This is the fifth part in a series about achieving mastery as a software engineer. The first part described senior software engineers. The second part discussed common flaws that could derail one’s growth. The third and fourth parts got as specific as possible about the skills you need as you develop, from junior, to mid, to senior engineer. In this part I’ll discuss true mastery, what it means, and how you get there.

Just kidding.

Actually, I don’t know how to get there. With smarts, talent, study, and huge amounts of directed energy, it’s possible to get to the “intermediate mastery” I described in the previous post. That’s a very high level. It’s what most of us strive for. And “achieving” it (though of course it’s really more of an asymptotic lifelong study) is a worthwhile goal. But there’s a difference between chess masters and grandmasters, first and fifth degree black belts, the master software engineers and the merely great. And I’d like to spend this post ruminating a little on why they are the way they are, and how one might scale that particular Everest.

What am I even talking about?

They’re out there. They’re better than you. They were better twenty years ago than I am today or ever will be. Maybe it’s natural ability. Maybe it’s luck in education or upbringing. Maybe they have a secret recipe for improving rapidly and learning utter fearlessness. I don’t know. But I’ve met ’em, and they aren’t “smart”. They’re abso-flutely fugging brilliant.
– Steve Yegge, Done, and Gets Things Smart

If you haven’t worked in an organization in which there’s one engineer whom even other senior engineers nervously make Chuck Norris jokes about (“When so-and-so breaks the build, the build apologizes and fixes itself!”), then you may not know what I’m talking about. And honestly, if that’s the case then you should probably start looking for a new job, because you haven’t worked in a great engineering organization. Or perhaps you are that engineer, in which case you should drop whatever you’re doing and call me right now because boy have I got a great job for you!

Ahem.

Anyhoo, the point is that there’s a certain class of engineers who’ve achieved a certain, rarefied level of enlightenment that makes normally snarky, cynical peers into wide-eyed fan-boys and -girls. It’s not clear how they got there, or how they do what they do, but they’re significantly and demonstrably better than even the best engineers on the “normal” scale we use to think about these things. They program faster, better, and with fewer mistakes (though their mistakes can be impressive). They’re like Zen coding masters, at one with their machines, Vulcan code whisperers mind-melding with the compiler.

As I said, I’m not one of these people, but after having worked with a number of them, I have a couple of ideas about what makes them tick. I don’t claim that this is an exhaustive list, or that ticking off these items will get you there. But I’m also not saying they won’t.

Command of Details

We’ve already discussed the types of skills needed to achieve mastery. But there’s a difference between someone who needs to check the manpages to remember the command line option to do X or Y, and someone who just knows it. Every time you have to look something up, you have to break flow, switch context, look up the information, try it a couple times to get it right, actually use it, then resume what you were doing. It may feel like just a minute or two, but you’ve just lost another 15 minutes trying to get back into flow. Masters have a complete command of their tools – they don’t just Google everything or look details up on StackOverflow (though they certainly can and do when faced with unfamiliar problems) – they have more knowledge at their fingertips, and are able to use it without intermediate steps, or even conscious thought.

Depth

It’s not enough to be a “jack of all trades, master of none.” Achieving mastery means applying yourself to one or more areas with such… abandon… that you understand them at a disturbingly deep level of detail.

Focus

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”. You know what’s pretty hardcore? Thinking that going to the bathroom is essentially the same as fucking off.
– Brian Hook, Smart Guy Productivity Pitfalls

The best engineers can shut the world out for hours at a time. They turn off the phone, close their email, turn off notifications, log out of instant messaging, set up their workspace so that they don’t have visual distractions, and either shut the office door or (more commonly) put on headphones so they can ignore everything around them.

During single-minded work time, people are ideally in a state that psychologists call flow. Flow is a condition of deep, nearly meditative involvement. In this state, there is a gentle sense of euphoria, and one is largely unaware of the passage of time: “I began to work. I looked up, and three hours had passed.” There is no consciousness of effort; the work just seems to, well, flow.
– DeMarco and Lister, Peopleware

Lots of people prefer to work in open plan offices. They like to be in an “energetic” (i.e., noisy) team environment where people are constantly asking each other questions, having nerf wars, shouting over cubes, etc. They may even think that this makes them more productive, but this is magical thinking. If you can’t create flow, you can’t get to peak performance, and distractions are deadly to flow. If you enjoy the cameraderie of hanging out with other engineers, shooting the shit and getting help with your problems, then eat lunch together or have a happy hour after work, don’t try to program in an actively hostile environment.

Let me be clear: you will never achieve peak performance, and by definition peak experience, if you’re constantly getting interrupted. You will never experience the most rewarding, exciting, deep, joyful experiences of your life if you don’t create an environment in which you can achieve flow. This is true for coding, writing, art, meditation, or anything else that requires deep individual thought. And if you scoff at the idea that you can have some of the most rewarding, exciting, deep, joyful experiences of your life while coding, then you’re in the wrong goddamn job.

