The best tools money can buy

November 3, 2021
In the best interest of the IT system as a whole, optimize for the engineer's time, since that time is expensive.

Once upon a time, the computer was the most expensive component of any IT system. At that time, it often made sense to spend a few extra hours optimizing a for loop, or rewriting a function to use a few bytes less memory, to avoid the need for a major hardware upgrade. Those days are long gone.

Today, in most IT systems, human engineers are the most expensive component. These days it doesn’t make sense to optimize a function to use a few less bytes of memory, except in the rarest of performance-critical pieces of code.

This means it’s in the best interest of the IT system as a whole to optimize for the engineer’s time, since that time is expensive.

But how do you know which tools optimize for an engineer’s time? Should you give your engineer a RAM upgrade? A more efficient IDE? A different operating system?

Fortunately, this doesn’t need to be complicated. Here I offer two simple rules that you can employ immediately, to boost your engineering productivity:

  1. Buy the best tools money can buy.

    If you’re debating between a 16gb laptop and a 32gb laptop, get the better one. Don’t even worry about “But will this person really use the extra RAM?” The time spent making that decision is an opportunity cost. And almost certainly they will use it, if not immediately, in 6 months when they install some new plugins to their IDE.

    You don’t need to rush out and buy a new laptop for all your engineers every time a new model comes out, of course. But any time there’s a significant upgrade available, it’s probably worth the cost. And the employee goodwill earned by the occasional upgrades is priceless!

  2. Buy the tools each engineer is most comfortable with.

    Do you have some engineers who prefer IntelliJ, and others who prefer Visual Studio? Do some engineers want Windows, and others Mac? Don’t worry about bulk discounts. Just buy the licenses they are most comfortable with.

    Except in the case of serious security or other legitimate business concerns, give each engineer their preferred tools.

Share this

Related Content

Adventures in DevOps 125: The Pull Request Paradox with Yishai Beeri

Yishai Beeri of LinearB discusses strategies to improve flow of PRs and code review with smarter tooling.

you.sh

If someone were to name a shell script after you, what would it do?

Adventures in DevOps 111: Infrastructure as code and Amazon CDK

Have you considered the significance of infrastructure as code and its importance in the industry?