Career advice for engineers who aren't supposed to exist

Hey there readers! This e-mail is another missive from Simpler Machines, a newsletter about making software and how to get better at it. I'm Nat Bennett, roaming test-first mercenary and Elixir student, and today we're returning to one of my favorite topics: People who are a better at the "advanced" parts of software engineering, like design, than they are at the "beginner" parts that are mostly about doing the keyboard tippy-taps real fast.

Before we get into that though, a couple of programming notes.

Are you hiring? Do you want to hire the kind of thoughtful people who read this newsletter? You can now submit a job listing for me to include in the newsletter. It's "pay what you want" for now while I'm testing this.

I've also just published another YouTube video. This one's about setting up your own Vim config with Jesse Alford.

Engineers who aren't supposed to exist

I've got some pieces in various states of drafts buuuut I saw this "System Design Explains the World" piece for the first time yesterday and immediately started writing a response in my head. So I thought, okay, I'll write a short thing and get that out. And then it turned into 2,000 words? Anyway, uh, enjoy!

My attention was drawn to this topic by Charity Majors, who also highlighted part of the piece that jumped out at me.

That quote comes from a discussion of a pattern that I also noticed during my days in the promo mines.

There were two groups of misfits:

People who maxed out as a senior engineer (building things) but didn't seem to want to, or be able to, make it to staff engineer (translating business problems).

People who were ranked at junior levels, but were better at translating business problems than at fixing bugs.

But the part that really blew my mind was this line.

People in group #2 weren't supposed to exist.

Because... yeah. I'm in this category, and man, I confused the hell out of perf systems back when I was trying to get delicious promotion pellets out of them.

I remember this one time, a couple of managers had built an elaborate and detailed system to standardize performance evaluations across the organization. There was a Google form that fed into a spreadsheet, and that spreadsheet generated a heatmap, and it showed your relative skill level across a bunch of categories of engineering skill. The core areas were "Technical Execution," "Process," and "Collaboration," and then there were a bunch of additional areas for things like "Technical Judgement" or "Operations" that in theory were mostly involved in evaluating very senior engineers.

So my managers goes around and has my teammates fill out the feedback form and came back with a heatmap that honestly described me pretty well. There was just one, small, tiny problem: The way my heatmap was filled out wasn't supposed to be possible.

I maxed out Technical Judgement. Just straight across, every question, every teammate, went, "Yep, yep, Nat does that, yep, yes, oh absolutely yes, all the time." That whole column was deep green. If you were just looking at that column you'd think I was super senior, Principle Engineer level, maybe there's one or two people at the company like this.

What I didn't have was maxed out Technical Execution. My Technical Execution was somewhere around "strong beginner." Good pair, can make progress on well-scoped stories, but I wasn't someone my team relied on consistently to lead the hardest stories.

I don't remember the exact quote but my manager almost literally told me, "Your heat map isn't supposed to exist." The way the system was built, the assumption was that Technical Judgement and Technical Execution both start out pretty low, then Technical Execution grows rapidly, and then over time Judgement catches up.

I ultimately got a pretty good outcome from that system, but at the time this was the source of a lot of angst. Was the system unfairly holding me back? Or was the system right that Technical Execution was the foundation of engineering skill, and I needed to catch up? Would I ever be able to catch up to these kids who'd been programming since they were 14?

Was I a good engineer or not?

So this is a problem that I've thought about a lot.

This is very "advice to my younger self" stuff but if you recognize any of this and you're wrestling with it in your career right now, here's what I think you should do:

• Keep your eye on the long view
• Don't let yourself get caught up in performance review
• Get faster with deliberate practice
• Get faster by building stuff
• Stay technical

Keep your eye on the long view

In my first technical job I made $80k a year. A few years later my salary doubled, then tripled. I don't know for sure how it is today but when I looked on levels.fyi I see basically the same shape. In our industry compensation grows so much between "entry level" and "mid-career seasoned professional" that the compensation that you make in your 30s will totally dominate your lifetime earnings, vs. what you make in the first few years of your career.

How fast you get to that "mid-career, seasoned professional" salary range matters a lot less than

• Getting there at all
• Having a high ceiling and continued growth potential once you do get there

And being one of these "shouldn't exist" strong-system-design-types is a huge advantage once you get into this range. As long as you don't let being frustrated about how hard it is to get promoted to senior chase you out of the industry entirely.

Ignore the ladder

So I don't think anyone consciously does this on purpose but I think in practice perf systems are effectively design to distract you and stress you out. It's easier in some ways to manage people who are very focused on the career ladder, especially when you're managing lots of 'em.