You also need to respect other people’s flow. If you have a question, first try to figure it out on your own. Then, send an email – people can ignore email, and get back to you on their schedule. While you’re waiting, work on something else – it may feel like you’re blocked, but there’s almost always something else that you can work on while waiting for an answer. Try as hard as possible to wait until someone is already out of flow (lunch, before or after meetings, coffee time, etc.) before buttonholing them. Don’t have loud conversations next to other people’s desks.

This may all sound incredibly pedantic, but it’s also probably the single most important thing you can do to improve your game.

Ability to hold many variables in one’s head simultaneously

A good programmer working intensively on his own code can hold it in his mind the way a mathematician holds a problem he’s working on. Mathematicians don’t answer questions by working them out on paper the way schoolchildren are taught to. They do more in their heads: they try to understand a problem space well enough that they can walk around it the way you can walk around the memory of the house you grew up in. At its best programming is the same. You hold the whole program in your head, and you can manipulate it at will.
– Paul Graham, Holding a Program in One’s Head

This is the part of “command of details” that relates to your code, as you’re designing or writing it. Every time you have to look something up in your code – a function name, a variable, an algorithm – you have to start your logical process over. This takes time, and prevents you from thinking more complicated thoughts.

The most influential research of experts’ memories focussed initially on chess experts. In their pioneering studies Chase and Simon (1973) showed superior memory for chess positions by chess experts. Chess players ranging from beginners to international masters were shown a position from an actual chess game for a brief time (normally 5 seconds) and then asked to recall the location of all the chess pieces. The ability to recall increased as a function of chess skill. Beginners at chess were able to recall the correct location of about four pieces, whereas international-level players recalled virtually all of the more than twenty pieces.
– K. Anders Ericsson, Superior Memory of Experts and Long-Term Working Memory

The more experienced you become, the more you perceive larger patterns instead of individual pieces of the pattern. Being able to think in larger patterns is both a result, and enabling tool, of experience.

Playfulness

Wait. What? Playfulness? Ok, this post just went in a seriously strange direction. What do you mean, being “playful” is going to help turn me into one of these hard-core, Terminator-like coding deities?

Um, sort of.

I went on to work out equations of wobbles. Then I thought about how electron orbits start to move in relativity. Then there’s the Dirac Equation in electrodynamics. And then quantum electrodynamics. And before I knew it (it was a very short time) I was “playing” – working, really – with the same old problem that I loved so much, that I had stopped working on when I went to Los Alamos: my thesis-type problems; all those old-fashioned, wonderful things.

It was effortless. It was easy to play with these things. It was like uncorking a bottle: Everything flowed out effortlessly. I almost tried to resist it! There was no importance to what I was doing, but ultimately there was. The diagrams and the whole business that I got the Nobel Prize for came from that piddling around with the wobbling plate.

– Richard Feynman, Surely You’re Joking, Mr. Feynman!

Playing is fun. It’s low risk. It doesn’t matter if you screw up, because you’re just twiddling around. And really, what’s the worst that could happen? You usually can’t screw up that badly when you’re just fooling around on your own time.

When you like doing something, you tend to do it more often. When you do something a lot, you get better at it. And, of course, you usually enjoy doing things you’re good at. Great engineers play with new technologies, approaches, devices, OSes, ideas, tools, methodologies, languages. They do it because it’s interesting, because they’re having fun, because it’s cool, because they were curious, because why not? They play obsessively, build tools for themselves on mobile devices, tweak and customize their workspaces, and frequently have a graveyard of consumer electronics somewhere in their house (much to their spouses’ dismay).

A child loves her play not because it’s easy, but because it’s hard.
– Dr. Benjamin Spock

Playing requires a certain fearlessness, a disregard for consequences. It doesn’t mean irresponsibility – rather, a willingness to try something different, to move things around, or completely change an approach if the old way isn’t working.

Continuous Learning

Always reading one more article, one more technical book, learning another language or obscure detail of something they already know. Always trying out new technologies, learning the basics and sometimes getting sucked in (mobile development seems to do this a lot).

There’s always more to learn, and these people don’t just slog through technical books and learn new technologies because they’re trying to get the high score on some cosmic learning video game – they do it because they’re obsessed with technology, and love learning more about it. Like sports fans slavishly memorizing stats on their favorite teams and players, they do it for the love of the game.

Put another way, you can’t just grind for a couple months or years, level up, then stop and expect to stay at the top of your game. This is a lifelong quest, and if you don’t love the process, you’re not going to be able to sustain it.

What this means for you

Change is hard. If you’re a senior software engineer, and you want to get to the next level, I’m not entirely sure what to tell you. Everything in this blog will improve your skills, with focus probably being the number one most important item. Will it get you to true mastery? Will people start making Chuck Norris jokes about you? Will you achieve Neo-like control over the Matrix? I have no idea, but it’s a good place to start.