At work, I've earned a bit of notoriety for being a code style commisar. I've been part of the group that from the bottom has been pushing people ot use flake8 and eslint, and I even wrote a tool to make polyglot testing easier. My latest kick is types. After experimenting with them for two years, I've decided that they do make a difference, a huge difference, in the quality of code. They won't catch every bug; today I discovered that a documented defaulting option hadn't actually been included in the parser I'd written. Yay for unit tests. But also: yay for types. By switching to types, and actually using them, I've discovered where my thinking was weak and vague. Type checking is a constraint. Great art is always made within constraints.

It's still not enough. You have to have good taste. You have to have an aesthetic sense for how the code communicates. You need to design everything. Design adds clarity. It's not enough to make it work. I tell people you need to design and write, then redesign and refactor, every project, and you need to book time into doing so. Function and variable names need to be clear and communicative– keep a thesaurus. in your bookmark bar! If you've got an excessively clever bit of code, break it into smaller units and name them with variable and function names. If your company has a preferred organization for classes and modules, use it consistently. If not, use an organization that best tells a story. Use nested functions to isolate unique functionality. Do the same thing with the filenames in modules.

This stuff takes practice.

There's a saying in software design that I have come to loathe: "Write your code as if the guy who has to maintain it is a violent psychopath who knows where your desk is." I heard a guy up from the San Francisco office say this the other day and my reaction was, "Nobody works well when they're afraid. If you want great software, you have to have, like, Buddha-levels of respect for the next person." I then went into a (small part) of my rant above.

I guess I must have been rather forceful and passionate in my defense of good taste in software design, but he next said, "Why do you care so much?" I found the perfect formulation:

Programmers work at the limits of their understanding, with their brains full. Maintaining code is harder than writing it anew because you have to understand what the original writer was trying to do while they were writing code at _their_ limits. If you have respect for the next person who has to modify your code, including the skills they're likely to have, then you will write software that's as clear and easy to understand as you possibly can. This means that any problems, any future extensions, and any customer requests can be met in hours instead of days, or days instead of weeks. The maintainer is happy because they aren't frustrated by code ugliness or made to feel stupid by excessive code cleverness. Instead, they can fix the problem easily so they're happy. Happier maintainers get stuff to market faster, and that makes customers happy. Happier customers buy more of your stuff. That makes stockholders happy. Happier stockholders reward you with bigger raises.

Aside from the money, I'm happier when I feel pride in my workmanship. Don't you?