Building the right thing the right way

TLDR: upskilling on ensuring you “build the right thing” is just as, if not more important than upskilling on “build the thing right”. We need to be experts in building the right thing, the right way.

STLDR: prototyping and using a whiteboard effectively are superpowers

In some martial arts, a black belt is considered the point at which you know enough to start to really learn. It’s the starting point, not the end point. It’s a huge effort, a significant milestone, but the assertion is that you have moved from unconscious/incompetence to conscious and unconscious/competence: you now know what you don’t know, and you know the basic/essentials enough so they no longer distract you, and you can start on the important stuff.

What’s the equivalent in software engineering?

I think it has nothing to do with tools/programming languages/infrastructure. It has everything to do with a whiteboard, thinking, and people skills.

We should be able to wield our tools/programming languages/infrastructure at least competently, and preferably expertly, but knowing how to wield them, when to wield them, what to build with them are key. Knowing how to interact with the messy, ambiguous, contradictory, and ever-changing reality of “the real world” is far more critical to “success”.

Knowing how to listen, draw out, clarify, and partner with people in order to understand the “what, why, when, and how?” bit of reality that you are trying to change. Knowing how to communicate back to your “partner” (I don’t like “client” ;-)) what they are asking for, etc. Knowing what to build is as important as knowing how to build it.

None of these are technical skills and all of them are critical.

By far the most powerful tools I’ve experienced in my 30+ years of doing this are: a whiteboard, putting people at ease (terrible dad humour is a superpower), clarity of thought, clarity of message, and being able to prototype incredibly quickly. Understanding that you are prototyping most of the time is also important. Call it “production” all you want, but it’s probably going to end up either a prototype or a “failed project” ;-).

So why do we focus so much on the technical aspects? I think they are absolutely important. Once you know what to build then yep, let’s be surgeons and wield our tools accordingly, impressively, and expertly. But please, please, please, learn how to identify what to build before focussing on how to build.

Both these sets of skills are critical, and are very different.

Technical aspects are nice because they are a closed and well defined domain. The real world isn’t. It’s much safer learning a new language, tool, or infrastructure. The first time your CI passes, or your end-to-end tests work, or pretty much getting anything working in AWS or Kubernates, or you understand AND CAN EXPLAIN a Monad is fantastic. “Success” is easily defined here, as is the path to getting there. But it isn’t enough.

(BTW - I say all of this as a hard core geek. Give me a cupboard with a whiteboard, an editor, and a large cup of coffee and I’m a happy chap, but professionally, as a professional Software Engineer trying to help people achieve their goal, it isn’t enough.)

Ultimately: I’d suggest far more projects die that built the wrong thing well than built the right thing badly. Let’s be experts in building the right thing, the right way.