The 8 Secrets of the Top 1% of Software Engineers

The secrets of the masters

To become one of the best software engineers in the world, you need to emulate the top 1%. I’ve had the privilege of working with some of the best, including Kent Beck at Gusto and the first engineer at JetBrains. Today, I’m going to share their secrets in eight key areas, starting with the first one.

№1 — Master the art of ambiguity

Many software engineers require clear instructions to be productive. They may remain idle until they are assigned a project or, worse, individual tasks. It is acceptable to be given a complex problem with multiple unknowns to solve. But it’s even worse to sit around until you’re spoon-fed in a sauna or Jira ticket spelling out exactly what you need to do.

In fact, this is a pretty good way to approximate an engineer’s level. Usually, the fewer the instructions on the task, the more experienced, higher level, and better paid the developer.

Companies want go-getters, they want people who can take vague directions like “Our tests are flaky or Our builds take too long or Our AWS bill is too high.” They’re not told how to solve the problem, just what the problem is. It’s on them to figure out the intricacies and make it happen.

So how do you thrive in ambiguity?

Well, the first step is to just accept it. Don’t shy away from responsibility because you don’t have all the answers. The truth is, no one does.

I used to believe that I was a bad engineer because I couldn’t complete an entire project on my own, while some incredibly skilled staff engineers could. However, this is not the case. Leaders don’t care how a project is completed, as long as it is finished on time without introducing excessive technical debt and produces a successful outcome.

Highly skilled engineers invest significant time in thinking and designing before writing any code. They consult with a variety of stakeholders to gain a comprehensive understanding of the problem and define success criteria.

This is essential because a vague problem definition leads to an unclear definition of success. For example, if leadership tells us that our AWS bill is too high, we know we need to reduce it, but by how much?

Anyone can make up a number and say they want it to go down by 50% per month. But is that a reasonable goal? Is it attainable? And more importantly, does it make sense?

Maybe it’s possible, but not at the cost of engineering, time, and effort. Everything has a price, and the best engineers understand trade-offs.

Once all the planning is done, the pros and the cons, the best engineers architect a robust system to cover all the important cases. No coding yet all this is done on design docs and tech specs, which they then send out for feedback. They get all the relevant parties to comment and once they have adequate buy-in, only then do they start coding, usually with a team of engineers.

№2 — Become a problem-solving expert

The best software engineers are self-driven and proactive. They can identify the most critical problems facing the team or company, and they have the skills and persuasiveness to convince leadership to prioritize those problems.

Finding the most important problems to solve is the hallmark of a top-notch engineer, and they achieve this by regularly exploring the codebase, having informal conversations with team members, and analyzing metrics.

Their goal is to understand pain points. These can be technical bottlenecks or product shortcomings or even just things that give developers the ick, a word I learned quite recently and then they surface these issues to the PMs or general leadership and they’re often met with the same question. Okay, but why?

You have to convince people that the thing you’re trying to solve is, one, an actual problem and two, big enough of a pain point that we should prioritize. This isn’t easy to do because engineering projects usually take months and are very costly because engineering time is expensive.

So, how can you become skilled at both finding and convincing?

To discover new problems and solutions, you need to invest time in learning about the system. This involves reading code, reviewing pull requests, and exploring unfamiliar parts of the codebase.

Onboarding yourself and reading the documentation can also give you a fresh perspective. Just like the person in the air freshener commercial who can’t smell their own smelly apartment, the more you interact with a software system, the more biased you become. A new perspective can make all the difference in identifying problems and solutions that others may miss.

As for convincing people and rallying them towards your mission, well, that just takes practice. You have to be persuasive and in this day and age, data is king.

So when you say something is slow, tell me by how much, and if something costs too much, then go find out what similar-sized teams are paying and then prove to me that our spend is multiple times that. The more data you have in writing, the stronger your case will be. It is also helpful to have the support of experienced engineers.

№3 — Master your field.

The top 1% of software engineers are the go-to people for certain aspects of a company. They’re responsible for entire product lines and teams of engineers and if something goes wrong, well, the buck stops with them.

But how do you build so much trust?

If you have mastered the first two secrets, you are well on your way to becoming an expert in your field. By learning how to first find and then break down ambiguous problems into bite-sized chunks you can make forward progress.

You inevitably spend a lot of time in one area, and the deeper you go, the more complexities you unlock and the better you understand that system, and at some point you’ve just spent more hours than any other person at the company and so you know the most about that one thing the good, the bad and the ugly.

Hopefully, you don’t hate the area you’ve now learned so much about because then you’d have to start from scratch somewhere else. The more you get invited to meetings and roped into discussions, whenever your system is mentioned, the more people start associating you with that area and if you’re not already that person, well then start faking it till you make it.

Even if you do not feel like an expert yet, project confidence and volunteer to help with problems and answer questions. Don’t wait for someone else to do the work; become the go-to person for that area. Dive deep into the details and find the answers.

Top engineers don’t wait to become experts. They just act like experts and then one day they become them. Doing all this takes time, and the top 1% of engineers know how to be productive.

