The Four Quality Katas of a Code Craftsman

I recently had the opportunity at a conference to ramen up with Lance Gleason of Polyglot. Of the many things we discussed in 3hrs, it came down to this:

"A really good developer implicitly cares about the quality of their work."

Forget what you've previously read, the blah blah, the pious statements, the bullshit for a moment. Consider these four reasons, practices if you will, that explain the statement above.

1. Write code that makes sense next week

I can't reason about things that don't fit in my head. So please write code that fits in my head, even if it already fits in yours. I say that understanding how big my own head is sometimes, and maybe that applies to you too. When we do this, code is easy to reason AND collaborate about, and it turns out that's severely important to our craft.

Also keep in mind that the amount of work you have to do next week will make you forget what you did this week. I love to forget about things, it helps me prioritize life. I wish the same for you. All code is an expression of intent, and when it contains bugs, we have to fix them. That means what we do today has to be simple enough to waste no time fixing when we revisit it in the future.

2. Write code that contributes to a purposeful existence

Life quickly becomes meaningless when you're working on meaningless stuff. Figure out what matters most in your life, make that your goal, and write code that contributes to that goal. Don't become a programmer for the money because you'll quickly learn to hate the programmers around you because we can be prickly unless you understand why we are what we are.

Personal scrutiny is a blessing and a curse. Self doubt, imposter syndrome, and uncertainty are all signs that you still have a soul, so don't worry if you see them while you write code. So when you see them on your journey with code or when someone points something out, you have no obligation to accept them verbatim; but you should receive it just as you should receive compliments, consider it, then if it makes sense work it into your code.

Be ethical enough to say "I will not build this" every time your conscience tells you that your product isn't going in a direction. Every time. Why? Because there is no soul in software other than what we as humans imbue into the process. Businesses are paper. You are craftsman. Be that.

3. Write code that entices others to collaborate

Who likes to toil away in obscurity on something no one else cares about? Exactly, so find projects that others also care deeply about, enough to contribute to, then go to it hard. Said the opposite way, you know if you're working on something valuable when others are so interested in it that they also want to invest their time in it.

Don't write negative comments over someone else's work. Just don't. Establish a dialog that helps you understand why they did what they did. Then if you still don't agree, be clear about the obstacles you see in the current approach and find which ones are imperative to resolve. Be okay with things that aren't perfect so long as there's a way to revisit them later.

You know you're doing it right when you leave no code behind that others are afraid to question. This is a characteristic of mature engineering, the self-evident latitude in your work for future ideas to improve what you have crafted.

4. Write code that anticipates change

Everything changes. Flexible code enables us to correct mistakes when we realize them in the future. Smaller code is easier to understand and fix.

Be clear about your surface area. The more you know about the limits of code, the easier it is to build code that uses it properly. If it's a function or method, naming and sufficient typing clarifies it's purpose and limits. If it's a REST API, a machine-readable descriptor with examples helps people integrate this into other code more accurately.

Constraints and dependencies also communicate the flexibility of a system. If you know that the code your writing shouldn't be used in specific circumstances, document those in a way that is easier for others to consume. Isolate dependencies when they are insufficiently abstract such that you can't write code that 'fits in your head'. Vet external software that you don't own, yes, open source libraries to ensure they meet licensing, security, and performance requirements.

Don't just talk about quality, practice it.

Quality isn't something you 'build in' afterwards, it's desirable characteristics exhibited by your work. There are many ways to accomplish this, but all take practice and focus, trial and error. Exercise teaches us to reason about why we do what we do, not just what we're doing. True software craftsmanship produces sensible, purposeful, collaborative, flexible code.