The path to becoming a better developer


This whole thing is likely to come off a bit conceited, but please believe me when I say I’m not trying to impress anyone and not trying to toot my own horn- not that I’d never do those things, I certainly would- it’s just that this entry isn’t about that at all, even if it may seem like it in some parts.

With that disclaimer in writing:

You know, I’m a pretty good programmer.  Sure, I’m probably not on the level of most of the top-tier guys, the Rod Johnsons and John Resigs of the world for example, but hey, how many people are?!?  Still, I’d say I’m probably better than many (to valid approximations of the word “better” anyway!)

I don’t mean any of this in a boastful way (hard as that may be to believe for those that know me!) I’m saying it because it sets up the discussion to follow, that’s all.

Now, one quality I have that I’m actually very proud of is that I’m a successful “generalist”.  This means that while you’ll always be able to find someone better than me in virtually any topic you choose to look at, you’ll probably have a tough time finding someone who is as good in as many different topics as I am.  I’ve always felt that good generalists are worth more than pure experts.  To be sure, sometimes you absolutely need a top-notch expert, someone that knows C++ like the back of their hand for example, as opposed to someone who’s just passable at it.  When I’m putting staff together you can be sure I’m thinking generalists all the way because it allows you to tackle things that are tougher to tackle if all you have are people who know A completely but who don’t know B and C at all.  Generalists are able to draw on a diverse background and set of experiences to reach conclusions are generate solutions that pure experts usually can’t, therefore a staff of generalists is usually more successful (unless you’re in an environment with a narrow focus of course, where experts tend to be more successful, but my experience is that those types of environments aren’t as prevalent as you may think).

I was asked by a colleague once how I got to be as good as I am at as many things as I’m good at.  Now, let’s put aside the obvious arrogance of accepting the premise of this question in the first place!  I respect that this colleague recognizes that not all developers are created equal.  This is in no way, shape or form boastful- it’s just a fact of every workplace.  That’s why you have lead developers and you have junior developers.  We all start out as junior developers, but good junior developers will recognize that they aren’t yet leads and will seek out what got the leads to where they are.  That’s what this colleague was doing.  So, I wanted to give them a real, legitimate answer that could at least potentially help them get to that next level.

So, I thought for a while, and ran through some possibilities in my head:

  • Is it as simple as God-given talent and aptitude?  No, that can’t be it because I’m frankly not THAT good!  While basic aptitude probably plays a role, I’ve seen developers who I would NEVER have guessed could code their way out of a paper bag and yet they weren’t at all bad at their jobs.
  • Am I simply smarter than everyone else?  HELL NO!  Most people that know me, I feel safe in saying, consider me a pretty sharp guy.  But I deal with people every day who I KNOW are intrinsically more intelligent than me, some of whom I’m a better programmer than, so it can’t be simple intelligence.
  • Is experience the wonder-drug here?  Well, clearly that is a factor. I’ve been doing this programming thing since I was about 9 years old, so that’s around 27 years in total.  Only about 13 of those though have been “professional”, where most would claim you truly learn the most, so that can’t be the only answer either.
  • Is education the key?  Definitely not: I never graduated college and only took a few Computer Science classes anyway, absolutely none of which taught me anything substantial that I didn’t already know.  Even in high school, while I was a solid B to B+ student the whole time without putting in much effort, I was rarely on any sort of honor roll, and was only about mid-range in my graduating class (if only I’d have put in SOME effort- oh the things you realize when you’re older)
  • Analytical ability.  Yes, that has an impact for sure.  We all know developers who can’t debug to save their lives.  They can’t think through a problem logically and come to some sort of reasonable conclusion.  Give them a detailed enough spec and they can produce working code, but not GOOD code, and any deviation from the spec along the way proves difficult for them to handle.  They lack basic analytical ability, even to some extent the basic ability to think logically.  This most definitely is part of the answer, and a fairly big part, but again, it’s can’t be the ONLY answer.
  • Being “into it” at a young age.  I tend to discount this because while I think it’s true for some of us, I’ve met tons of developers who totally kick ass who’ve only been doing it a very short time (like 2-3 years in some cases).  While starting young I wouldn’t imagine ever hurts a developer, it’s probably not all that important either.

So, what makes me a developer that someone thinks to ask how I got to be as good as I am?  I didn’t have a definitive answer right away.  All of the above points probably factor into it, but none of their own is enough I think, and some are probably even debatable anyway.

Then it occurred to me: there was one thing I’d done A LOT of growing up that many other developers didn’t do, one thing that I still do today that not many developers do:

Video games.

