Tools as Identity

Programmers love tools. They love them so much, they become part of many people’s identity.

I’m a rust programmer.

I’m a Java person.

This has always struck me as a little weird. You don’t hear (for example) wood- or metal-workers saying “Oh, yeah, I’m a hammer guy”.

If you were to try and imagine frequently-discussed topics in software engineering supplanted into other contexts, it’d become clear quite how insane software engineering looks to outsiders.

Alice: If you want to join two bits a wood together, a hammer and nail is really the best and most flexible option.

Bob: Oh but I disagree! I find a screwdriver and a screw is more ergonomic for me. And you can do so much more with it!

Alice: Nah, people who use screwdrivers just haven’t read the hammer manual properly and don’t understand how it’s so much better.

Charlie: I generally like working in an “impact” style. This “twisty/binding” approach to problem-solving doesn’t make sense to me.

Eve: If you guys aren’t doing your own metallurgy, you don’t really understand how your hammer is made and how it works. Amateurs!

The tool is the toolbox

But this metaphor isn’t perfect, or indeed very good. Java can do a lot of things. Rust can also do a lot of things. A hammer is usually for solving a specific, single problem: applying an impact force to a location. Maybe a better metaphor is a specific, opinionated set of tools in a toolbox?

This starts to feel like a better parallel - your workshop should contain all the tools that you like working with, and you should feel pretty good about knowing what those tools are for and how they can be used to solve problems / build stuff.

You’re allowed to use all the tools

A better parallel here is golf. For some reason, there’s a rule in golf that you’re only allowed to carry a certain number of clubs (4? 28? can’t remember). So you see an interesting part of the game is deciding which set of clubs to take around. This’ll usually be informed by both the course and the player’s personal preferences. Some people will go heavy on the wedges, some will stick a hybrid in, etc. etc.

Software development is a little bit like that. The constraint is less artificial-rule-based, and more practicality-based, but constraints exist nonetheless. Bringing Scala, Typescript, Rust, C and Ada all to a single project isn’t (usually) a good idea, despite the fact that those toolboxes might have the very best-shaped tools in them for solving the specific problem at hand. The compromise is how much can you achieve with as little complexity as possible.

For a specific project (or golf course), this seems reasonable.

Make your own toolbox

Humans are not projects!

Leaning on this metaphor (I started, so I’ll finish), a good golfer knows how to play all the wedges, and all the woods, and all the irons. They may have a preference over which club to use in a specific situation, and they won’t have all those available on every course they play, but they practise with and know how to use them.

I maintain a bunch of stupid small projects, that only seem to be useful to me. These projects are written in (amongst others):

• rust
• golang
• python
• kotlin
• typescript
• bash(!)
• scala

This is not meant to be some sort of brag, but more a note to my future self. I sometimes find myself working on a rust project, really feeling competent (for whatever reason) and then thinking “I should rewrite all these projects in rust! They’d be so much better!”.

The projects might be better (rewrites often improve things), but I’d end up being a worse golfer.