Treating Your Software as a Craft

As a software engineer, developer, coder, or hacker, whatever title you adopt, are you a craftsperson? If you take pride in your work, what makes you a craftsperson? If you don't, why not?

These days, there is little question if your name will be attached to your software for its lifespan. Versioning software like git assures that the "blame" of each line of code ties back to its history of authors. I personally have learned from, and cursed at, prior engineers of code bases, many who I have never met or known.

But I do know them, through their work. I have learned some to be thoughtful, intelligent, careful engineers who I aspire to be more like, and others as lazy hacks who bandaid in solutions without a care in the world. How do you want to be viewed retroactively through your code?

In recent years I have begun to think of myself as a craftsperson. I am not a master by any means, I have a great deal yet to learn. But I have adopted the attitude of someone who consistently hones his craft. This attitude has helped me make great strides in my ability to grow and it has helped me accept my own limitations.

For me, a craftsperson is someone who cares not just for the appearance of an end result but also for the details that goes into getting there. Often this leads craftspeople to be appreciated more by their colleagues than their clients. The wielder of a sword only really notices the quality of the build after it dulls or breaks in battle, and by then, it is too late. Another swordsmith however, can appreciate a sword long before it's used.

You must accept the humbling notion that there is always more to learn. Then you must push yourself to never become complacent. Every ticket you work on, every feature you add, bug you fix, etc., it's an opportunity to try something new, learn, and grow. But you can't grow without having a direction. In a previous article we cover that the top priority goal of software is readability so this should be the primary goal you grow towards.

2. The second pillar is that you should maintain strong opinions loosely held

You should be able to justify the decisions you make (technologies you use, architectural design choices, etc.) with reasons beyond "well it was easier for me". Generally, any software decision can be boiled down to either: "it was easier for me", "it is now easier for a reader", or "it was factually the only way", and that last one is (in my experience so far) always a lie. Make your decisions based on what is right, not easy, and then defend them when you are challenged. However, if someone shows you something better, proves you were wrong, be quick to drop your old ways, and humbly accept the new.

Criticism can be valid or invalid, and you should put the effort in to decide between them (See the second pillar for how to approach these conversations). Valid criticism is welcomed by a craftsperson because it is an opportunity for them to learn and improve. Being open to learning from anyone around you means you must put aside your ego and accept that your work isn't perfect. Find people to review your code who go beyond the basic. Seek out the higher standard instead of avoiding it.

Have pride in your work but also accept that it is flawed and that you can do better. Have confidence in your skill but avoid comparing your skills to others. Confidence is about yourself, Ego is about judging yourself against others. You should not feel ashamed of past work that you could do better now, it was written to the best of your abilities then. Similarly, knowing there is a better way, shouldn't freeze you from getting things done today, just do your best with each piece of work. Prefer simplicity for others, over padding your own ego by building things that show off your cleverness, or massive intellect.

Take caution in what you learn from others. While it is likely you can learn something from anyone, sometimes what you learn is simply what not to do. If someone shows you something because it is easier, or assumes that the reader can figure it out, it is probably a bad lesson.

Be more trustful of the current masters like Sandi Metz, Martin Fowler, Kent Beck, etc. Be slightly apprehensive about some of the older Masters like Robert Martin - many of his lessons are timeless, but many have become dated as well. Be very cautious of the millions of nameless tech bloggers (like myself). Be open to learning from all but use a critical mind, evaluate the reasons presented (or lack thereof), and decide for yourself which lessons are worth actually absorbing into your own craft.

It is your manager's (both product and project) craft to care about your velocity. It's your craft to care about the quality. A great manager understands that Engineering is the most expensive part of code both in terms of time and money, so it also makes financial sense to optimize this part. Having quality, readable code, minimizes painful code-debt and leads to high velocity. However, naive managers who only prioritizes the gains of the current sprint or quarter tend to be far more common.

Imagine you hire a company to do your taxes. Just like your manager, the company wants its workers to get as many tax evaluations done, as quickly as possible, so that they can maximize profits. But if the individual tax professional does poor quality work, they are opening the company and themselves up to lawsuits, reputation damage, and long term failure. It is the responsibility of the worker to do a quality job and prevent this downfall.

This is true for every profession; Lawyers versus their firms, Doctors versus their hospitals, Mechanics versus their shops. Would you want to hire any of these people if you knew they wouldn't stand up for the quality of their work first? There is no reason Software Engineers are a special case.

A craftsperson delivers a product as quickly as possible without sacrificing the quality of their work, and they stand firm on this. The question becomes, how can you balance writing quality, readable, code while delivering at a pace acceptable by your manager?

For me, the way to find the best balance is: I write the code to solve and understand the problem, I rewrite it once, optimizing readability, and then I deliver it. Often I know there is still room for improvements, but if they were obvious to my skill level, I would have done them on my second pass. After that I follow up with iterative improvements with each new fix or feature I make in that codebase.

Being a craftsperson is hard, and often unappreciated. But if you want to follow this route, I hope I can help. I am far from being any kind of Master. But I have learned from many of them, and struggled with their lessons. I have come up with my own understanding of many of those lessons and will follow with blogs on them. Hopefully, if they way they phrased something doesn't quite click for you (as it often didn't for me), my attempts will help to add clarity.

Often what is treated as a minor detail by a Master has taken me a lot to fundamentally understand, so I will write posts going into much deeper consideration of minor lessons, attempting to address the reason behind the lesson, with examples of the problems they cause and how the solutions are implemented.