Programming video games is an experience unlike virtually any other that I’m aware of.  You touch on so many different areas and have to learn so much that I think the outcome of the experience is your brain being wired a bit differently!  Especially if you do every detail of the game, from level design to graphics and sound to the underlying logic coding, you can’t help but learn a ton.

You need to figure out how to efficiently store all the multimedia assets so that it fits on your shipping media without killing the quality of the resources.  You need to do AI development.  You need to understand math to do graphics programming.  You need to design the world map and do level design and ensure that it’s all logical, solvable and fun at the same time.  You need to deal with compression algorithms and multithreaded design and network communications and audio/video and even write the story!  You often times need to manage multiple people, even for a little side-project, to get artwork done and voiceovers performed and code units integrated into the main baseline.  You need to create your own tooling, and you need to do all of this while ensuring that the performance of everything you do is stellar!

Even for simple games, this is not a task to be undertaken lightly!

It’s not about learning anything SPECIFIC either. I mean, learning Bresenham’s algorithm for drawing a line, or understanding how to put together a pursuit algorithm, none of that is likely to be directly applicable to coding an account balance transfer system for your next contract with a bank.  However, these things have underlying concepts and thought processes that can inform your thinking on the tasks you have to do at your regular day job.  They’ll also open up your mind to new solutions to problems that take bits and pieces from multiple topics in a way that many other developers can’t.  That’s what being a generalist is all about.  It’s more about practicing the ability to take seemingly unrelated bits of experience and information and synthesize it into a unique solution to a problem than it is about what you concretely know about anything at any given time.

Now, let’s be clear: none of the games I’ve ever made have been great.  It’s not like I’m churning out Halo or World of Warcraft or Guitar Hero here, so it can’t be about money.  I’m extremely proud of a couple of them (, K&G Arcade in particular, but the sales numbers say they weren’t very good, or AT BEST weren’t marketed well (hey, there’s something else you have to deal with!).  The thing is though that they don’t HAVE to be good for them to make you a better programmer.  No, check that: a better DEVELOPER.  It’s not just programming that creating games improves, it’s everything else that goes into being a developer because, let’s face it, programming, i.e., writing code, is a fairly small portion of what us developer/architects actually do.

I can remember the first game I ever wrote: the year, approximately, 1983.  It was based on the television show The A-Team and it was on my Timex Sinclair 1000.  I don’t remember much about the game, aside from the fact that it sucked beyond belief!  One other thing I do remember about it though is that the Timex Sinclair 1000 had 2k of memory and in order to make the game how I wanted it, I actually invented run-length encoding.  I obviously don’t mean “invent” as in I should own the patent on it now, it clearly wasn’t an original idea.  I mean “invented” in the sense of I didn’t know about it, in fact at that point had no way I COULD have known about it, yet that’s what it was.  I crammed something like 2k of graphics data alone into about 500 bytes, give or take, leaving me 1.5k for the game’s logic code.  In retrospect, that’s a pretty amazing achievement for a young kid doing a very early bit of programming.

But again, it’s not that I’m smarter than any other kid that age was- maybe I was to some extent, but not hugely so.  The difference is that I put myself in a situation where I had no choice but to improve if I wanted to succeed.  Making a game was that situation.  Few other projects at that time would have provided that challenge.  I guess at the end of the day it’s a question of evolution: evolution doesn’t necessarily mean growing a third arm because that’s advantageous for the species (it would be though, wouldn’t?!?)  Personal evolution is just as important.

Every one of the books I’ve written so far has had a chapter in it devoted to a game project.  That’s the case for a couple of reasons.  First, I believe my readers enjoy it. Second, I think they learn a lot from it because it frames the topic of the book in a different way than the other projects presented do.  Third, it’s frankly fun for me to work on, which is important when you’re writing a book because it’s a lot of work and having one chapter that you can cut loose a bit in is helpful.  Fourth, I know that in the process of writing that chapter I’ll learn something myself, and it hasn’t failed yet!

So, the point of all of this is simply that if you want to make yourself a better developer, a better generalist, start creating games today!  They don’t have to be great, and honestly, they mostly won’t be very good at all- you may produce one at some point that’s not bad, but generally, they’ll suck.  Thankfully, that doesn’t matter in the least!  As long as you aren’t in it for the money it doesn’t matter one bit.  The process of creating a game will improve you as a developer more than any other single thing you can do, that’s my very firm belief.  I mean, you can waste four years in school, MAYBE learn a few things that are useful (the rest will be outdated by the time you get your degree, or else wasn’t terribly useful in the real world in the first place) or you can spend a few months creating a game that’ll teach you so much more.

I know which I’d choose 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.