You know the Golden Child Engineer, the favourite of the Director of Engineering? He’s that guy (and it’s basically always a guy) who’s the company Teacher’s Pet? The software developer who gets promotion after promotion?

You’re not that guy. With one fun exception, I haven’t been either. And I’ve worked at a lot of companies.

You watch to see who gets promoted. So do I. It’s a great game, especially if you work different places and see how it changes. I’ve also interviewed hundreds of software developers over the years. Which means I’ve had several different Directors of Engineering tell me exactly how good at coding is “good enough.”

That means you and I have watched who gets promoted and how often that’s about coding skill.

Not how often they say it’s about coding skill, of course. But you knew that.

The First Time You’re “Good Enough”

Once you’ve been a professional developer for a few years, if you’re any good, your coding skill is “good enough.” You won’t pass 100% of your interviews, but you won’t have trouble getting a job. It won’t get you an automatic promotion, but it won’t hold you back from a promotion you were going to get anyway. You’re not the Golden Child. I hope you’re also not the manager’s least-favourite. But even if you are, that usually just means you won’t get a promotion.

Your coding skill is “good enough,” and that’s what I mean by “good enough.” You follow?

That means that one of the times your coding skill matters is when getting to “good enough.” Some folks come out of university being that good, but it’s probably around half and half. You may have to do a lot of interviewing for your first coding job to luck out. Then you stay at that job for a few years, and by the end, no question, you’re good enough. Then you can stop worrying about it for awhile.

You spend a few years bumming around and learning to be “professional.” You learn to use source control consistently. You learn to write tests. You learn how to talk to your team members and how often to tell your manager what you’re up to and how to respond at the morning stand-up meeting. Maybe you get better at coding, too, but it’s not really mandatory.

And at some point you get promoted from “junior dev” (or local equivalent) to just “dev” (or local equivalent.)

That’s fine. The pay bump is nice. There’s a certain amount of muttering about how “senior” is different, but it’s also clear that they won’t promote you for awhile. So you have a few years to figure it out. Mostly there isn’t much change in what kind of projects you’re doing or how people treat you.

The Ugly Secret

Which brings us to the second time your coding skill matters: making it from just “dev” to “senior dev” (or local equivalent.)

Those are pretty much the only two. If you’ve been batting it out of the park and becoming an amazing coder because your coding skill is going to get you promoted to CEO, I have bad news. And it rhymes with “you’re gonna have to drop out and start your own BUMP-any.”

Or you could keep climbing the ladder. While there’s a long period after senior where nobody seems to know what comes next (see video below), you can do it.

But after that, it’s not about coding skill any more. As John Allspaw points out in my favourite article about being a senior engineer, from there on out it’s about communications skills.

Which is to say: once again your coding skill is “good enough.” And from there on, that “good enough” lasts approximately a lifetime.

Were you keeping count? There were only two times it mattered.

The Objections

I’m psychic. I’ll prove it:

Once this post has been up awhile, the comments are going to be full of smug developers saying, “oh, that’s not how it works at MY company.” (Also maybe less-smug developers sighing deeply that it is how it works at their company. But they don’t leave comments as often.) The smug developers will sound pitying, to imply that the problem is that I’ve never worked anywhere as elite and wonderful as where they work.

See? Psychic.

But because I’m psychic, I’ll also tell you why they’re wrong.

I could say, “I’ve talked to an awful lot of friends at Facebook, Google, Amazon, Netflix and many small startups and I know whereof I speak.” And that would be true, but it’s not the reason.

Or I could say, “your process promotes people in a weird way with ulterior motives and then claims it was for their coding ability.” That’s basically true too, but it’s also not the reason.

Until you become a senior engineer, you’re being judged as an engineer, and you’re being judged by engineers. That’s why you have to demonstrate coding skill for those two major transitions.

And after you’re a senior engineer, you’re in a different category of expense and strategic value. The company suddenly cares about what you do. You are supposed to have changed from “may potentially do something useful” to “is currently accomplishing something the company cares about, and doing it well.”

Engineers no longer judge that. Instead, people with titles like “Director of Engineering” or “Senior Vice-President” or “CTO” judge that. And those people are basically managers and businesspeople. They do not (in a well-run company) spend their time coding.

And that means levels above “senior” are judged by managers and businesspeople, on communications skills.

There was a wonderful, hilarious, beautiful Quora question I saw many years ago. A newly-graduated programmer was asking, “what if I’m a better programmer than the founder of the startup I join?”

He was asking, you see, on the assumption that it wouldn’t make sense to have a random programmer be a better coder than the technical founder of a startup. He was asking, in other words, on the assumption that a startup is a sort of Thunderdome for programming ability, where your rank is based on raw coding ability. And so if you were better than the founder, clearly the right and appropriate thing would be for the founder to step down so that you could be in charge with your better coding ability.

Above a certain rank, it’s not about your raw coding ability. There are only two times you’ll have to get better. After that, it’s all about the communications skills and business skills. No matter what the smug developer in the comments says about working at Google, Google isn’t Thunderdome-for-coding-skill either.

Though from now on, when anybody asks you “who run Bartertown?” you have my permission to yell back, “Larry and Sergey!”

Okay, So…?

There are a few reasons you might care about this.

You might be trying to get your first job. Bad news: straight-up coding skill is likely to be one of your challenges. I sell a book that could help. But mostly what you need is practice. The book, which is 100% optional, is just about how to practice more effectively than coders generally do. You ever notice how we’re bad at that? We really are.

Or you might be trying to settle in comfortably and let your career be a slow set of promotions by seniority. Bad news: while you don’t need more coding ability after “senior,” there’s still a reason it’s hard to get promotions after that. Engineers have a mid-career slump that can be pretty rough. The hard part is figuring out that tricky transition from “coding skills” to “business skills” so you can do what you want to (write code) but also what the business wants (communicate, mentor, persuade, document…)

Or you might be a just-a-dev (not junior, not senior.) In that case, you’re at that inflection point where suddenly your coding skill matters again. You’re going to need to convince folks you’re good at coding. In high-level languages with good library support (e.g. Ruby, Python, Node.js, Go, etc.) a lot of what you need is the ability to work and debug down into your frameworks and dependencies. You need to get good at not just your own code, but the code it interacts with constantly. If your stack includes Ruby and Rails then I have a book for that, too. But if you’re okay with slides, there’s a free workshop you might want to look at first.

No matter what point you’re at, keep in mind that you’re committing to long-term mastery, not just making this one transition. A lot of this feels big and difficult, because it is. This isn’t a problem you’ll solve in a week or two. University (or boot camp) took you some time. Going from junior to senior took some time. Getting from senior to the next level takes at least as long — it took me around 6 years, depending how you measure.

So settle in. This is a lot of work and it takes a long time. But you’ll get there — especially because now you know a little more about the obstacles along the way.