№4 — Make your customers your top priority.

The best engineers are customer-obsessed and always keep in mind who they are building for. They don’t build things because they think they are cool or technically challenging, but because they solve real problems for real people, and though 99% of engineers understand this, they don’t live it or breathe it.

They think it’s the product or the user experience team to understand the customer and figure out what we should build, but it’s not. The best engineers are product minded and this doesn’t mean they’re building a consumer app.

Everything is a product, even the gnarliest infra team or the backend developer experience team, they also have a customer. It just happens to be a technical person.

While most engineers get their projects done and then move on, the top 1% of engineers continue collecting feedback. They check in from time to time and understand how their customers are liking the product.

Then they suggest improvements and go on to prioritize them. They realize that you can always do better and delighting customers is the best way to make more money, which means more recognition, and then that means better pay.

№5 — Keep it simple.

Software engineers should keep in mind that they are building products for real people, which should deter them from overengineering. However, this can be difficult, especially for engineers who enjoy complex challenges. It is important to remember that we have limited time and resources, and we cannot build everything.

We should avoid the temptation to overengineer systems or make them unnecessarily abstract, especially when a simpler solution would suffice. For example, instead of overengineering a system to scale to hundreds of millions of users, we should focus on building a simple form for a web page.

Build for what you need now and that doesn’t mean be dumb and purposely make your life harder in the future, but don’t plan months or years in advance.

It is better to ship a feature early and iterate on it slowly, rather than spending a long time developing something that no one ends up using. It is more valuable to have a product with thousands of users that can be gradually improved than to have a perfect product that no one uses.

The biggest mistake that amateur software engineers make is failing to scale their systems. They often think that the real world is like a system design interview, where they can simply throw CPUs, cores, and expensive systems at a problem to solve it.

However, the top 1% of software engineers are not the best coders. Strong programming fundamentals can be helpful, but they are not necessary. If your goal is to become a top lead coder, a legendary grandmaster at Codeforces, or an International Olympiad gold medalist, then I am not the person to help you. I did not even know that these titles existed until a few minutes ago.

The best software engineers simply build the best products in the timeframe that they’re given. They realize that there are real-world constraints and you can always improve and iterate in the future. This ability to understand and embrace the limitations of software development is a superpower that allows them to deliver high-quality products under pressure.

№6 — Give back to the community.

The best software engineers are not only skilled at their craft, but they are also generous with their knowledge and expertise. They are always willing to help others learn and grow, and they are committed to making their teams better. This is an essential quality for any software engineer who wants to be successful.

Hopefully, this one isn’t a surprise because I’m sure the software engineers you look up to most have helped you in your own personal growth and career in some way. The best engineers give back and make the people around them better. It’s what they’re judged on, because if you’re not making your direct team more efficient then what are you doing? Companies want multiple rockstar engineers and some are just born that way, but the majority of them are coached to that level.

By spending time pairing with and getting feedback from superstar engineers, you start emulating their habits and behaviors and good industry conventions. It’s like faking it till you make it, but you’re not really faking anything, you’re just copying until you get there.

Mentorship can come in many different forms. It could be notes on a document or comments on a pull request or just career advice in a casual one-on-one. But the true differentiators the top echelon of software engineers, the top 1% of the 1%, they don’t constrain their coaching only to the company. They believe that their brand should echo across the industry and they do this through blogs, conferences, and interviews.

№7— Grasp the Impact on Your Business.

If these layoffs have taught you anything, it’s that companies only care about their bottom line. Increasing the bottom line means more profit, which means more money back to shareholders. People often think that engineers should be shielded from the intricacies of making money. That’s for the product and finance teams, right?

Wrong. The top 1% of engineers embrace the numbers and align themselves with projects that will move the needle. The joke at Google used to always be that the fastest way to get promoted was by getting on projects that would ship and make a big impact even if they failed. It’s the reason there have been so many messaging apps from Google like Hangouts, Meets, and Allo.

Part of succeeding is having people in your corner and there’s nothing that brings people together, like money. Spending time understanding the money printing machines at a company and how to improve margins or create new business lines is the best way to make a splash.

In short, the best engineers are those who embrace the business side of things and align themselves with projects that will have a positive impact on the company’s bottom line.

№8 — Improve Your Culture, Improve Your Business.

Last but not least, rockstar engineers improve a company in more ways than just engineering and product. They drive culture, they run hackathons, write blog posts, and organize conferences, and they even make the interview process better. They understand that the only way to scale a company is by working on its culture. A good culture is the best way to attract great talent.

If you think of two of the best engineers out there, Jeff Dean and Sanjay Ghemawat, they’ve built some insane products at Google, but their reputation is so much more than that. They’ve mentored hundreds, if not thousands of engineers, improved culture, as well as technical initiatives like code processes and testing and they’ve worked on projects that have directly increased Google’s market cap.

I’m not a top 1% engineer. I’m nowhere close. But by emulating the behaviors of the very best software engineers, I’ll eventually get there and so will you. That’s all I have. Till next time. Cheers!