Learn how to build tools
Learn how to build tools
Dear new developer,
Our jobs and lives are full of repetition, and one of the beauties of being developers is that we can take steps to automate away some of the repetition.
Learning to automate, or at least minimise, some of that repetition is a great way to optimise your work. It can allow you to get your tools or boilerplate code out of the way, and allow you to focus on the value-add proposition for your work, and aside from just automating the task at hand, can have a tonne of other benefits.
To learn how to make small changes to make you more efficient
Something I've enjoyed over the years is trying to improve my ability to complete tasks, whether that means learning a keyboard shortcut to save clicking around a couple of menus, or learning some of the different parts of git
I wouldn't usually use. Being able to get a feel for areas that are repetitive isn't just something that can improve your own life, but can be used to discover behaviours in your team or organisation that could be improved.
It's a little morbid, but Scott Hanselman has written about how you have a finite number of keystrokes you have left until you die, and so making small improvements to shave a few keystrokes here and there can allow you to save time to work on more meaningful things in your life.
Consider that you're working on a project with Gradle, and you're consistently finding you write ./gradlew clean build
or ../../../gradlew test
a lot. An alternative helper script to speed this up could allow you to call g clean build
, which works regardless of where in the project you're running from.
Every step you take to making improvements on how you work can make you feel like you've got superpowers, which can be a pretty fun outcome 🦸
To learn more about your company, team, tools
As a newer developer in your team or company, finding areas to automate and improve can be a great opportunity to find out why things the way they are, as well as finding ways to improve things.
One of the first widely pieces of automation I built at my first company was to open a browser up with the logs for our web application. This gave me a good understanding of how our web application worked and where and how logs were stored.
There will almost certainly be areas of your teams' processes that could be better managed, or common tasks that could be even partially automated, and even through looking at areas to automate, you'll get a much better understanding of how things work.
To learn more and different things about your language
By building tools, you can learn more about how your language and tools work. As mentioned above, I'd built a tool to open the latest logs for our web application. This sounds trivial, but it actually involved:
- Take an optional command-line argument for whether to use the test environment or production
- Send a GET request to a JSON metadata endpoint to get information about the app's AWS CloudFormation deployment
- Construct a URL to AWS CloudWatch log group
- Open the browser
My team was writing a lot of Chef cookbooks, which is a configuration management tool built in Ruby, so I opted for Ruby as a way to give myself a bit more of a chance to practice, and because I knew that the team would have Ruby installed.
This seemingly straightforward script gave me a few areas to learn more about and try out different approaches, such as giving me a smaller project to play around with debugging or trying different HTTP clients to compare alongside Ruby's standard library.
To try something new
Building tools is a great opportunity to try some new libraries, new languages and technologies, especially as they are often fairly small in scope and work required.
As a backend engineer who's been using Linux and the command-line for several years by the time I got my first job, I was much more comfortable building command-line tools. I'd got lots of experience building shell scripts, but wanted to build something with a bit more so started scripting in Python and Ruby.
But as a backend engineer who focusses a lot on building tools for the command-line, every so often I look to build something web-based for an appreciation of different tooling, and to learn how to build tools that can work for folks who don't necessarily want - or need - to use the command-line to achieve a task.
If you're an engineer who's used to always writing everything by hand, why not try a low-code tool, like IFTTT or Zapier?
If you usually reach for a scripting language like Ruby or JavaScript, try a plain shell script to get a feel what it's like to not have a standard library to use.
To learn how to build tools for others
Building tools is also a great way to learn about how to think outside of your own use case, as it can lead you into thinking about the user experience of the tool for people who aren't you.
If it's a command-line tool, does it have a -h
or --help
flag? Do errors explain what's gone wrong, or does someone need to look at the source code to understand what's gone wrong? Can you build it in a way that feels familiar to use - for instance, following conventions introduced used by similar tooling - or does it need a terse interface?
Probably the most important question will be "does it solve the problem it's built for", which may require more insight into the problem area and learning from others what they're trying to do with it.
Aside from making it possible for others to use, you also need to consider how you'll package it for installation or how others will access it.
For instance, are you assuming that everyone is on the same Operating System? Mac OSX's versions of tools are different to those on Linux or Windows, which means that you need to write tools to either be compliant with the different versions, or you add an additional requirement to folks running the scripts.
How would you package the tool? If it's a shell script it may be self-contained, but what if it's a ~1GB set of files? If it's a web application, does it require someone to log in, if so how will access be managed? If it's using a scripting language, do you know what range(s) of language versions will be used?
Notice how in my example around web application logs above I used Ruby as I knew everyone would have it installed, where I also knew everyone was on a specific version of Ruby to make things even easier.
To have fun
Finally, have some fun with it! A friend of mine paid for a new PlayStation 5 by setting up an automation to save 20p every time he tweeted, and you too could probably do something interesting that doesn't have to be within the realms of work.
Bio
Jamie Tanna is a serial blogger, builder, and Open Source advocate.