Have high expectations of tools

Tools are multipliers. Rather, tools can be multipliers, but all too often they’re not. Or rather, they multiply distraction rather than productivity. Like any other craft, software developers need tools to do their job. On the obvious end, tools are physical implements like computers and mobile devices. Design and development applications like your terminal, text editor, web applications, and other coding tools count as well. Then there’s open source packages and frameworks. Even analog implements like pen and paper are tools of the trade.

And we’re always on the lookout for new and better tools—a process which can be a distraction as well. The right tools can work wonders for productivity, but too often we don’t question the net productivity of our tools. With physical tools, it’s important to keep a variety of tools for very specialized tasks, but with software, teams have a tendency to continuously add more and more tools to their development stack and workflow regardless of whether they’re necessary or even the best tool for the job.

Evaluate the net benefit of tools

With every new tool, it’s not just about the upside. Tangible things like learning curves can help temper our adoption of new tools, but sometimes, it’s the more subtle drawbacks that go unnoticed until we’re in too deep. Maybe we over-engineer our stack or add an open-source package that increases maintenance or exposure to security risks.

In some cases, tools may save a little bit of time, but in the case of packages or frameworks, every time there’s a new release, the upgrade process can be painful. Then dependencies come into play. While package management tools have helped, there’s often still a spider web of dependencies that each bring their own baggage. The result is that you’re forced to either spend time upgrading or delay upgrading and accept the associated risks. Either way, more tools means more maintenance of those tools.

And that’s the best case. What happens if a package stops being maintained? Do you have the knowledge to update it yourself? What if a package or library you use has several additional dependencies and one of those stops being maintained? There’s a significant level of risk with the adoption of packages. The question of whether it will save you time now isn’t the important one. Will it save you time over the life of improving and maintaining your code? All of this contributes to focus. Maintaining code is part of building anything, but there’s a point where maintenance shouldn’t be significantly detracting from improvement.

Commit to your tools and become an expert

That’s enough about your codebase. You know that maintenance can be distracting. What about the applications you install on your machine? How well do you know your text editor? How’s your keyboard shortcut game? Are you pushing it to its limits? What about your terminal and related tools? Or do you spend so much time trying every new tool that you’re not great with any of them?

Getting to know your primary tools forward and backward is one of the best ways to stay in the zone. Sometimes that’s memorizing keyboard shortcuts. Other times, it may mean watching a few hours of tutorials. More often than not, your best bet is getting to know your existing tools better rather than hoping some other tool will elevate your productivity simply from switching. You want to get to a point where your primary tools are almost extensions of how you think and work. Muscle memory takes over, and you no longer have to think about the tool. You just use it, and it just works.

That’s not to say that there’s not a time and place to try new tools. Learning curves for development tools are steep, and so the cost of adopting a new tool is significant, but at some point, there’s likely going to be a new tool that’s worth the learning curve. The key is to avoid being haphazard with trying new tools. Make a point to be deliberate about investigating new tools.

Don’t default to digital tools

One of the most under-rated tools for programming is our good old-fashioned analog tools like pen and paper. Writing and drawing ideas before setting out to write code can help you think from a different angle. Programming may require a computer, but thinking doesn’t. In some ways, thinking can’t happen at a computer because it’s constantly pinging you with notifications and other distractions. When we’re at a computer, we often fall into the traps of thinking based on the way computers allow us to create. Pen and paper can help remove some of those limitations.

Leverage tools for heavy lifting

Finally, don’t hesitate to streamline regular processes like deployments. It may take some time to move from manually syncing files and restarting servers, but it’s worth it. Similarly, as your stack grows, your release process will invariably break down or struggle. When something goes wrong, it’s worth it to fix the problem rather than let it fester and just deal with it manually. Resilience and flexibility are your friends, and building those into your own tools will save plenty of time dealing with things that aren’t directly productive. We’ll address that more in the automation chapter.

Regardless of the tools that work for you, always have high expectations. Do they enable you to focus, or do they force you to get sidetracked? Once you’re familiar with it, does it feel effortless, or does it feel like you’re fighting it? Do you fully utilize its capabilities or just a small portion? If a tool doesn’t support or free you, fix it or fire it.

Your next steps

1. Pay close attention to the net benefit of your tools.
2. Be deliberate about investigating new tools without bouncing from tool to tool.
3. Take time to learn the keyboard shortcuts and power features of your tools.
4. Look for advanced tutorials for your text editor/IDE of choice.
5. Turn to analog tools like pen/pencil and paper more frequently.