Heuristics for Learning Tools

My path to proficiency with all my editors: Vim, Emacs, and IntelliJ has been to apply features one at a time once I needed them. That meant never blindly copying in a configuration, but instead slowly building it up over time.

All of these tools are extraordinarily powerful and are overwhelming if you attempt to pick up every feature from the beginning. Most of your energy should be focused on solving the problem you're working on with these tools. If you're spending more time trying to remember shortcuts, it's not going to work out very well.

Every time there's a feature you expect to exist: Google it. Learn how to apply it, and keep using it till it becomes intuitive. Move on to the next trick. Over time you'll build an impressive repertoire of skills.

Instead of jumping in and exploring both a complex new tool and diagnosing whatever performance issue you're trying to solve, first run it against a simple program you already understand well.

Because you already know exactly what the program is doing, you'll intuitively understand what the tool is showing you. More importantly, you'll realize it doesn't show you.

Sometimes it's worth creating a short test program and profiling it to make sure it shows up as you expected in the tool. This is a technique I've often seen Brendan Gregg reference in most of his tutorials, but I don't recall him explicitly calling it out.

For example, I started evaluating my Python tracer by running it against "Hello, World" – and realizing that sys.settrace doesn't intercept pure C functions, like print.

Similar to using a known, tiny program for profilers, I recommend using a tiny table with a few rows to understand how different data tools work.

Sanity checking that the graphs and statistical calculations match your expectations easily pays for itself many times over. Being paranoid while working with data is always a good idea because it's much harder to cross-validate results.

Even when you do have large sets of data, start by looking at the raw samples to validate any underlying assumptions.

It can be hard to truly appreciate the potential of a tool before seeing a master apply it. ¹

If possible, observe experts live – or even better, pair program with them– if you get the opportunity. They can be fairly hard to get access to, but happily there are several resources available online.

For example: Brendan Gregg constantly writes about what's possible with performance and debugging tools, Howard Abrams writes about Emacs and literate devops, and there's always Twitch.

Use the tool in anger: when you're under pressure and you need to deliver is when you'll find yourself quickly gaining competency and confidence. You'll also learn the limitations inherent in the tool.

Pressure doesn't necessarily need to be from production production; it can be as simple as taking part in Advent of Code and trying out a new editor while aiming for the leader board.

For Keyboards, and Keyboard Layouts I'd strongly recommend Type-racing. I've found nothing more satisfying than watching my typing speed climb back across 100 WPM after switching to Dvorak, and then again after switching to the Kinesis.

If I'm honest, shooting down alien spaceships was also fairly satisfying.

Drop me an email or reach out on Twitter.