Productivity Hacks
Engineers love nothing more than hacking on our own productivity. At its worst, it becomes its own form of procrastination (hence the term “yak shaving”) but at its finest, it allows us to tackle ever-larger and more complicated problems and streamlines our entrance to the exalted state of flow.
I learned the lesson early. As Netscape’s first summer intern in 1995, I’d broken the build once, survived the wrath of jwz, and never made that mistake again. I returned for a second internship in the summer of 1996 to find a company transformed by growth. With new hires and interns pouring in every week, the build was broken almost every day. In 1995 there had been a grand total of thirty engineers working on the browser, across Windows, Unix, and Mac. In 1996… well, no one was really sure — but there were three hundred people on the clienteng mailing list.
The legendary Terry Weissman was working on the flagship new feature for Netscape 3.0: e-mail. Progress was glacial thanks to the constant churn. As I recall, at some point, Terry decided that this was insanity, put his browser work aside, and set to work writing tools that became Bonsai and Tinderbox (predecessors of today’s continuous integration tools.) When he was done, the build went green and (mostly) stayed green. I was a baby duckling, and I imprinted: even when you are behind — actually, ESPECIALLY when you are behind — stopping and fixing the underlying problem is smarter than just putting in more hours.
Not every productivity hack is the equivalent of adopting continuous integration, but here’s a compilation of some of my favorites, with special thanks to my friends on facebook for all the suggestions.
- Meta-productivity. Before you apply the rest of the list, make sure you’re working on solving the right problem, that you’ve prioritized just the work that needs to be done, and you have the skills or get the help needed to do the work. I can’t emphasize enough what a waste it is to head 100mph in the wrong direction.
- Go in the right order; in particular, always front load risk. As Leo points out in the linked post, you don’t want to waste work on trivial preliminaries in an approach that turns out to be impossible or unusable once you finally turn to the hard part. Another reason: the hard part usually takes the longest and most unpredictable amount of time. Putting it first gives you more time to recover from unexpected delays.
- On that note, test first. Yes, I literally mean, write the unit tests before the code. It forces you to have the discipline to figure out the interface and expectations of your code before writing it, and to get tighter feedback loops as you write the code. A subtler but beautiful emergent property is that when you design with testability in mind, you will write cleaner and more well-structured code.
- There’s nothing more daunting than a blank sheet of paper. If you’re stuck getting started, just start typing. Sometimes it’s easier to react to a stake in the ground (even a wrong one) than to conceptualize the right thing from scratch. It’s a little evil, but this technique works great on other people. Blocked on someone else’s part of the project? Send them a crappy first draft of their work, even an outline of thoughts; you’ll be astonished how fast they can leap into motion in response.
- Trick your procrastinating mind. If you‘ve been stalling and you know it, promise yourself that you’ll only work for five minutes and then stop. Five minutes is plenty of time to get into flow after which stopping will be the last thing on your mind. If your hindbrain is too smart or too stubborn to be fooled by this trick, try the master class: structured procrastination.
- Be lucky enough to work on something that really motivates you — failing that, figure out what does motivate you about your work. Maybe you get to work on cool new technology and solve challenging problems — maybe you don’t. Maybe your work affects lots of people, or meaningfully affects a few. Maybe it isn’t saving the world, but still helps your customer’s bottom line. Even the most boring scut-work involves coming through for your team and being someone they can rely on.
- Invest in optimizing your physical setup. Your chair, mouse, keyboard, and monitor are all opportunities for solid 5–10% efficiency gains or more. That’s hours a week if you code every day! If you write compiled code (thanks a lot, mobile apps, for bringing back problems we thought died in the 90's) then it pays to max out your hardware. Big difference between a 60 second and a 90 second compile time when you build dozens of times in a programming session.
- Invest in optimizing your “logical” setup: window management, screen colors, keyboard shortcuts, the works. Facebook engineer Erin Summers: “Taking hours or even a day to set up a good working environment will save you days of work. Especially learning shortcuts for moving around code in your programming environment.”
- Don’t sacrifice exercise or sleep. You may feel like you’re adding more hours to your day, but it’s at best a short term optimization that goes net negative very quickly. Pay attention to your personal energy. Are you most productive in the morning or evening? Would an afternoon snack or lunchtime workout help you power through?
- Fix your calendar. Batch up meetings and collaboration so you can devote big blocks to “maker time.” That linked article is a classic worth reading, but one caveat: it fails to recognize the importance of teamwork — for any project of significance, you will require collaboration time with other makers to enable the productive blocks of coding time!
- Eliminate interruptions when you are programming. Even a momentary loss of concentration can cost you 15 minutes to get momentum back.
- Use a weekly plan (optionally, shared with your team as a weekly status report) to organize your thinking about what you’ll get done. It will force you to be crisp about how many things you can work on at once, and what your real priorities are.
- Understand when to tackle technical debt. Yes, it is slowing you down. But replacing old debt with new debt won’t speed you up. Fix it when you have something clearly better in mind.
- Keep honing your craft to become a better software engineer. Read books, blog posts, and other people’s code. Enroll in online classes, embrace code review feedback, and challenge yourself with projects outside your comfort zone.
- Don’t just focus on learning new languages and frameworks. Your goal is to become a better designer — whether of code, systems, or even UX. Forming the judgment to find sweet spots between ugly hacks and over optimization will take you a lifetime. The journey is its own reward.
Got more productivity hacks? I’d love to see them in responses!
