Does experience slow you down?

This is somewhat of a philosophical post inspired by a good discussion we had in my engine group at Insomniac Games that also spilled out on Twitter. The question I asked was: “Do you think having more experience slows you down? And how do you combat that?”

The question seems illogical at first. Having more experience should make us better and therefore faster at getting results, right? That might certainly be true for a lot of problems, but when we’re trying to innovate and break new ground having many years of experience can lead to a condition known as “analysis paralysis” where we find ourselves unable to get started because we’re finding problems with our design before it even exists.

Of course that type of deep analysis has massive value itself. We want our designs to be efficient, make good use of memory, have a great UX and scale up to whatever production constraints we might face. But if we worry about those things too early we might never get to the points where we can know if an idea has any value because we never even get started.

In my experience this creeps up in particular when trying to innovate and break new ground. We have an idea that something would be useful and solve some particular problem. But years of experience with similar or related solutions might lead us down the analysis rabbit hole and we start to ask questions like:

  • How can I reduce the memory waste of this thing?
  • How will this thing scale to 10x the number of objects?
  • Will this approach lend itself to SIMD or a GPGPU implementation?
  • How will this work with 100 team members?
  • How is source control going to work?
  • How is it going to be network synchronized?
  • How can I maximize cache throughput for the data?

It’s easy to discard good ideas because we project there will be some future possible problems with them. But if we were actually to try the idea we might learn that only a few (or none!) of those concerns are actually valid based on what we find trying to implement it!

For example, if you’re just starting out and all you know is malloc() and linear searches, then everything you try to program will naturally map to those two concepts. There’s nothing to think about, and the neophyte will start programming right away to try his idea out. But someone who has 10+ years of experience of tuning custom memory allocators or crafting customized data structures will naturally have a tendency to think much deeper about a possible design in those two areas and disqualify every possible solution based on some theoretical problem it might encounter.

After two weeks the neophyte has a working prototype of his new thing while the battle-scarred veteran has 4 sheets of papers with half-formed plans for memory optimization and data structure sketches, or network synchronization problem dead ends or whatever his particular domain is.

At this point, what is the better position to be in? Being able to judge the merits of a naive implementation that actually runs? Or not having a prototype implementation at all because we don’t see how we can get past some future problem we might run into if we ever get there?

I’d argue that the naive start is way better, and cheaper too. If the solution has value and actually solves some problem (however poorly) we can apply optimization experience much more easily to improve the design incrementally. Furthermore, all the hard data dependencies will naturally have been shaken out by actually by taking an idea from start to finish which means the space is constrained and optimizations fall out much more naturally.

My advice: don’t be afraid to write “bad” code to test an idea out. Violate your own basic principles. Use malloc, or even std::vector. Use a slow scripting language. Use scalar code full of doubles. Use a single lane of a GPU wavefront. Use Excel and a bunch of awful awk scripts. Whatever the shortest path is to getting some output that will validate the idea. Only then start worrying about all the real world constraints.

If things don’t work out, then all the other constraints are moot points anyway. If things do work out, we know we have the know-how to get them sorted out.

Here are a few concrete tips that might help:

  • Write down all your concerns. Cross off anything that relates to an area where you have deep experience already. Solve what’s left using a prototype. Come back to your concerns when you’re satisfied the real unknowns are solved.
  • Start new files with the comment: “Do the simplest possible thing that can work. You can fix it later.”
  • Keep prototype work off to the side to remove any idea of peer pressure early in the discovery process.
  • Practice. Participate in demo scene blitz events or game jams where the whole point is getting something working right away and then iterating on it.

Finally I want to share this fantastic piece of advice I got on Twitter from Branimir Karadžić (@bkaradzic):

 Just do it, hack! I approach code like games, rush deep into room, trigger all NPCs, die, after respawn I know where NPCs are.

When trying to break new ground, that’s what it’s all about.

3 thoughts on “Does experience slow you down?

  1. This is something that I have been battling myself recently. I was feeling very unproductive. I got caught up in my imagination with all the things that I thought could/would go wrong. I was so obsessed with getting it right, that I couldn’t get anywhere.

    This is why I think it is important to have peers. They keep you honest. Left to your own devices, you need a truck load of discipline.

    The turning point for me was Chet Faliszek (from Valve) and his presentation at the Eurogamer Expo 2012. At one point he said:

    – Constraints aren’t removing features. What constraints are; is giving you an area to work in that you can push against.

    This boggled my mind for quite a while but allowed me to start considering what problem I wanted to solve, limit myself to solve only that problem and then actually solve it (and only then was I allowed to consider where to go next). Link below.

    I can also testify that it totally works to attempt some mind control tricks on yourself and that it requires a lot of practice and conscious awareness. When I catch myself doing something I should probably not be doing, I go into Notepad (or some trivial text editor) and type out a sentence or two. For example, why are you trying to optimize , when you don’t yet know that it is the bottleneck? Or my own personal pet peeve. Stop changing the name of everything, all the time.

    Thanks for sharing.

  2. Great advice! It is true that I often have a hard time getting a prototype out because of that. I’ve scrapped a lot of side projects because I ended up making a new memory management system or a network message system.

  3. There are those who advocate developers should always use the prototype-to-garbage strategy: always turn the core idea into an observable prototype that clearly demonstrate the main aspects (not caring about potential problems, and never, ever resorting to premature optimization) and show it to the other crew members (and to the contractor). After taking feedback, throw the prototype out and begin planning the real software.

    It seems overkill, but if you think that it fits the “show results early / focus on what brings revenue” model of e.g. scrumm, this really makes sense. But when I say “it fits”, it does so as one of the many ways of getting there, not necessarily the better.

    I think that if you have no legacy (in terms of code and knowledge of the platform) , you’re more tempted to not prototype, but that’s where the prototype feedback would be more effective.

    For instance, if you’re developing for a new harware platform whose capabilities are yet to be empirically tamed, it’s better to build one (or several) prototypes of your application of those capabilities and to see what can really be done on it.

    The same applies for a known hardware platform, if you’re starting a software product that’s somehow different of what you (either as a person or as a team) do.

    But if on the other hand you’re starting with a legacy: reusable software components, known hardware capabilities, restricted APIs, etc, perhaps your prototype need is lesser, but on the other hand it’s easier (and cheaper), so perhaps it’s an incentive to doing it as well.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s