I’ve had the good fortune to work with some really incredible engineers in my career.

I mean the sort of people who spawned the “10x developer” myth – the ones who can write entire low-level databases from scratch which outperform (and, uh, out-reliable?) anything we could have gotten off the shelf; the ones who will go out and implement a solution in two weeks for a problem everyone else thought was unsolvable.

It’s amazing to watch – and so often, these people are a delight to work with, too.

In the last few months, I’ve been wondering to myself – what makes them different? I don’t believe it’s because of some innately high IQ. Is it because of the college they went to, or did they all get started programming at the age of 9, and had some kind of unique development alongside computers during their formative years?

I think I understand it now, and I don’t believe it’s so complicated.

Failing Is Awesome

Let’s start from first principles. These people are really smart, right?

Well, how do we become “smart”?

We become smart by learning.

And how do we learn?

We learn by failing.

Or at least – that’s by far the best way to learn that I’m familiar with. Sure, you can also learn by reading a textbook, or by listening to a talk given by some “smart” person – but in my experience, the most effective way to learn how to do a thing is to just, do it, and then look at what worked and what didn’t.

Trying, and then failing a few times, is a fantastic way for us to do our jobs – not only do we end up with a working system at the end, but thanks to those failures, we’re more intimately familiar with that system. When your load balancer starts responding with a bunch of 503 even though your backends seem to be running fine, you know right where to look – because this is exactly what happened last time you tried to improve the service discovery.

The really impressive engineers (that I’ve seen, at least) are the ones that don’t just fail often, but actively seek out failure, as a way to better their understanding. They run unrealistic load tests, for example – they deliberately search for the places their solution falls apart.

Humility Is Hard

But, there’s a snag here, right? Most people don’t want to fail.

There are definitely external reasons for this, right. My understanding is that most workplaces aren’t very kind to folks working on projects that have rocky starts, and so there’s a strong implicit motivation to have everything work “the first time”, to minimize (or at least hide) any failures from the broader eye. Learning by failing doesn’t work so well when you’re worried you’ll get fired for failing. This is a lack of “psychological safety”.

I don’t mean to downplay that – it’s a huge factor, and alone is already more than enough to determine behavior.

But, more and more, the resistance seems to come from “internal” places, too. I see people who meet unclear situations and handle them by making off-the-cuff assertions instead of digging in deep; people who hear questions from others with defensiveness and not curiosity; people who call a system “done” while putting in suppressions for all of those weird warning logs it’s still emitting. It’s much kinder to our ego to just deny outright the possibility that we might be wrong, I guess.

I think it’s due to an aversion to looking stupid. We want others to see us as both smart and capable, right, so we do our best to seem smart and capable – which admitting “I don’t know” does not exemplify. But I’m no psychologist.

What I do know is, this attitude has a tragic impact on the software itself.

The Right Mindset

In some sense, it is our job to be smart. We are “knowledge workers”; if we aren’t preparing for the right failure modes, if we don’t understand our systems well enough to diagnose a bug in a reasonable amount of time, then we aren’t doing our jobs well.

So, if it’s our job to be “smart”, it means it’s our job to learn, right? A software developer is a professional learner – thus, perhaps, a professional failer. And the more confident we become that our opinions are “correct”, the less willing we are to change our mind upon hearing a new perspective – the lower the artificial ceiling we put on how much we can achieve.

When we see a different approach to solving a problem, spend a couple of minutes looking it over, then shrug and offer “that’s a pretty low-quality solution” – that was an opportunity to become better at our jobs, lost forever. There are no “high quality” or “low quality” solutions anyway; it’s all context-dependent. The best one is the one which most closely matches the constraints and priorities of the business, which are usually pretty nuanced and folks have varying opinions. Some made-up concept of “quality” doesn’t come into it.

Is a mindset like that too extreme? All solutions are valid, no one’s ever wrong? Maybe! But my point is that we should strive to view it this way, at least. Or else we’ll stagnate – we’ll start dismissing someone else’s idea as “low-quality” just because it isn’t how we would have done it. Plain old arrogance – and arrogant developers are mediocre at best.

See something unexpected? Ask questions about it! Try it out, see it fail, fix it, and try it again! Celebrate looking stupid! And open the door to becoming incredible yourself.