So the question will very likely need re-phrasing. I thought about asking this for a while, but held off because it's a tad vague.

To explain - I have been a programmer for 4 years and only begun doing it when I took a university course. Now that I'm working as a programmer, I find that often people assume you know a number of things that I feel people who have been messing around with computers know by default, and I don't.

Things like shell commands, how to use subversion, stuff about how websites work at their base level, how to use databases and so on.

What I would like to know is some of the basic stuff, the nitty gritty that people in a programming job are expected to have encountered and know how to do.

Also, I'm sorry if people feel this question is not a perfect match for the Q and A format - please let me know how I can improve it - or just edit it heavily.

Thank you in advance.

  • 1
    \$\begingroup\$ The reason your question isn't a good suit for the Q&A format is because every answer is arguably valid. There is no "correct answer" that stands the test of time. That, and in my experience, you'll learn what you need to know on the job by virtue of having to do things. See also this question: gamedev.stackexchange.com/questions/5538/… \$\endgroup\$
    – Tetrad
    Feb 6 '12 at 16:33
  • 2
    \$\begingroup\$ fair enough. I have to say though, I think often you two stick to the site rules a little too rigidly and close questions that actually have really methodical, useful answers. For example - gamedev.stackexchange.com/questions/22571/… I'm not having a go, I'm just saying maybe someone in the future would actually find them useful. \$\endgroup\$ Feb 6 '12 at 16:43

I'de say the following is important:

  • Algorithm efficiency (knowing which algorithms are more efficient for which problems and what heuristics to apply for which problems is very important in AI, graphics, and a few other parts of game programming). I'm a hobby interviewer and have encountered this more than anything else I'll mention.
  • Heavy object oriented knowledge (beyond the basics of object oriented design with polymorphism, inheritance, generics (in languages where applicable), and other abstractions, you really need to know how to design an object oriented program. If you're going for entry level game programming, knowing how to design it atleast in concept, will help you navigate your peers code at the very least.)
  • Know different design patterns (In commercial game code I've seen, you tend to run into a lot of versions of the common patterns like observer, monitor, facade, etc)
  • know SVN, shell, other stuff you mentioned. These are essentials and can easily be learned in a week if you dedicate some time. Using them right comes with practice, so I'de use them for all personal projects no matter how trivial for a while.
  • It's not computer specific, but the more advanced your game, likely the more you will need linear algebra. Knowing what types of transformations will do what to matrices and what these matrices represent proved to be a great help. Once I learned this stuff, working with vectors, image effects, and projection matrices became really easy.
  • \$\begingroup\$ really excellent. thank you. I'm going to cram design patterns and revise template stuff. \$\endgroup\$ Feb 6 '12 at 16:23
  • 1
    \$\begingroup\$ By the way, to learn the common design patterns, pick your favorite language that compliments object oriented design and search amazon for a book called "<language name> design patterns". In my case it was "C# 4.0 design patterns". That brings the patterns into a language you're comfortable with and speeds up the learning. \$\endgroup\$
    – brandon
    Feb 6 '12 at 16:35
  • \$\begingroup\$ FYI I got the job, been in the industry for 6 months now, so thanks! babbled on about singletons, factories and facades in the interview! \$\endgroup\$ Aug 16 '12 at 11:21
  • \$\begingroup\$ Very nice, congrats! Yea I went through a phase where I wanted to know what was expected in the industry so I went to a few interviews with no real interest in the job. Learned that the things in that list are enough to peak their interest. \$\endgroup\$
    – brandon
    Aug 16 '12 at 18:17

I wouldn't stress out too much about not knowing stuff in advance. I've spent years hearing people talk about stuff I didn't already know (I didn't study computer science in school) and it used to intimidate me, but the pattern I eventually started to notice is that people almost always talk like they knew it forever and everyone should already know it, but that's rarely actually true and it's not a big deal for me to simply make a note "someone mentioned X; learn about that" and then figure it out.

You may have heard that a programmer needs to learn new stuff constantly and one of the most important skills a programmer needs is the ability to learn new stuff quickly. Well here's why.

For example, to address the exact list you gave, here is how I learned that stuff:

I first learned to work with shell commands because I started using computers back in the days of DOS. Obviously I was only doing the simplest command-line stuff, but the point is I got comfortable working that way and have no problem picking up other stuff on an as-needed basis.

I learned about SVN at a job a few years ago. This was the clearest case of what you described, where other programmers at that job behaved as if everyone should just know stuff by default, but it wasn't hard to learn SVN and that is just one of several really useful things I learned at that job.

I started learning how websites work back when I made my first website in highschool, and I've been gradually adding bits and pieces of knowledge over time. There's no clear moment of learning I can point to.

I still don't know much about how databases work, because I'm mostly a client-side programmer. When I once needed to query a database directly I learned a few SQL commands on an as-needed basis, but beyond that I don't know much. shrug


Not the answer you're looking for? Browse other questions tagged or ask your own question.