Putting Lazy to Work
I’ve always been practical, but… I have a confession: I also have some potentially less desirable character traits. I tend to be somewhat impatient (I hate waiting), and lazy (repetitive work annoys me to no end, and I will stall or avoid it). I find that having these specific traits are remarkably useful in software development, and so I listen to that inner voice — constructively. Concretely, it’s forced me to look for better ways to do whatever I’m doing. Perhaps it’s something mundane like getting a list of email addresses properly formatted or running a short set of steps in a debugging session, but the message my brain sends is “find a better way than brute-forcing it”. This sort of thing comes up regularly, even if they’re small in scope and only take a few minutes.
Looking for opportunities to do work better is not a unique trait. We all do it. The key to success that I’ve found is a combination of two key things: having a continuous inner dialog scanning for opportunities, and the second is around having a diverse set of “tools” in your toolbox . Let’s talk more about them…
Having an inner dialog is important as there’s always a balance to strike. If you go and automate/optimize everything all the time, you’ll be exhausted ineffective as there really are a bunch of one-off things. On the other hand, if you never automate, you end up doing the simple stuff all day. Finding a balance is key, but it’s always better to have the mental dialog saying “should I automate this? How much work is it? What’s the benefit?” and rejecting, vs not having it. Often that mental exercise takes a few seconds, and benefits you by practicing planning, and moves you further towards a very intentional approach.
Why did I say it’s important to have a diverse set of tools — while talking about working better? Because understanding tools help shape the way you think about problems. At the heart of it, we’re pattern matchers, and knowing more patterns to match to helps. Back in university (working on a Math degree), it was all about reducing problems into a known form. If you know regex, or sed, or templating languages, it really extends the capabilities you have at your disposal.
I propose all the following skills are key to have in your “toolbelt”:
First, learn to touch type. While it’s not trivial, it will repay itself over time. I know speech-to-text is getting better, but the reality is you’ll still type a lot over your career. Reducing the friction on getting thoughts into the computer saves time in a major way. I’ve seen impressively fast hunt-and-peck typists, but it’s the exception, not the rule.
Text editor macros: find a text editor that allows macros. I’m not going to step into the world of emacs vs vi vs <IDE of choice> but… there’s a bunch of simple tricks here:
Find out in your editor of choice how to do this. If you can’t, find a backup editor you like that does for when you might need it. It’s amazing how much can be automated this way. I fix malformed email lists, do cleanups of large text files, scrape log files for key metrics, etc… with little effort via careful use of macros that can capture fairly complex sequences of action.
Make: learn how to use make (trivially). While there are many, many other build tools out there, make stands out for simplicity and language-agnostic capabilities. To be clear, I’m not saying to use make instead of gradle, etc.. for highly opinionated build tasks that also manage remote libraries, etc.. (as befits your language of choice). However, because it’s not language-opinionated, it’s a great tool to have handy and makes a bunch of simple automation easy.
https://www.gnu.org/software/make/manual/html_node/Simple-Makefile.html#Simple-Makefile
Python — while it’s a very powerful language that can take years to really master, getting to “slightly more than hello world” familiarity is easy to achieve, and very powerful. It’s ubiquitous and has libraries for almost everything. The roots were around scripting, and it’s good at that. While many folks try to stay in “long chain of unix commands piped together” (and that’s cool if you can do it), I mostly reach to python when in that mode. It’s easy to debug and observe. It’s not the fastest thing out there, but good enough for a lot in 2021.
Regexes (aka “now they have two problems”) — in whatever language you like. This may be somewhat controversial but knowing how to use regexes well is useful. It’s not the answer to every problem, and one of my favourite blog entries on Coding Horror gives fantastic guidance on the right time and place to use them: https://blog.codinghorror.com/regular-expressions-now-you-have-two-problems/
I hope the above list helps; I know it’s helped me a lot. Everyone has their own productivity hacks, but I’ve found that when I properly harness my internal resistance to brute-forcing something, I learn a lot. I’ve happily spent hours reading how to use macros, master tools, template languages, etc., all in aid of avoiding activities that could be done by just sitting down and forcing my way through.
The value of learning how to automate is critical in the profession. To me, it’s multiple wins: beyond satisfying my potential “character defects”, it also forces me to get to the heart of issues. It’s about repeatability, consistency, and scaling. If you can codify steps, you understand them and then can share, optimize, and repeat safely. And the more you internalize that in everything you do, the better you become at it. Now go be lazy… I mean… learn something!
