“Sharpest tool in the shed” by Lachlan Donald, cropped (cc-by)
Developers working on the same project often have wildly different workflows, based on how they like to work and the tools they are familiar with. Despite that, there are usually a few common tasks that everyone has to do.
If we compare the flow state of writing software to Mario speeding through a level in Super Mario Bros., then development tools provide the stable bridge above the fiery pit that allows Mario to safely navigate through the complex castle that is his project.
Mario thinks that this castle will be his last. Don’t tell him what happens during Product Review!
To stay in the flow state, engineers must avoid the pitfalls that come with interactions across the systems that make up a development environment, such as source control, testing, linting, and code review tools. When all goes well, an engineer happily skims across the surface of these tools and repeats the process. As any engineer will tell you, this is sometimes easier said than done.
Over time, engineers here at Slack developed their own individual workflows for getting things done. The slack-cli project was born when we decided to take some of our ad-hoc shell scripts and package them together in a tidy way. Offering up a shared set of tools had a number of benefits:
In some cases, this process is not much more involved than sharing common terminal aliases and scripts. In other cases, many individuals have riffed on a tool over time to support complex use cases. Overall, the goal was to reduce friction in a developer’s work day wherever possible.
A good rule of thumb for a development tool is this: if a developer has to stop what she’s doing and open a browser window for the next step in her work, then that task is a good candidate for building tooling around.
Is it because engineers ought to do everything from the command line? No, but the internet is a veritable Candyland for the monkey mind, filled with delightful distractions that are unrelated to your current work. Slack wants to enable employees to do the best work of their lives, and providing a focused environment through tooling reinforces that value.
Having a place for tools to live opened up all kinds of interesting possibilities. Once we had a structure in place that made it easy for people to add new commands, we started to see the tool get used in both expected and unexpected ways. Here are some of the less obvious uses: