If Tools Were People

Wolfgang Schuster — Thu, 17 Sep 2020 18:24:45 +0000

I often think about what the personalities of tools would be if they were people. For example, my air fryer gives a cheery little tune when the timer is done, like a friend inviting you to dinner. Compare this with the buzzing sound the alarm on a dryer makes. It feels harsh and repelling, like someone scolding me for not having done the laundry sooner.

So, what about our development tools? Well for many of us our communication is through text messages. Those could take the form of error messages, or completion messages when the tool is done running.

Take Rust's cargo. To me cargo feels like a nice coworker, the kind you want to pair on with challenging tasks. They might take awhile to look over all your code but when they find something that looks wrong they can point you directly to it and even give some suggestions for maybe how to fix it. Sometimes they digress into really complex topics, but they're still there to help you get the job done.

Javascript is the near exact opposite though. When working with my coworker Javascript I often would rather not be pairing. When I make a mistake in my code they often wait until I try to use it before they even bother to mention a mistake I made. Then when they finally do let me know about my mistake, it's like talking with a child. Sometimes they just blurt out ERROR but won't tell me why or where. If they do tell me where it's not where I made the mistake. They give me a line number in some maybe related file and say, "Good luck, I hope you can find it." before walking away.

My favorite person to work with by far is Elm. When I make mistakes around Elm, they politely tell me exactly where I went astray and off multiple suggestions for how to fix it. They just point to the actual code and say, "Pardon me, I see you wrote this but I think maybe you meant to write one of these other options." They even take into account that I might be new to all of this as well, and will give hints about how they do things a little differently and it's ok to be learning the different approach. One of my other favorite things about this coworker, they let me know right away when my code is off. They don't wait for me to try and use it and they don't have to sit and think for minutes about what I'm writing. They sit there with me through the whole process until my app is all done.

This isn't to say that everyone should be Elm. There are many tasks where I need my coworker Rust to help because Elm doesn't understand what needs to be done, and that's cool! Just like real people, we all have different skills that we excel at. I would like it though if all of our tools were a bit more kind. If they were a bit more like Rust and Elm, and a bit less like Javascript. The personalities of our tools should mirror the personalities of the real people we want to work with.

Humanity in Software

Wolfgang Schuster — Tue, 23 Jun 2020 21:15:13 +0000

So I’ve been trying to find better words to describe how I feel about programming lately. I think I’ve found better ways to understand where I’m at mentally and emotionally.

Over the 8+ years of my professional career I’ve worked in at least a dozen different languages, and that code has been or is currently running in production. In my 20+ years of hobby programming I’ve written more than Hello World in probably an additional dozen languages. I’ve used this build tool, and that build tool. I’ve written configurations and I’ve followed conventions. I’ve worked at companies of over 2k developers, down to just 2, and various sizes between. I’ve done games and enterprise apps and startup apps. I’ve done object oriented and functional, and even graphical programming. Dynamic and static typing. It’s taken me all this time to realize the 1 thing I’ve been missing in software development that I got in every other field I've worked in.

Empathy.

When I worked in food service, it was expected that everyone cleaned up after themselves and left the next crew with a clean workspace. You set the tables at the end of the night, you washed and put away all the dishes. You took out all the trash. You maybe even prepped some things for the next shift. When I worked in manufacturing, you cleaned up after yourself. You put your tools away. You swept up and washed down anything that needed it. You left your space organized for the next shift, so they knew exactly where to find what they needed.

In software you get docs, maybe, and if you do odds are they’re outdated. You get comments, maybe. You get code that was slapped together in a rush and shoved out the door. Our tools work most of the time, but when they break they give us error messages usually no easier to understand than a solid colored jigsaw puzzle. There’s little to no empathy from the tooling and there’s little to no empathy from the people. Half of the GitHub issues are demands instead of requests or questions. Instead of discussing a tools accessibility or maintainability we discuss its popularity.

Part of this feeling comes from spending most of my career in other people’s code. That is I’ve only ever worked on 1 completely greenfield app. Additionally, most of the code I have worked on was written by someone that’s no longer at the company so going and asking questions about “what” or “why” usually isn’t an option.

Maybe I’m alone in this feeling. If so then these words are just for me. In the case that I’m not alone, what do we do? Overall I’m not certain, though I do have 2 ideas.

My first idea is to spend more time talking about the how the code we’re writing is going to affect the next developer. If you came into it today, completely new to the general context of why it was written, how likely would you be to succeed. This can be challenging, but isn’t that different of the thought process of “walking a mile in another’s shoes”. This can sometimes be as simple as writing out a longer variable name. Maybe it’s a little more work, a comment about what’s going on and why. Maybe it’s really complex and requires documentation. If you can keep it in the code itself, that’s usually best as it’s most likely to stay up to date. The further you get from the code, such as documentation, the less likely it is that it will be updated. Stale documentation is about as useful as no documentation.

My second idea is improving tooling. This one took me even longer to come to realize. If I’m new to learning a tool, make the error messages meaningful to a human. Point out where the issue is and maybe even some possible solutions. Only suggest reading documentation as a last resort, because as I pointed out earlier it can get out of date. This doesn’t apply only to language compilers but also to linters and more. If your tool requires a configuration, make sure you error messages explain what’s wrong with my configuration in a way that doesn’t make me want to pull me hair out as a first time user. If your tool prefers “convention over configuration”, make sure it’s still explicit. Your “it’s obvious” or “it’s natural” is another person’s “wtf?”

A final thought. If your internal, or external, response to a question about code/tooling is anything along the lines of “RTFM” (Read The Fucking Manual), “obviously [..]“, or “naturally [..]” then you’re not walking in that person’s shoes. Similarly if you’re struggling with something, or dislike the approach a tool takes, it’s not empathetic to respond with demands or accusations. It doesn’t matter if it involves Open Source or other “free” work. We’re all in this together, we’re not against each other.

I'm just as much guilty of being a part of this cycle. I'm writing this partly because I want to be better.

DEV Community: Wolfgang Schuster

If Tools Were People

Humanity in Software