Please Don’t Hire “Coders”

blogI often hear software developers described as “coders”. To me, this implies someone who implements the very last step in a one-way idea-to-product chain of events. Someone who, perhaps unquestioningly, takes an idea that is deemed sufficiently well-defined, and codes it in an arbitrary programming language.

I think that businesses hiring “coders” miss out on the real understanding of technology and, more importantly, what is possible with it, that they would gain by hiring slightly more experienced software engineers. If your product is to be built in software, shouldn’t you hire people who know a little more about it?

Yes, experience costs more. But with experience comes the ability not only to improve, optimise and speed up the creation of software, to make it more reliable, scalable and understandable, but also the ability to discuss how it will be built, perhaps using existing components, ways to improve it and to work through problems encountered (there will be many) and available options at each stage.

Crucially, decent engineers can do all of this both in technical terms and in the language of any audience: business sponsors, sales, marketing, clients. You can hand them a whiteboard marker and ask them to tell a room full of people about it… in a way that everyone will understand.

The ability to bring other non-tech folks into the software development process, on their own terms, is the sign of a mature engineer. They don’t need to baffle with technical details as a way to pat their own ego. They can explain and expose their decisions in ways the rest of the business can understand, and involve people in those decisions.

In short, experienced engineers enable a business-wide discussion about technology, rather than a simplistic, and perhaps limited, coding of an idea in it.

So if you’re building a tech product, and you really want it to sing, to work well and to compete… please don’t hire “coders”.

I Will Always Write Code

handI’ve written code since I was 7 years old. To me, it’s the equivalent of painting to an artist, writing to an author, cooking to a chef, etc. They are all creative. With all of them, you get to build something.

In tech careers, there usually comes a point when a developer is asked to stop coding and to focus entirely on other activities; usually management. I’ve had this about five times, and have always managed to remain at least partly hands-on too.

To my mind, you wouldn’t find a passionate chef willing to completely forgo cooking activities for kitchen or restaurant management, a talented author who’s happy to manage a team of writers but not write themselves, or an inspired artist looking to run a gallery but not at least paint / sculpt / create occasionally in their free time.

If your passion comes from building and creating something, I doubt you can ever truly give up on that. No-matter how much you may take on other responsibilities (and you probably should!), I suspect it’s usually a mistake to entirely give up on creating / writing / coding / cooking if they are your passion.

Taking on other roles is something I believe we should all do if we’re good at them, and it forms a healthy part of career progression… but it needn’t come at the expense of remaining partly hands-on, if that’s where our passion lies. Though we may need to make that happen ourselves, or realign ourselves with opportunities that allow it. Pigeonholing is all too common.

Like I said, I’ve coded since I was 7 years old. I don’t do it out of necessity, but out of a real sense of fulfillment and a desire to build things. It isn’t a stepping stone to something else. It’s something I’ll always do, no-matter what else I take on 🙂