Introduction

Think about the top 1% of developers you know. What do they all have in common?

Are they all smart people?

Probably, but do you know any smart developers whom you wouldn’t place in the top 1%?

Are they always up to date on the latest techniques?

Maybe, but that could be a correlation. I doubt, very much, that it is a driver.

What about the latest technologies?

Undoubtedly, they are experts in whatever technology they work with most, but that is not what makes them top 1% developers.

As I started to think about this and go through all the developers I can remember in nearly 30 years as a programmer, I became less and less confident in what made someone a really, really good developer.

When it finally struck me, I found the answer surprising.

It was one of those epiphanies that you know to be right because, in retrospect it appears “obvious”, even though it eluded you for years leading up to its discovery.

So, later in this chapter, I’ll explore my own journey as a software developer.

First, though, I want to give you an example of what I consider to be a top-1% developer.

One of the best developers I’ve ever met is someone I worked with over a decade ago, now.

I knew him when he was still “just” a tester. I watched him as he switched over to developer and took off.

In some regards, he’s not my best case study, here, because he is, in fact, brilliant. But, at the beginning, his raw intellect was offset by his newness.

Still, very early in his career, he set himself apart by making what people considered a dangerous decision…

There was this one part of the system that made everything slow. I don’t mean “3% slower because of this class”. I mean - and I write this without a shred of hyperbole - certain customers were waiting 45 minutes for login to complete. Again, that’s not a typo or an exaggeration. That’s just the reality.

On top of that, was a constant source of waste. Our manager crunched the numbers and decided that the team lost something like 60 hours a month to the new bugs that were constantly being created and found in this single class.

It was a huge class, too. As things got worse, people kept adding to it in an attempt to fix it. That only made it worse, though.

He decided to take it on himself to rewrite it. He produced a system of classes about 350 lines long in total (<10% the original length) that completely solved the problem. He fearlessly changed the coupling over to his new system, knowing that he was taking a risk.

The result was overwhelmingly positive.

The new system he built was easy to understand, easy to change, and fully covered in tests.

The stream of something like 3 high severity defects a month was sealed off–the additional productivity the team got over the next few months more than covered the initial investment of his time.

In addition to sealing up the time-sink, it also solved several critical problems. Not the least of which was bringing login times down to something reasonable.

Some might ask if this went perfectly. He was dealing with an extremely fragile subsystem that was widely used throughout the system.

He had to identify all the use cases. He had to point all the client code to the new thing. He had to make it all work.

Did he create any bugs? You bet he did.

He created exactly one bug of medium severity in that process. A bug he was able to quickly fix.

Since people were accustomed to three severe bugs coming from that system a month when nobody is changing it (aside from previous “bugfixes”), nobody was upset.

He took a risk. There was a cost. It paid off.

I won’t say that this launched my friend’s career. I’m sure it had a positive impact, but if not this, then some thing.

What I mean by that is that this is a pattern for him.

It wasn’t a one-time risk he took that paid off and launched him: It was an expression of the way he works.

This approach to software has served him well. He quickly climbed the ranks of individual contributors and then started moving up in leadership.

The last time I checked, he was a VP of Engineering at a well-funded and growing startup with a strong team underneath him. A team that trusts his skills and his abilities.

A consistent pattern of making the right decisions with good long-term payoffs—and a solid plan for how to implement those decisions—is what put him where he is, today.

That got me thinking about my own trajectory.

Now I want to take you back to my beginnings as a software developer.

I’ve been coding for a long, long time. I’ve been doing it seriously since I was a child.

I used it to weasel my way out of a number of classes in high school that I thought were beneath me.

Why should I take an elective, when I was the one teaching programming? I’ll just convince the administration that that was worth a math credit.

Why should I take a foreign language? Isn’t defining and building my own programming language foreign enough?

I started coding professionally when I abandoned the “education” system once and for all in my freshman year of college.

I’ve always thought of myself as pretty good at this. Humility only really entered into the picture once I’d been doing it long enough—and sticking with one project for sufficient time—to look back on how my younger self worked and be able to shake my head in judgment of that younger man.

But, professionally, others recognized my abilities as well (which did little to help me develop humility).

Over the decades, my perspective on what software development—especially good software development—was evolved.

