#+TITLE: Heuristics for Learning Tools

Hear are some heuristics that have helped me rapidly pick up and learn
new tools; I hope you find them useful! 

* Complex tools, like Vim, Emacs, IntelliJ, Butterflies, etc.
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

* Profilers, debuggers, tracers; introspection tools of all kinds
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.

* Data exploration and manipulation tools, pipelines, et al.
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.

* Watch experts at play
It can be hard to truly appreciate the potential of a tool before
seeing a master apply it. [fn:defection]

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.

[fn:defection] I defected to Emacs from Vim after spend a few months
in a team full of Emacs wizards manipulating Haskell in arcane
ways. It was extremely inspiring to watch them program.

* Building mastery
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.

* And now, for something completely different
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.

* Comments?
Drop me an email or reach out on Twitter.