The Effective Developer


I recently finished reading "The Effective Executive", by Peter Drucker. It's a classic and I've seen it recommended countless times over the past few years. Naturally, I highly recommend it as well. However, the book is general (as it ought to be) so I wanted to explore some of its concepts applied to gamedev. Not only for my own benefit, but for any other developers who are looking to improve their processes as well.

Without further ado, here are 3 important take-aways from chapter 2 of the book, "Know Thy Time".

The Time Quantum

"To be effective, every knowledge worker needs to be able to dispose of time in fairly large chunks." - Peter F. Drucker

This is an idea that will not come as a surprise to many of us, but the term "Time Quantum" may be a new one. It refers to the amount of time required for minimum effectiveness. For a programmer, it is large because you need time to build up a mental image of what the code is currently doing. Only then can you know where to put the next couple of lines. For creatives, you need to be able to submerge yourself in the world before making meaningful strides of progress. During our design phases, our best ideas arrive after brainstorming for 30 minutes to an hour.

So what is an action item based off of the time quantum concept? Block off long, continuous chunks of time in which to do work. If you have 3 errands to run, do not sit down and work for 10 minutes, then run an errand, then sit back down to work, etc. Instead, run all 3 errands at once and then spend the remaining time developing. In the end, you'll have gotten a lot more done even if you spend the exact same amount of time.

Eliminate Time-Wastes

"To find time-wastes, one asks of all activities, 'What would happen if this were not done at all?' If the answer is, 'Nothing would happen,' then the obvious conclusion is to stop doing it." - Peter F. Drucker

This one is a no-brainer, but I have found it helpful to try to form this into a habit. We all know that if something will have no outcome, then there is no sense in doing it. Yet, we are often in such a rush to get to work that we rarely stop and ask ourselves, "What if I don't do this?" The goal of this exercise is not to negatively affect the game by removing necessities in the name of productivity. That is, in fact, quite counter-productive. The goal is to make sure something is a necessity before taking the time to create it.

An example taken straight out of Dojo Storm: we wanted to create a tool for entering static text. Most of the miscellaneous text was either stored in code or in XML. This would have enabled the designers to edit text directly, as opposed to telling me and then I update the code. Spoiler alert: the tool was never created. Why not? The overhead of the others telling me what to enter, and then me entering it, was not large enough to warrant building an entire tool. In other words, the answer to "What if I don't create the tool?" was "It'll take 30 seconds per sentence, as opposed to 4 hours to make the tool." Deciding on the tool's fate after that was easy.

The Recurrent Crisis

"A crisis that recurs a second time is a crisis that must not occur again." - Peter F. Drucker

In other words: Fool me once, shame on you. Fool me twice, shame on me. There are always going to be unforeseeable issues that arise during development. We forgot to account for making a game icon. One of our computers died. A tornado struck and wiped out our entire studio. These are all things that can happen (some more severe than others). But, the instant that one of them happens a second time, you should put some kind of control in place to prevent it from happening again.

Forgot the game icon? Create a "Do not forget" document and make sure you reference it at the start of every project from now on. A second computer dies? Start saving all your info remotely and/or in backups. Most developers will yell at you if you aren't already doing this, anyway. Two tornado strikes in one month? It's time to either relocate or invest in a tornado-proof building.

It's even possible to develop these controls ahead of time. At Synersteel, we use Git with Unity. Git has a fairly steep learning curve, especially for non-programmers. As such, we created a quick document that outlines all the common functions of Git and how to perform them. This took about 20 minutes of a developer's time and will save much more than that, especially as the company grows and others get involved. It's a lot quicker to copy-paste a link than it is to type it all out each time or get on a 10 minute Skype call.


The ideas of time quanta, eliminating time-wastes, and recurrent crises can all be applied to game development. We've started implementing them at Synersteel, and would love to hear from you about including them in your own routines.