What does the skill of a professional game programmer look like?

So I've been teaching myself about C# programming for a handful of years now, and I've come a long way. I'd like to know how much farther I still need to go before I'm ready to apply for a job. Of course I'll learn a lot along the way while I'm actually working, but it would be nice to know what I'd need to know first.

If anyone could shed some insight on this, I would be thankful. What topics does a programmer need to know before they're considered to have completed their ninja training?

 

With game dev, it is too large for that question. What do you want to specialize in gameplay, graphics, networking, ai, physics...? Though in general know the basics of data structures, trigonometry, file input/output, and the general concepts of other areas is a good start.

 

I would start with looking up c# interview questions.

While not directly related to game dev, being able to answer the questions will give you an idea of what level ninja you are or are not.

 

If I was offering someone a job I'd expect them to know all of that.. Most I've worked with do, although some stronger in some areas than other.

 

If you want to be "a programmer", you're already that. Get someone to pay you to do it, and you are now a "professional programmer".

But you want to be like a ninja?

*cues flute music*

No one can never know all they need to know, Nemox-chan. To reassure the conscience, people adopt labels... experts, professionals, highly experienced... but these are just labels, they mean nothing. Like a sticker that says "bulletproof" offers no protection in battle, these labels don't enhance our skills or knowledge.

Instead of reassuring yourself that you're "ready", adopt the way all masters as your own.

Train every day.
Be obsessive over small details.
Be highly critical of your own work.
Do things correctly, even if it takes more time.
Never stop learning.

That said, I recommend The Pragmatic Programmer, as it was the only book I ever read that presented practical advice about how to structure programs.

Learn to program.

Focus on the stuff you find difficult, not what you're best at.

Learn about unit tests.
Write code that catches bugs and inaccuracies as close to the line of occurrence as possible.
Only use exceptions for exceptional circumstances.
Comment with care.
Hard-coded values are the devil, Hitler and Megatron rolled into one.
Remember that every line you write is a potential disaster waiting to happen, so write fewer lines.
Remember that every time objects interact with each other's members without going through public methods or interfaces, you lose the ability to narrow down problems to the actual object in which they occur.
Remember that in two days, you will be scanning this code at 3am for a bug that "doesn't make any #@&%ing sense"... make everything you do as clear as is humanly possible, right down to the spacing of your parenthesis and the naming of your variables.

Do not repeat yourself.

You will have situations you come across where you need to create a method, but instead, you copy and paste the code and change "foo" to "bar" in 2-3 locations to "save time".
If you have copied and pasted the same code 15 times, one day you will have to make 2 changes to each of those 15 code blocks that will be different by one word each, that's 30 individual changes.
If you do this habitually, you will be modifying 3, 5, 10 objects each time you add something, on several lines in each, in 2-3 places each.

Plan.

If you don't plan, it will never work out anyway so just quit now... cut to the chase.

Work harder than other people.

Always assume everybody else is smarter than you.

When you are ready, you will no longer question if you are ready, grasshopper.

 

Apply for a job now. If you get the job, you are ready.

 

http://programmers.stackexchange.com/questions/76123/im-in-over-my-head-at-my-job-what-should-i-do

A comment from the poster:

http://blog.codinghorror.com/why-cant-programmers-program/

...

...sometimes you can pay somebody a lot of money, and they can do what you pay them for, and they don't have to be all that good at it to get it done. It's taboo, but doing something for a living doesn't mean you're good at it. Sometimes, it just means you are really good at getting hired... good people skills, likable personality, good manners.

Recently, I learned that Toby Turner (aka Tobuscus, he was a fairly popular YouTube star a couple years ago) had some issues with the development of his game. Apparently, what was supposed to take 2 months ended up taking a year and a half. The game is still riddled with bugs, and he is largely dissatisfied with the product. They way contracts were written, he apparently had to pay $50,000 to fix even relatively minor issues.

He had over a half of a million dollars from an Indiegogo campaign to make the game, and to date has probably not made back the money they spent developing it, despite healthy promoting, partially at least due to the fact that the developer took far too long to produce what is still, by any measure, an incomplete game. It's an app that looks like a Warcraft clone, but about 1/1000th the scope of Warcraft.

Being paid to do something and having ninja skills are two different things.

 

To be fair, I don't think anyone would be ready for what's described in that StackExchange listing. There's a difference between "skilled" and "experienced", and the only way to get the latter is by doing actual jobs. If you're getting experience without a mentor/superior around then it's way harder, and I suspect would always lead to self doubt because you've nothing useful to measure yourself against.

