I looooove building tools. It’s like building a jig1 in a woodshop. Once you’ve built your new tool, you feel like you now have the ability to do something you couldn’t do before, or at least the ability to do it better. Unlike a jig in a woodshop, with computer work we can store as many of these tools as we want, as long as we can organize the github gists and git project scripts directories.
When I think about building myself a little script or tool to help me do some dumb, tedious task, I do sometimes think of serious things, like xkcd #1205.
Other times I think of less serious things, like xkcd #1319.
Then I think of the potential benefits, benefits that might not be immediately obvious. I’ve sometimes noticed pushback against taking time to automate from project managers and executive types who are pushing features or ticket closure metrics. I can only imagine the “not immediately obvious” benefits aren’t… well… immediately obvious.
1. I learn how to automate better and faster
Learning to automate faster means the next time I need to automate something the payoff from the time savings could potentially come much earlier. This only comes from practice. When am I supposed to practice?
2. I’m more correct
Automating something isn’t just about being able to do things faster, it’s also about being able to do things more repeatably, more accurately. Sometimes being accurate in a task is as important, or even more important than doing it quickly. It could be that I prefer to automate things because I know I’m prone to human error.
3. It’s easier to document a process
By collapsing multi-step processes into a tool/script that I also share, it makes reproducing the output easier. This becomes more pronounced when you build your tools with good design principles. While 12-factor is typically for building software that’s easy to run in production, our tools should be easy to run, too. There are a number of those 12 factors that apply really well to command line tools. If you have the option to make a tool take input from the user interactively OR accept command line arguments and options, choose the latter.
If you can do both, that would be even better! I love tools like trogon for python. I’m not super jazzed about distributing python tools, but would love to see libraries like these for Go or Rust tooling that integrates with the existing cli frameworks. Having these kinds of interfaces really helps with a big problem in CLI tools, discoverability.
Honestly, the design of good tools could be an entire post on it’s own, and I’ve digressed a bit here.
I just love it when easily readable code becomes “living” documentation.
4. It’s fun
I realize this isn’t the case for everyone, but I don’t think the fun factor should be overlooked for those who do enjoy it. Having fun automating a thing has an additional benefit of helping out with burnout. It can be a nice way of providing a break from tedious work that can also be productive at the same time.
5. It scales
Of course it depends on what you’re automating, but once it’s automated, it at least has the potential to scale up, even if it’s as simple as looping over your tool to do the thing many times. When you do something like that manually, scaling isn’t even possible.
6. You understand a problem space better
When you go to automate a thing you tend to better understand it. It isn’t always the case, and it depends on what you’re automating, but it is a learning experience, even more specifically than just learning to automate. The value of this understanding is what needs to be weighed when deciding to share some automation, more details about this in Possible problems.
Possible problems
When I think of the benefits, it’s hard for me to think of reasons I might not take the time to automate something. In situations where time is the #1 concern, it’s not the best idea. If a system is down, and you’re working on restoring services, it might not be the best time to slow down and automate a task you need to accomplish.
Tools need to be maintained. If you don’t maintain a tool, the worst that can happen is that it stops working. With computer work, it’s not as if we’re wasting physical space on storing broken tools. It also doesn’t require materials to repair, only time.
While I think that more or less sums up the times I might not choose to automate something personally, taking that extra step of sharing my automation with others can bring it’s own possible problems.
What if by automating this process, I prevent others from being able to understand how something works? I’m still working through this one, as I’m not sure if automating it necessarily hurts in this situation. Yes, someone might use my tool as a crutch, but at the same time, if I build it in such a way that is easy to understand and easy to extend, It can do more good than harm.
People who’s tools break and need help with them are likely going to need help doing the task anyway, and especially whenever something goes wrong. I’m not convinced we’re making things worse by automating and sharing automation, even when it’s half-baked.
Principles
Sharpen your axe. It’s hard to find the etymology of this parable, but it’s interesting I came across this article that links the idea to continuous improvement. These are very literally the equipment we use day to day, and it’s worth taking the time to create and maintain them.
Always be Knolling. This is one of Tom Sachs' “10 bullets”. It’s interesting I had in mind to share this under principles as I was writing this blog post, because I went back and watched the source video (Knolling bullet here), which I hadn’t seen in a while. While I do think it’s still applicable, I’m having to take a moment and think about why my mind went here.
You might immediately think the take-away is how we might organize our tools, but this post isn’t about organization or even design, even though we’ve touched on those points. The reason it’s a principle is because it highlights a general mindfulness we should take towards our tools.
If you talk to a carpenter, handyman, or mechanic, they’ll probably tell you they could always use more tools. The difference is their tools cost money, take up physical space, and need to be transported and stored in such a way to make them easily accessible. If you were to ask them if they could build all their own tools with nothing but time because the materials were limitless, recall them on the fly as if they had been magically summoned from a parallel universe, that’s the stuff of fantasy. The same is not true for our work.
Conclusion
… build all the tools.
-
I came across this definition of a jig I thought really highlighted the analogy:
↩︎on-the-spot device created to make the cutting or shaping of a part the wood in a project either more safe, more efficient, more accurate, more rapid, or any of a multitude of other reasons.