• Hey Guest. Check out your NeoGAF Wrapped 2025 results here!

So I just got a job in the game industry...

congrats, here's a cookie

cookie.jpg
 
wmat said:
He's the guy who promotes SDL every time and wants to make a Train Wrestling Space Trade Sim.

I enjoy programming a lot.
:D
By the way SDL rocks ,and the train is already running on the tracks. >:(
But i want to be a McBradders ,a game designer.
 
Fersis said:
:D
By the way SDL rocks ,and the train is already running on the tracks. >:(
But i want to be a McBradders ,a game designer.

Inform us when and how you make the switch. :)
 
bistromathics said:
:lol and what do you expect to be doing out of college?

every CE and ECE ends up as a software engineer

quit lying....

really?

man that would suck...but at the same time i don't wanna be doing test engineering.
 
Andrex said:
Inform us when and how you make the switch. :)
Oh yeah, right now i cant quit my job. I have to finish the current big project first.
But is really hard to land a job like that.
 
Fersis said:
Oh yeah, right now i cant quit my job. I have to finish the current big project first.
But is really hard to land a job like that.

That's why I said it. :lol

...:(
 
My Tip:

Test your code before you commit anything. If you break the game for others it will piss them off and it is also a huge waste of time and ressources for the company.
 
Most peeps have already said what needs to be said.

- Don't be an asshole
- Know when to ask questions and when to work it out on your own
- (Me personally) I start a notepad on my computer with names of people and where they sit in the office in relation to me. I cannot keep track of names very well and I find it helpful to write them down.
- Don't fucking break the build. AKA Test your code as many ways as you can think of before submitting or every other department will know you as THAT GUY THAT RUINED MY DAY
 
Iced_Eagle said:
Oh, and don't be a hermit! Go talk to people and try to be interesting (aka, don't always talk about games because how many conversations are you going to have on how Ocarina of Time is awesome before people just decide to start to stop caring?).

YES. Speaking from experience here (lol), there's a limit to how much you can really talk about video games. Unless you actually played it WITH them, there isn't all that much to talk about except "how I felt" about the game... and convo's dry up really fast especially with a person who didn't play the game recently (or hasn't played it in since 1996 lol).
 
flarkminator said:
Most peeps have already said what needs to be said.

- Don't be an asshole
- Know when to ask questions and when to work it out on your own
- (Me personally) I start a notepad on my computer with names of people and where they sit in the office in relation to me. I cannot keep track of names very well and I find it helpful to write them down.
- Don't fucking break the build. AKA Test your code as many ways as you can think of before submitting or every other department will know you as THAT GUY THAT RUINED MY DAY
-Branching off the "Don't fucking break the build". When you check things in, even if it's working on your machine, have at least one person test it before the end of the day and make sure it works. You don't want to come in the next morning to find out that what you checked in was correct, but only applied to your machine and broke everyone elses.
 
Like most people said, be open, don't be afraid to talk to people and to ask for help when you need it.

Don't reveal anything until it's been announced to the public. Golden rule for the outside world, especially if you work in a close-knit industry like we have here in Montreal. One wrong move, a real bad one could get you banned from all of the studios there.

Just be a decent human being.

Also, Programmers are fuckin' weird and badass at the same time. I wouldn't do their job for all the money in the world. So complicated.
 
AlphaTwo00 said:
-Branching off the "Don't fucking break the build". When you check things in, even if it's working on your machine, have at least one person test it before the end of the day and make sure it works. You don't want to come in the next morning to find out that what you checked in was correct, but only applied to your machine and broke everyone elses.

That's great advice as well. Once again, thanks everybody that chimed in. This should help when I start next month. Heh, I might even be working with one of you.
 
If you're anything like me, you're going to feel like an idiot for the first couple weeks while you try and get integrated with the codebase. I hate the feeling of just taking up space and not contributing but you've got to be able to know how the current code works. Your co-workers will understand this. Hopefully you'll get something easy to do to help you get integrated instead of your first day being a "read the documentation" day.

If your company has a lax schedule (for example, core hours being 11-4 but you must work an 8 hour day) I'd recommend coming in earlier. I love coming in before everyone else and getting all of my e-mail crap out of the way so that when my boss and everyone else comes in I'm already doing what needs to get done. I also tend to stay a little later than everyone else as well, but I'm only an intern and I'm still trying to get the full time gig.

Other than that, don't freak out. No one is expecting you to have all the answers so be sure to ask questions if you feel like you're doing something wrong, it's the only way you're going to get better at what you do and it's a far better option than just committing garbage code.

Congrats on the job though. I'll be graduating in May and I'm stressing over if I'll have one come graduation time.
 
Jackson said:
And lastly, don't forget! Life isn't World of Warcraft. It takes years to get where you truly want to be, and requires a lot of hard work and dedication.

Um, that sounds exactly like World of Warcraft actually. :o

Just enjoy your job for now; you can worry about trying to get places later on.
 
Jackson said:
And for the record at my company, anyone can suggest anything from any level to the top brass.

You bet they can, now that you have greenlighted this terrible game of doom that needs to reference every noun in the english language :P

Didn't know you were the owner btw. It makes you even more badass.
 
hydragonwarrior said:
YES. Speaking from experience here (lol), there's a limit to how much you can really talk about video games. Unless you actually played it WITH them, there isn't all that much to talk about except "how I felt" about the game... and convo's dry up really fast especially with a person who didn't play the game recently (or hasn't played it in since 1996 lol).
Unfortunately, WOW talk is evergreen.

ratcliffja said:
This should help when I start next month.
Oh, you haven't started yet? You might want to read "Code Complete" or other Steve McConnell books. If you've already read it, read it again; it can't hurt.

RoyalSimonBoobs said:
If you're anything like me, you're going to feel like an idiot for the first couple weeks while you try and get integrated with the codebase. I hate the feeling of just taking up space and not contributing but you've got to be able to know how the current code works. Your co-workers will understand this. Hopefully you'll get something easy to do to help you get integrated instead of your first day being a "read the documentation" day.
I find I've always needed some time to ramp up. Unless you come into a situation where you already know the codebase inside-out (say, you're returning to a company, or it's licensed an engine you wrote somewhere else), it's absolutely expected that a new employee won't be up to speed immediately.
 
AlphaTwo00 said:
-Branching off the "Don't fucking break the build". When you check things in, even if it's working on your machine, have at least one person test it before the end of the day and make sure it works. You don't want to come in the next morning to find out that what you checked in was correct, but only applied to your machine and broke everyone elses.

:lol

Gives me memories of last week. Went to go implement a few things, went to test and BAM game insta-crashes when you get past the menu... Cool stuff to basically twiddle your thumbs until the guy fixes his mess. Which I guess is also a lesson that before you do anything for the day, make sure the game runs :lol I wouldn't have wasted all of that time doing implementation and bug-checking if I would have just seen that the build was busted before I touched it.

Oh, and on that note... Don't overstep your code boundaries. If you see something wrong in someone else's code, tell them politely. Don't just go magically changing their code around to "make it better". Seriously, it's happened to me where I go to work one day, and some of my code is different. What makes matters even worse is two-fold:

1) The code I had was merely temporary and was due for a re-write. Thus, the person who spent the time "improving" and testing my code wasted their time since it was going to be rewritten anyways in a few days.

2) I had to take time to figure out what the hell they changed since it was my responsibility. Loss of productivity on my part!