I've certainly been there. It took me until years later to find out that some things I did and felt negative about are things that either a) more experienced people struggled with, b) other teams had refused to even try or c) my result was in fact far more solid than I'd thought. That's all because, at the time, I didn't have a more experienced person directly on hand or in the trenches with me to say "nah, this thing is actually really hard, most people would find it a challenge, it doesn't reflect negatively on your skills". All I knew was that either the job wasn't done as easily as I thought, or that the results weren't as good as I was hoping for. (Luckily we were always smart about only promising what was needed, so I always met deadlines and requirements on that basis.)

In that guy's case he's measuring himself against a 3 month benchmark and feeling bad that he's falling so far short of it, without ever realising that it was a completely unrealistic benchmark in the first place. Estimation is hard, so it's quite possible that all of that fellow's insecurities come down to that mistake being made in the first week.

So, if there's a lesson from this post, it's to see if you can get a first job which involves working with someone already experienced in the field you'll be working in. I'd say 5+ years and multiple delivered projects, because you don't want someone who's a bit ahead of you, you want someone who's comfortable and established.

 

This one is double edged. I largely got as far as I have because I was happy to work to my strengths and get others in to fill gaps. If I recognised that a project involved an area I wasn't familiar with I wouldn't start learning it, I'd look for someone with the relevant skills and bring them in. I've never wanted to be good at everything, and if I'd insisted on trying there's no way we'd have completed projects as reliably as we did in our early days, because instead of taking advantage of my strengths I'd have been diluting myself across areas of weakness.

Some degree of focus should go into stuff you're weak at because that's how we improve, but that shouldn't be an all-encompassing guideline. Sometimes you should focus on what you're good at, put all of your finite effort into the areas where you're fast and effective and can Get Stuff Done.

As an aside, having people in who are good at things I'm not was a great way to start learning those things. I still had to be a bit familiar with what they're doing and have relevant knowledge to work with them to Get Stuff Done, and had an experienced person on hand to help with that. So I was still learning, and we could both/all Get Stuff Done at a pretty reasonable pace.


Edit: Let me re-state my premise. As someone with around a decade of experience I don't consider it "pragmatic" to drop all of that experience at the stuff I'm good at and focus on a completely new area if I don't have to. If for some reason I do have to then I'll do it as early as possible, because that gives me the most time to deal with issues which will almost certainly arise.

 

Actually, that listing pretty much described my previous day job for a while, and I quite enjoyed it. Before they finally hired a good DBA, I solved numerous performance issues in both the code and the database. Anyone that can't do it simply doesn't have enough experience yet. It's not magic, just knowledge and problem solving.

Still, they *should* have had a DBA for the DB stuff and left the coder to code. They probably thought they couldn't afford it, but they were wrong, of course. They paid that poor dev a lot more money than they could have spent on a short-term DBA to do the same thing, quicker and better.

 

Just noticed I didn't answer the OP's question...

The answer to "what should a senior programmer know" depends on the field. For all fields, they need to know how to implement standard things like singletons, managers, queues, etc etc. I'm a web dev by day, and I'd expect a senior web dev to thoroughly understand the lifecycle of an http request, including security concerns. I'd also expect them to understand event-based programming and dom manipulation to the point that they can whip up a small framework from scratch if needed. (Hint: It's not needed. But they should be *able* to.) They should understand CSS thoroughly as well. They should know what will and won't work on various browsers, at least for the major things that customers frequently want. And they should be able to look up anything they don't know in a reasonable amount of time.

A senior programmer should be able to create an experiment to test a new design quickly and simply, and then re-implement that design with better performance in the main project. They should be able to things in more than 1 way so that if one way has flaws, it can be reimplemented with another solution that doesn't have those flaws.

They should be able to compare solutions in their head, finding the obvious potential flaws without writing a line of code, and choose the solution with the best potential to be correct. They won't always be correct, but they'll have a much better shot at it than a more junior programmer.

This is what I do for my day job as a senior developer. When a developer under me needs help with the above, I also have to stop and help them with their problem as well.

Not everyone needs to be a senior developer, and not every company needs one, either. Modern programming techniques such as pair programming, code reviews, unit testing, etc allow programmers to share their individual skills a lot better and improve the skills of every programmer involved.

So the final question is always: How do I get to be a senior developer?

Practice. Keep writing lots and lots of code. Write code in your spare time, on practically any subject that interests you. If something is shiny, take it apart and see what makes it tick... Or write your own. Or take it apart *and* write your own. Join others in your local community for tech talks, meetups, code dojos, and more. Publish things as open source and accept the critiques that you'll get.