On owning a software problem

This weekend, I saw a tweet that really resonated with me, and judging by the comments, resonated with a lot of others, too.

It reads,

“My buddy is an electrician and told me a few months ago that he always leaves the screws in a vertical position on jobs as a sign of craftsmanship. Been thinking ever since what my “vertical screws” equivalent is for product design.”

Tweaking the screws in a light plate is a relatively low-friction small thing that most people will not notice, but that when they do, it’s a sign of craftsmanship, expertise, and pride in your work.

I wondered out loud what the equivalent of that was for machine learning and data science work, and got a wide variety of answers, ranging from:

• Python code has type annotations
• Accurate documentation of a repo and an easy, reproducible way to run the project
• Method and class names that match the names and style of the rest of the codebase
• Formatted and linted SQL statements
• Opening a ticket to improve documentation on someone else’s project
• Editing typos and inaccuracies in old communications
• Carefully reasoning about corner cases in public
• Explaining acronyms and industry jargon when in an audience that might not be familiar with it, and being cognizant of when they’re in that audience
• The code recognizes the multitude of variations in data that can happen and handles those cases
• If you’re putting together a SQL query, saving that query in the accompanying spreadsheet so others can reproduce it

All of these in and of themselves are not singular indicators of good craftsmanship. What they all have in common, though, is that they are indicators of ownership. A good developer cares about the code they’re putting out into the world not only because it has to work for them, but because their code will spend most of its time being read and implemented and worked on by others, and as developers, we want to care about those people, too. By observing someone who does one or more of these over time, you can spot the telltale signs of someone who cares about their work.

Ownership means you make your code the best it can under the circumstances you have, and are proud to pass it on to other people. And, if it breaks, you understand the implications and can jump in to help. Ownership means you take the responsibility on yourself for not only your code, but any code in your path that is a potential blocker, and you go in and make it better, because doing so makes your part of the codebase easier to work with.

Ownership means that you might be a general contractor and building an entire house for other people, but when you’re handing over the keys, you’ll be damned if the buyers see anything other than vertical screws, and even if they don’t notice, you can rest easy, taking personal satisfaction in the job you’ve done.