Don't go around being an asshole and saying "Dude, go fix your code and do it this way" as it's not your job to tell them how to do theirs, but if you see like a really great way that will actually make a noticeable difference just give them your opinion if you are knowledgeable about it at all. It's a fine line between being helpful and being an ass though, so watch out :lol
 
Ravidrath said:
Fuck you, I'm taking you somewhere to lunch this week you're going to HATE.

On that note, everyone I know at work that browses Gaf is a designer. There's one programmer but I don't know if he has an account. I wonder if that's a coincidence.
 
M3wThr33 said:
On that note, everyone I know at work that browses Gaf is a designer. There's one programmer but I don't know if he has an account. I wonder if that's a coincidence.

I know several designers here who browse GAF here, all with accounts. At least one programmer and one producer browse, but I don't think they have accounts. Tis weird.
 
* If you drink the last bit of coffee, make a new batch.
* If you drink the last of the watercooler, get a new jug of water.
* If you use up the last bit of toilet paper, get new rolls.
* Flush properly, and scrub those skidmarks dammit. Don't pee all over the place.
* Do not steal other people's pens/wacom pens/ phone chargers.
* Do not leave your dirty cups or opened food items on your desk. Those black things on your desk are mouse turds, and that sticky patch on your wacom tablet is mouse pee.
* Do not play your music loudly.
* Do not browse tubgirl, goatse or rotten.com where people can see your screen dammit.

* And keep your job options open.
 
Tempy said:
* If you drink the last bit of coffee, make a new batch.
* If you drink the last of the watercooler, get a new jug of water.
* If you use up the last bit of toilet paper, get new rolls.
* Flush properly, and scrub those skidmarks dammit. Don't pee all over the place.
* Do not steal other people's pens/wacom pens/ phone chargers.
* Do not leave your dirty cups or opened food items on your desk. Those black things on your desk are mouse turds, and that sticky patch on your wacom tablet is mouse pee.
* Do not play your music loudly.
* Do not browse tubgirl, goatse or rotten.com where people can see your screen dammit.

