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.

Don’t Panic! (or how to prepare for IoT with a mature testing strategy)

Thanks everyone for coming to my talk today! Slides and more links are below.

As all my presentations are, this is meant to extend a dialog to you, so please tweet to me any thoughts and questions you have to become part of the conversation. Looking forward to hearing from you!

More links are in my slides, and the presenter notes are the narrative in case you had to miss part of the presentation.

Android Debug Features and Tools chat with Sam Edwards

Developing Android apps can be hard…without the right tools and patterns in your back pocket.

I had a chance to sit with Sam Edwards (@handstandsam) to talk about some of the work that went into his presentation at Droidcon Boston last week. There are a bunch of tools outside in out-of-box Android stack that I wasn’t aware of (see below), but Sam quickly educated us. His full talk will be available in a few weeks once the conference dust settles.

Improving the Espresso Testing Landscape

Afterwards, Sam and I went for a stroll down Tremont and discussed some patterns people were applying to simplify writing Espresso tests.

Shauvik Roy Choudhary who I met at last year’s Capital One Android Summit has produced some great work around Testing Robots (slides and code). This is not to be confused with Jake Wharton’s work on (also named) Testing Robots, equally awesome and worth your time reviewing if you haven’t already. Shauvik also produced Barista, which you can find in the app store.

Related note: in recent StackOverflow work, I found out about another cool project called Barista, a library of wicked helpful functions for Espresso testing by Rafa Vázquez, Roc Boronat, and Sergi Martínez.

Great to see people sharing their experiences and lessons learned so we don’t have to toil on them ourselves.

Android debug and design tools that Sam covered: