The more I involve myself with the software development industry the more I see developers describing themselves as software craftsman. Surely this is a good thing, right? Sadly most of them seem to interpret this to mean they have to produce the world’s most beautiful, fully tested, totally modular code. This doesn’t seem to fit the bill of what a craftsperson does.

To set the tune for the rest of the article it’s useful to know I’m a leather worker in my spare time and a developer currently at ustwo London during the day. This means I am constantly creating both physical and digital products for others.

I think the problem lies with people’s bastardisation of the term “craft” in the industry with some people using it to mean aiming for perfection at all times. Even artisans or crafters of physical products cut corners while keeping the user requirements in mind.

The crafter has the power to decide the end product; for instance a blemish on a piece of leather may not be seen much by the user nonetheless in some cases the blemish, such as a scar on a piece of leather will add character to the final piece. It’s up to the crafter to decide to either show it off or hide it behind another piece.

The same rules should be applied to “code blemishes” since as a developer you should be questioning the impact on users and evaluating what they may feel about it. For example, as a developer you would likely prioritise more important features e.g. playback in a music player, since it’s part of your core feature set and you want to showcase it. Nonetheless, you as a crafter, might want to decide if a bug/blemish is worth fixing comparatively to other features that users require.

Although you’ll build to the best of your abilities you’ll always have to keep the user in mind.

If the user wants a handcrafted leather wallet tomorrow, no matter what, then you’re going to have to cut corners to ship in time. It’s still a lovely handcrafted piece and it’ll still serve the purpose required and that’s what matters most. If you’re building a prototype then you don’t need to use the best materials or practices available and just use cheaper alternatives. Similarly in the software world this could mean hard coded strings, using 3rd party libraries and writing throwaway code that you’ll scrap.

If I’d made this messenger bag prototype from real materials I’d have spent a small fortune making and remaking it with all the tweaks it required.

From my own experience I’ve made my granddad a new 6 slot, 2 hidden compartment, note holding bi-fold wallet. It wasn’t made from the finest materials possible and I wasn’t the best with my craft skills then. Maybe I wasn’t overly happy with the end results and even worried he’d never use it or worse, just throw it away. Nonetheless, I gathered the courage and sent it to him anyway… He was absolutely over the moon with it — loved it — couldn’t see a thing wrong with it. Only when I pointed out the slightly wonky stitching did he realise that was something that he might have missed, still, he couldn’t have been happier with it and it served the purpose he as the user wanted it for.

Grandad's wallet lesson #1: Ship it and get feedback! It’s better to have a product out there that fits the user’s needs, even if it’s not perfect than to not have a product out there at all.

In the talk “Quality is a variable” by James Higgs he mentions that code is merely a transitional artefact, a byproduct of creating the product. I’d argue that code is so much of the product that it should be considered the product. The code drives the UI, decides the functionality and puts the flourishes where they are needed. Just like the leatherworker, a developer needs to pick the right pieces to focus their attention on, there’s no point doing the finest stitching you can if it’ll hidden by another piece of leather, just stitch it and be done. A developer shouldn’t focus all their attention on beauty or animation if the prime requirement from the user is speed.

The problem

If a crafter never flexes their skills and pushes themselves with their craft they won’t learn lessons about how to make their products better for their users or future products.

The same applies to developers. If they don’t occasionally push for perfect solutions they won’t likely be learning valuable lessons that will help deliver for the right user requirements.

Grandad's wallet lesson #2: Aim for perfection occasionally. Sometimes a crafter needs to aim for perfection to learn how to better themselves technically. Often crafters have to compromise with the user requirements in mind to ensure products ship.

If I hadn’t made mistakes whilst making Grandad's wallet then I wouldn’t have been able to improve my skill set to make the one below.

Check out the bonus Monument Valley totem in the background :)

For a software craftsperson you need to make sure that they’re able to explore and take some learnings from their experiences so that their aim is to be software craftsperson. Just not the bastardised version of it.