This is barely worth mentioning, because I’m pretty sure this is just the description of how any child sees anything that interests him.

When I was a child and I first started to get involved with programming, I saw it as a plaything.

It was a source of mysteries to be unraveled with the potential to serve as a creative outlet.

I had been playing games for a little while and I wanted to make my own. I’m not the first developer with that as the initiating force in his backstory, nor am I the last.

Nevertheless, I had too little understanding of what programming (let alone software development) was to have an opinion on what was good and what was bad.

As a budding youth, I saw coding as one big exercise in mathematics. The goal was to get the right answer.

There may have been a sense of craftsmanship but only in so far as it served in the pursuit of perfection.

Mathematics was appealing to people like me because there were correct answers. It’s one of the only spaces where that is true in its absolute sense.

My idea of what good coding was descended directly from this fact.

There’s just one problem. In mathematics, each proof, each theorem is correct because we make it correct.

Software is too connected to the real world for us to have that kind of stipulative power.

Upon leaving college and joining a firm called Rogue Wave Software, I was presented with a new force: Someone else was paying me to code.

These people weren’t really interested in perfection. Instead, they were mostly interested in these annoying things called “problems”.

Customer problems served as a crucible in which my actions were held for judgment.

The real world had come calling and the idea of frittering away who-knows-how-long on who-knows-what-but-it’s-beautiful withered in the fires of that judgment.

So my new perspective quickly became something like “good coding is solving problems efficiently”.

Yet “efficiently” did not really have a universally-accepted definition for software development back then. Honestly, it might not even today.

My previous experience and my instincts told me that solving problems with quality was essential to efficiency. Intuitively, I understood that quality code was easier to change later.

Mentors and collaborators along the way also knew this and helped me learn to externalize this idea.

In the years that followed, something happened: A lot of developers kept doing things the hard way. People would cut corners, knowing it was going to cost more in the long run.

As someone to whom interpersonal interaction never came easily, I did what was obvious. I got angry.

People were being obstinate. I told them what to do. Luminaries far above me and widely respected told them what to do.

But they weren’t doing it.

They weren’t stupid people. So malice (which I called “laziness” at the time) was the only explanation I could imagine.

So I blustered. I castigated. I whipped my prowess out, slapped it on the desk, and dared anyone I could to go get a measuring tape.

For some reason, this didn’t work any better than telling people nicely.

Go figure.

Despite my many, many flaws, a relatively elite consulting firm ended up hiring me as a technical coach.

They took me under their wing. They helped me learn how to interact with people. They taught me that it’s not my responsibility if someone can’t or won’t adopt a skill.

They taught me to accept how people grow and change.

They helped me grow as a coach and as a team member.

Through all that, though, they didn’t really change my concept of what good software development was.

I still saw the fundamental problem of being a software developer to be solving problems with high quality, so you can keep solving them rapidly later.

After a while, I started to see things a little differently. Once I had enough samples, the pattern became clear to me.

People in the top 1% often…

• …are very smart, but they’re not all geniuses.
• …have some kind of authority within their organizations, but not always.
• …adhere to best practices, but some of them are basically just cowboys.
• …study deeply, but not always.
• …have a mastery of multiple technologies, but some of them hyperfocus on a single stack.

They can work differently, talk differently, act differently. They even wake and sleep differently.

The one thing I noticed in every developer I’ve met who consistently made highly-visible impact was this:

They all were willing to tackle the hard stuff.

They weren’t afraid of any code, or, if they were, they didn’t let it stop them.

They have a pattern of seeing that something needs to change, and then making that change. Often, this carries significant risk so they come up with strategies to mitigate that risk.

Some of them work in ways so careful, that they prevent those risks from manifesting at all.

Yet all of them make the hard changes and make them work.

Throughout the remainder of this Part, I will clearly define what it means to be in the top 1%, what doesn’t work, and what holds people back.

I’ll also establish fear of short-term consequences as a major player in what keeps people out of the 1%.

For now, let me establish this definition:

Top 1% Developer

Someone who consistently solves the problems the rest of a team is unwilling to tackle.

In other words, they aren’t magicians or savants—at least they don’t have to be. They’re just the people who keep rushing in where others fear to go.

By the end of the book, not only will you know what it takes to be one of them, you’ll know what you need to do to get there.