Productive Developer Series - John Carmack

November 26, 2017

John Carmack is the instrumental developer behind groundbreaking products such as: Wolfenstein 3D, Doom, Quake, Doom 3 and more. Currently he is the CTO of Oculus VR.

Carmack is a prolific developer and has shipped multiple succcessful, cutting edge products.

What can we learn from this innovative and productive developer?

Focus & Measure Productivity

Carmack on focus:

Focus is a matter of deciding what things you are NOT going to do.

From Brian Hook’s excellent blog post “Smart Guy Productivity Pitfalls”:

I remember Carmack talking about productivity measurement. While working he would play a CD, and if he was not being productive, he'd pause the CD player. This meant any time someone came into his office to ask him a question or he checked email he'd pause the CD player. He'd then measure his output for the day by how many times he played the CD (or something like that -- maybe it was how far he got down into his CD stack). I distinctly remember him saying "So if I get up to go to the bathroom, I pause the player".

Making Time for Deep, Uninterrupted Work

From Cal Newport’s blog, via “Masters of Doom”:

John Carmack, adopted an aggressive tactic to increase his effectiveness while working on his breakthrough Quake engine: Carmack, seeking a break from distraction, began to shift the start of his workday one hour at a time, until eventually he was starting his programming in the evening and finishing before dawn.

John Carmack working

Work Ethic: Embrace the Grind

From “The Rise and Fall of Ion Storm” on

"Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it. If you aren't sure which way to do something, do it both ways and see which works better."

At the Oculus Connect 4 conference (October 2017), Carmack had a message for VR developers:

Embrace the grind...It takes more than just 'be bold'; you have to actually work really hard. You've gotta fill your products with 'give a damn'.

In “Masters of Doom”, Chapter 16, page 292:

In the information age, the barriers [to entry into programming] just aren't there. The barriers are self imposed. If you want to set off and go develop some grand new thing, you don't need millions of dollars of capitalization. You need enough pizza and Diet Coke to stick in your refrigerator, a cheap PC to work on, and the dedication to go through with it. We slept on floors. We waded across rivers.

Leverage Simplicity

Doom 3 BFG Screenshot

“Doom 3 BFG” was written in C++ - a vast and complex language. Rather than make use of some of the more advanced features or C++, id software chose to use a subset instead. See Fabian Sanglard’s excellent code review of Doom 3 BFG.

In 2004, an interview for “The Making of Doom3” book:

You look for the synergies between the different areas and the ways you can simplify things down. There's always a strong desire with functionality to kind of pile things down. Historically, I always resisted this. I've been one of the big believers in keeping it as simple and clear as possible. It pays off in maintenance and flexibility and stuff like that. ...snip... Sure, new features are great; but what's not always obvious is that every time you add a feature, you are at the very least increasing entropy to the code, if not actually breaking things. You are adding bugs and inefficiencies.

In the 2012 QuakeCon Keynote, Carmack said:

I would like to be able to enable even more restrictive subsets of languages and restrict programmers even more because we make mistakes constantly.

As an aside, it’s interesting to note that restricting language features was a core design principle of the Go programming language.

Learns from & Recruits More Experienced Developers

Michael Abrash quote on working on Quake

When developing Quake at id Software, John Carmack managed to recruit one of his graphics programming mentors, Michael Abrash.

As documented in the WIRED article “The Egos at id”:

Once John Carmack's guru, Michael Abrash is currently his right-hand man. They work side by side, Carmack writing engine code and passing it to Abrash, who optimizes it for elegance and efficiency.
One of the world's best-known programmers, and author of seven books (including Zen of Graphics Programming), Abrash wrote a column in the late 1980s that had a formative influence on the young Carmack and Romero. Shortly after Doom's release, Carmack offered his mentor a job. Comfortable at Microsoft, with an interesting pet project on the horizon, Abrash declined.

Carmack and Abrash today both work at Oculus VR.


Carmack on sleep:

Losing sleep to hit a deadline the next day is valid, but it isn't a productivity enhancer. I have always needed a full 8hrs for good work.

Decision Making

An interesting discussion about Carmack’s decision making process is revealed in an interview from the defunct website “”. Luckily there is an online copy along with many other interviews (PDF format):

Gabe Newell (Valve Software): John has consistently made very clear decisions about the scope of projects id has undertaken, which I would say is one of the main reasons id has been such a consistent producer over an extended period of time. Not having spoken with John about it directly, I think I understand his rational for focusing id on the Doom project. For the benefit of other developers, are there a couple of heuristics John uses to decide what does and doesn’t make sense to undertake on a given project?

John Carmack: The basic decision making process is the same for almost any choices: assess your capabilities, value goals objectively, cost estimate as well as you can, look for synergies to exploit and parasitic losses to avoid. Maximize the resulting values for an amount of effort you are willing to expend.

Computer games do have some notable aspects of their own, though. Riding the wave of Moore’s Law causes timeliness to take on a couple new facets. Every once in a while, new things become possible or pragmatic for the first time, and you have an opportunity to do something that hasn’t been seen before, which may be more important than lots of other factors combined. It also cuts the other way, where something that would have been a great return on the work involved becomes useless or even a liability when you miss your time window. Several software rendering engines fell into that category.