(continued from Imperial Yaks; part of A Taxonomy of Yak Shaving series)
Each of the previous yaks stood in the way of a particular task. The Trim Yak is not so task-specific; these are the ones that let us work faster generally.
I nickname them “Hackhacking Yaks” after Lifehacking, which includes all the ways we change our environment in order to influence our own behavior. Change your world in order to change yourself, the feedback loop of human progress. Here, we’re talking about writing or configuring programs in order to change the way we code: Hackhacking. (It’s fun to say.)
At one extreme: how long between receiving your work laptop and when you can get work done smoothly? At least a couple days. There are essential Hackhacking yaks to shave here. Gotta install all the tools, gotta set up all the credentials. But then there’s more. Dotfiles, IDE configuration. For me, I cannot communicate in Slack until I’ve imported a few dozen essential emoji. To do that, I install a Chrome plugin and log in to Dropbox — Trim Yaks can stack up too.
These yaks may look like procrastination. And they can be, let run loose; configuring a keyboard shortcut can turn into writing a vim plugin.
For me, it’s stuff like, I have a library that’s used by another library that’s used by a service I want to test, which is a lot of installing and version-updating locally and doing that manually is just wrong and I want to automate it all! Or, something is wrong with my git repo, it’s in some weird state and I want to know how it got there and can I go read man pages until I understand it. Or, I hate changing nginx configuration because I don’t understand it, can I spend a day learning nginx configuration?
All of these things are useful. And they’re the kind of thing that when I do them, they pay off in ways I never would have expected. Automating the repository linkages (which I did on a weekend, for play) left me with a little toy program that later when I picked up Neo4J it was fast to implement a piece that makes a little dependency graph. Early in my git usage (this was 2012) I spent 6 hours (at work) watching a few videos and reading the book until I grasped the concepts. Later spent 45 minutes writing a talk that launched my speaking career. I still haven’t learned nginx configuration but gah! I so wish I had.
Trim yaks are about increasing our speed over time. It’s hard to know how useful a given Trim Yak will be; we might never use it again or we might use it a million times. Benefit is uncertain, so limit the cost.
Here’s a strategy:
Timebox! The first time something bugs you (“gosh, this code change could be faster, I bet the IDE has tools for this”), do it by hand. The second time, think about changing it: can you give it 15 min? that might be enough. If it isn’t, then the third or fourth time, give it an hour. Spend time only on what has proven useful.
And more considerations:
Stay curious! Learn a little bit more than you need to. I need one nginx option, I’ll look past the first StackOverflow answer, check the docs, and get a clue about why it works, or learn some new vocabulary word.
Pairing: I find pairing a big help with the Imperial Yaks; it helps to have someone else who is like “yeah we really have to fix this.” But it’s hard to shave Trim Yaks while pairing. Except! Pairing is a great time to share trimming tips. “I wish I had a faster way to do this, do you know one?” When your partner can help you get that IDE plugin set up, it’s efficient and also builds relationships.
Here’s the one Trim Yak that will pay off more than others: learning the system you work on. This is the one trick that separates hyperproductive developers from struggling ones: intimate knowledge of the system we work on. And it’s very, very hard to achieve in a system we didn’t write ourselves. Build your mental model at every opportunity. This yak that pays off most and fastest.
When pairing (or mobbing), learn what your partner (or everyone) knows.
When coding alone, dig around. Write tests, or break tests, or refactor. If you refactor, be careful: you built up your own mental model, your brain’s entwinement with the code, but you’ve invalidated the mental model other people have. Consider throwing the refactor away. Sometimes the team is like “this is a mess please change it,” but other times you’re not so much shaving a yak as combing the hair in a different direction.
Extract more value: Trim yaks increase personal productivity. If we take them a little farther, they can be generative. Post useful scripts or shortcuts in Slack. Document how to develop and test. If you do enjoy nginx configuration, tell people that you’re interested in it. They’ll be happy to share their nginx yaks with you next time, and you can build that skill. Blog! Those little tricks that you don’t use very often, let Google find them for you next time, and save hundreds of developers from your pain.
Share what you learn, and find out what’s holding other people back. You can do that with the next yak… the Royal Yak!