Develop your autopilot

I was once asked during an interview, ‘How long until I’m leading the department?’ That question has stuck with me for years. As has the way the interview ended: with an entry-level candidate quite unimpressed that we were the latest in a long line of companies unwilling to give them a senior title and salary right out of the gate.

The interesting thing is that, to the uninitiated, they may have seemed like a great hire; they knew all the latest fads and buzzwords. But beneath their understanding of all the best practices they should be doing was a lack of understanding of why they should be doing any of them.

And when it comes to seniority, the why is perhaps the only thing you simply must master. When your day-to-day decisions affect the company’s ability to make revenue (and therefore the livelihoods of your colleagues), you had better be able to explain every little decision that you make.

So what makes a good senior?

I have always found a good senior to be quite boring. They often blend into the background, and are definitely not the ‘rockstars’ on the team (though hopefully you don’t have any rockstars).

They are the ones who make plain, sensible decisions. They choose MySQL over the hottest new DBMS because they remember the project that limped on in production for ten years as support for its dependencies ended one-by-one. They know how long poorly written code can stick around for.

They have spent time working in cross-functional teams solving problems that affect the company’s bottom line. They understand the impact of this work and recognise that development does not occur in a silo — if their company makes a product to sell insurance, they understand that they work in the insurance industry and seek to learn the ins and outs so they can write the best damn insurance software on the planet.

They are naturally wary when talk about The Big Rewrite rears its head, and know when time is better spent on MVPs and applying the strangler pattern to solve the underlying problem. They also understand the difference between an MVP and a POC, and the difference in code quality that is acceptable for each.

They can explain highly technical matters in simple terms and accurately convey their sense of distress over Something Being Done Wrong without resorting to exaggeration or hyperbole. And they can do it without seeing those on the other end of their explanations as The Enemy.

They view documentation not as a chore, but as a brilliant way to help themselves and their colleagues. And they know that descriptive variable names and comprehensive docblocks do the trick 99% of the time.

When reviewing others’ code, common vulnerabilities jump out of the screen at them, plain as day.

And most importantly: all of this happens without any conscious effort. They effectively develop an autopilot.

Honing your autopilot is perhaps the most important piece of professional development you will ever undertake. Because as you edge closer to seniority in title, you step away from the various safety nets of juniority, and every decision you make has far higher stakes.

So how do I develop this autopilot?

Developing your autopilot takes time and there’s no way around that. It is for this reason that ‘seniority’ and ’time served’ have a correlation and are often confused. But it is not just about spending time on the job — you also have to spend that time wisely.

Whether you stay in the same company or hop between many companies, it is essential that you are always moving forward. You should be aiming to constantly operate outside of your comfort zone; to fail appropriately and to learn from those failures.

Over the course of a decade, you should aim to acquire ten years of experience, not one year of experience ten times in a row.

It may seem that job hopping is the quickest way to achieve this (and it may well be), but I would argue there is something to be said for sticking around in a role, at least for a few years.

By sticking around, you get to see where you are truly awful. That fancy new system you architected that solves all of the company’s problems? Turns out it causes even larger problems at scale. But if you move on before the shit hits the fan it’s always going to be the next person’s problem, and you’ll never have the opportunity to see exactly where you made mistakes and what you could have done differently.

Yes, it’s going to be uncomfortable confronting your failings, and fixing them will be an awful, humbling experience. But you’ll also get to see the full picture (it wasn’t just a broken method, it also stopped clients placing orders!), and the next time you architect something similar your autopilot will course-correct the moment you start to err.

Getting things wrong and learning from them makes for an attractive senior engineer because there are less unknowns — you messed up in X way, reacted in Y way and did Z thing the next time.