This site runs best with JavaScript enabled.

Luke Mayhew

Front-end dev. Mentor to struggling developers. Pursuer of growth, wisdom, and a life well-lived.

Good programmers are worthless ― this is who I'd rather hire

Luke Mayhew

August 26, 2019

If you're a good programmer, don't worry - it's ok. I won't judge you. In fact, I won't even blame you. It's probably not your fault, after all. It's probably just a combination of passion, the education system, and the millions of messages we're bombarded with every day that's throwing you off. And that's ok (though passion has its downsides, and education can be problematic too).

But if I had a choice, I wouldn't want to hire a good programmer. Not even a great programmer. I'm serious - just check out what I wrote in every cover letter I wrote this year:

You'll want to know all about me. Here's the thing: I wouldn't say I'm a good coder.

Yes, I wrote that in every single cover letter. And yes, I did get hired, and by a place that really values what I bring to the table. Sounds crazy? Here's what I wrote next:

I am a great developer, though.

I'm not just being pedantic here about the terms coder and developer. What I'm trying to do is make a very real, and very important point if you want to be a top professional in our field:

Your value doesn't come from the quality of your work. It comes from the impact your work has.

In other words, if you're just a good programmer, you've only made it halfway. What you really need is to be an effective developer.

An exercise in missing the point

A couple years back I got to work on a really cool IoT project. As a web development agency, we'd been wanting to break into IoT for a while. And as a team, we were excited about the potential impact of IoT, and the experience of actually working with IoT technologies.

So of course we were really excited about this project. Aaaand we were in over our heads. All of a sudden we were dealing with a ton of new challenges we'd never thought of before:

  • Different sensor and edge device connectivity types
  • Different connectivity protocols
  • Delivering over-the-air updates without bricking the device
  • Ingesting and process massive data pipelines
  • ...and much, much more.

And that's only the real technical concerns. Then there were all sorts of non-technical concerns that we also had to keep in mind:

  • How do we provide support to this client after project completion?
  • How do we manage the risks of doing something in a completely new field to us?
  • How do we develop quickly enough to be profitable when we have no existing work to draw from?
  • ...and on and on it went.

Yeah, we were in waaaay over our heads. Not as in a "well that's impossible" way, but as in a "Hahah ok, good luck, I'm just going to whip up some popcorn and watch the fireworks - who knows, maybe you'll make it through without setting anything on fire!"

But here's the problem - there's something missing from that list of concerns. Have you ever noticed that no one likes to hang out with you if you only ever talks about yourself? That's partly 'cause it makes you an asshole, and also partly because it makes you pretty damn irrelevant.

And yet, as programmers, we often end up conditioned to think only from our own perspective. Notice how almost all the points in the lists above are all about "me"? What technology do I have to solve, how do we turn a profit on this?

They're good questions, but good only gets you halfway, remember? We could've absolutely nailed every single one of those questions and it still would've made about as much difference as a fart in a jacuzzi.

Why? Because as a professional, you're not programming for your own sake - you're programming to have an impact on someone else. And if you can't deliver on that value, you're a bit of an asshole, and pretty damn irrelevant.

(Don't believe me? We ended up losing the contract on the project, and all the brilliant work we did being good programmers just became a liability the company had to pay for. Ouch.)

As a professional, you're not programming for your own sake - you're programming to have an impact on someone else. And if you can't deliver on that value, you're a bit of an asshole, and pretty damn irrelevant.

At the intersection of "good" and "need"

So here's the bottom line. Being effective means pairing the good you can do with the need that people have. Ever seen anyone trying to sell oxygen to folks who can breathe just fine? Nope. But when you're on the lung transplant list, any price becomes a good price. See? Need.

But there's a catch with all this - we're not sensible creatures. We're emotional, egotistical, and have tragically limited and self-centered perspectives. In other words, we are naturally inclined to lose sight of what need really looks like, and just start thinking that whatever matters to us is the very definition of need.

Take that IoT project for example. We had folks on the business side of things asking need-based questions like, "What value are we actually selling here?" or "How will this help the client to scale?" Now contrast that to the developer we had who kept insisting that if we were going to win the contract we needed to do Machine Learning in the project.

Now, none of us really knew much about Machine Learning except that it can provide huge benefits when applied to IoT, but I knew enough to know that Machine Learning isn't value. And that's because it doesn't meet a need. No one ever woke up one day and went, "Holy crap, I just realized what I need! I need Machine Learning!" They may have thought "I need Machine Learning to do something for me", sure, but Machine Learning itself is a concept, a set of techniques, not actual value. It's when the application of that concept creates a result that meets a need that we actually get value.

Value occurs at the intersection of what is "good", and what is needed. Without both, you have nothing.

Solving the maze

When I was a kid, my father taught me a brilliant trick about solving mazes: start from the end and work backward. If you want to be an effective developer, this should be your guiding light too.

Here's how it works. Before you start coding, before you start researching, before you even start thinking you understand the problem, ask yourself "What is the root need we need to address here?"

Why? Well, ever seen those lists of "10 Most Useless Inventions Ever Made"? You don't want to end up on one of those lists. You don't want to be one of those poor bastards who thought they had a good idea, only to find out that somewhere along the way they went just a degree or two off course and ended up in a whole different timezone than the actual value they should've been aiming for. By fixing yourself on that root need right from the start, you give yourself a guiding star to make sure you nail that need and deliver value.

However, keep in mind that the key phrase here is root need. Needs are always a hierarchy, and what seems like the real need at first is usually not where it all starts. For example, we might say that the root need is the customer's need for effective collaboration, but the reality is that the need to solve that stems from the need to get customers to pay us, which stems from the need to keep a roof over our heads, etc.

Not being a root need doesn't make a need any less important, but not knowing your real hierarchy of needs will eventually throw you off course, and waste your time and effort on things that, in the end, just don't matter. Know the needs, know your course, maximize your effort.

So would I hire a good programmer? Maybe, if there wasn't anyone else. But an effective developer - someone who knows what to do, not just how to do - that's the real deal. That's who my money would be on.

Don't do things right. Do the right things right.