* And keep your job options open.
This man speaks the truth.
 
Iced_Eagle said:
I'm still in college, but my professors who worked at MS say that it is really, really important to ask for help when you need it.

During your first couple of weeks, people will pay attention and try to figure out how you work. Games are all about a team, so they want to see if you are someone who does his own thing and consistently bangs his head against the wall and is stubborn, or if you are someone who when he gets stuck goes and asks for help.

Oh, and don't be a hermit! Go talk to people and try to be interesting (aka, don't always talk about games because how many conversations are you going to have on how Ocarina of Time is awesome before people just decide to start to stop caring?).

This is true to a degree but there is a downside to it that you have to watch for.

As a manager I always appreciated when new hires tried to figure things out on their own as much as they could before coming to my office and asking about trivial stuff.

There is a time for asking for help and there is a time for figuring it out yourself. For example if you need help with setting up your machine and finding the resources you need, talk to your co-worker (it's better to ask somebody in your team than your manager if you have the option and good managers will always assign a mentor for new members). If you need a quick rundown of what a function or feature does or the overall system you are working on, go and ask somebody in your team to give you an overview. That's a very positive attitude and there's no harm in it.

However, once you got the overview, don't ask people to explain what a function does unless you have tried your best to figure it out yourself. Nothing is more annoying than somebody who keeps asking trivial questions (and it may cost you eventually).

If I want to you give you a couple of advice:

Show a "can do" attitude. Don't be shy of accepting whatever they throw at you. "By default" your answer to new assignment should be "Yes I can do this and fit it in my schedule" and not "but why me, the others are not doing much".

Show passion for what you are doing.

Don't be too quick to dismiss somebody else' code. There may be a reason for the code to do what it does but it so happens that the previous guy didn't bother to comment it. Be respectful if you see something that doesn't look right and ask questions as if: "There is a good reason for this and I don't know what it is".

Don't try too hard to show you know something when your knowledge is really shallow. In other words, don't make a fool of yourself.

I see somebody suggested you start by thinking outside the box right away. That's fine but you got to know the box before you can think outside of it.

Look for opportunities to go beyond what is asked from you. For example try to develop a test for your code even if you have not been asked to. Document undocumented functions. Offer help with fixing bugs even if they are not yours.
 
Tempy said:
* Do not steal other people's pens/wacom pens/ phone chargers.

When I was enjoying a day off from work once one of the fuckers from the test department took my Wacom pen and sellotaped it to the ceiling above my chair. >_<

Oh, that's another thing: people who work in QA can be utter nutcases, either from birth or through months of doing their job. They can be your best friends and your worst enemies all in one.
 
SovanJedi said:
When I was enjoying a day off from work once one of the fuckers from the test department took my Wacom pen and sellotaped it to the ceiling above my chair. >_<

Oh, that's another thing: people who work in QA can be utter nutcases, either from birth or through months of doing their job. They can be your best friends and your worst enemies all in one.
Yeah.
Its a hard and crazy job after all.
 
I've thought of applying for a job or two in the game industry, but with the industry cutting massive numbers of jobs, and my programming experience not extending much beyond doing a few small projects as well as my CS degree, why would anyone hire me over one of the recently cut people who have been in the industry forever. I guess it would be better to keep working on my "indie" experience, and try to apply in like 2 years or something, when I have more things in my portfolio, as well as actual "work" experience. I guess it would also help to live in SoCal :(
 
Actually, I thought the same thing. However, I applied for this job a little over a year ago and just kept pestering them about it. They kept saying that they'd let me know if there was an opening and to check back later. I did over and over and over again and I finally got the job. It's definitely important to have a good portfolio, but perseverance is essential.
 
I'd planned to go into game programming after graduating, but was turned off by instability of it all. Instead, I took a position at Company X to do my coding.

Others have offered some sound advice, such as being humble. It's very likely you are not going to out-code a senior programmer, and you should probably keep that in mind. Check yourself many times before taking issues to your superiors, or questioning their suggestions.

Also, spend some quality time reading the C++ FAQ Lite. You're sure to find some interesting things in there that can be helpful.

Finally, good luck. Give 'em hell.
 
poweld said:
Others have offered some sound advice, such as being humble. It's very likely you are not going to out-code a senior programmer, and you should probably keep that in mind. Check yourself many times before taking issues to your superiors, or questioning their suggestions.
Really, it's about balance. Some people are too humble, and they check themselves too much before stepping forwards with questions. That wastes time. Others are too brash and do need to hold back. Try to figure out which side you're on and how to correct it.
 
Dachande said:
I know several designers here who browse GAF here, all with accounts. At least one programmer and one producer browse, but I don't think they have accounts. Tis weird.

^_^ :D
 
Top Bottom