And anyway, we're status-obsessed social animals: You give me a ladder and I'm going to try to climb it.

This is a trap!

Don't ignore the ladder to the point of like, not meeting the basic requirements of your level, and sometimes it's appropriate to spend some dedicated time focused on demonstrating that you've met the requirements of the next level above you. But it's really easy to get way too sucked into thinking about the ladder, and you're probably going to be happier, without giving up much equity, if you err on the side of thinking about it less than thinking about it more.

You need to take a really mercenary view of your company's performance system. It's not an accurate judgment on your worth as a human or as an engineer. It's a weird box that money comes out of occasionally.

Get faster with deliberate practice

So this is a little bit in tension with the advice above, since what I'm about to say is "spend some time getting better at the thing that the ladder asks you to do." But there's a mindset trick here.

Don't think about "what do I need to do to get to the next level?" Instead think, "What will make me better and faster at building stuff?" If you need to obsess over something, obsess over getting faster. Even if your heart is really, truly in debugging, system design, people problems, all that good stuff– being able to demonstrate your ideas quickly and fluently in working code is a general purpose skill that will help you achieve your goals.

Deliberate practice to get faster includes

• Practice typing speed, especially the weird programmer errors, with something like typing.io
• Make and study flashcards for your editor's keybindings
• Make and study flashcards for your main language's syntax
• Make and study flashcards for your main language's standard library, and any frameworks or libraries you use a lot
• Invest in blub studies; learn things you already know really well
• Get good at using git
• Invest in understanding and controlling your developer environment by writing your own workstation setup script

None of this requires the dreaded "side project." (More on that in a minute though.) I like flashcards specifically because you can schedule 15-30 minutes for yourself during the day and do your practice. You don't have to do any project management work or decide what to build.

Get faster by building stuff

I'll admit it: I'm not great at building things on my own. I'm not one of these people who's always itching to, I dunno, write a parser, or build an app for a hackathon. Even when I do get an idea, I'm okay at starting stuff but I always get like a week into it, get bored, and wander off to something else before finishing it. When I'm working full time I'm not much of a "side project" person. I want to write code during the day job and then do other stuff with my time.

But for improving raw technical execution, and especially your perceivable technical execution, it really does help to have built a couple of projects in your domain and toolset from "first commit" to "a meaningful program."

Look for excuses at work to start projects with scratch. Make little websites or little CLI tools. Make scripts! Make them as small as you possibly can – something you can take from "first commit" to "it does a useful thing" in a day or a week. Then write another. The most useful thing is to get reps in of the entire product development cycle.

Stay technical

If you're better at whatever this stuff is that's not technical execution – "glue work" or system design or project management or whatever else you want to call it – there's going to be a temptation to get off the engineer track. To switch into some kind of management– project, program, people, whatever. You may also be drawn to "higher level" engineering, one of these flavors of roles where you're still technically an individual contributor, but you spend more of your time scoping work and writing docs and talking to people.

I can't speak for everyone but if you're at all like me this is also a trap.

Building stuff is fun. Fixing stuff is fun. Being able to do this fast is very fun.

Management is, uh, not fun.

Getting faster is hard. Getting good at doing the dumb bug fixing stuff that you can tell doesn't really matter as much as the stuff that you're already good at is hard and scary and maybe even feels kind of pointless. You'll see new grads come in and they're already better than you at tippy-tapping out code and you'll think, is there any point? Will I ever actually get good at the tippy-taps?

And there's this temptation. There's some other job and it's right there, and you'll make more money immediately, and your manager thinks you should at least try it, maybe it's a good fit, and you'd get to stop fighting to be better at fucking typing.

But the thing is, if you push through that fear and just do the work, you'll realize pretty quickly that getting faster is fun, and pretty much immediately rewarding. And you can still go switching into Whatever Management later – you haven't given up any optionality by getting better at cranking out code.

Management, in contrast, is not immediately rewarding. No matter how good you were at the parts of management you were doing as an engineer, you're going to get reset back to "brand new and bad at this." For at least a year. And people are going to be mad at you for being bad at it. And it's going to be harder – though absolutely not impossible – to get back to being a regular engineer, especially if you don't have that base of skill & confidence from having spent some time as a Solid Executor.

So in general I think you should ignore anyone who's encouraging you to go into management, and put off switching as long as possible. When engineering gets boring – when you find yourself building yet another damn Rails app – then, that's the time to start thinking about giving management a shot.

As long as it's just scary, though, keep at it.