As engineers, we’re obsessed with efficiency and productivity. From carrying around a decade’s worth of configuration in an .rc file to setting up your favorite IDE to techniques like Inbox Zero to the gadgets like Fitbit, there are a lot of software and hardware trying to convince you that your life (and work) can improve.
In the end, though, I believe whether any of this stuff works depends largely on the individual. That said, here are some things I’ve found useful for software programming.
Hardware
Buy the best hardware that will make your workflow as optimized as possible. For some this may mean a 11″ Macbook Air they can take on the plane, for others it will be dual 27″ monitors connected to a quad-core desktop loaded with RAM and SSDs.
It will also mean having enough hardware for builds, staging, and other non-dev environments. Nothing kills productivity faster than waiting a day for the build to go green.
Software
Pick a text editor/IDE and become good at it. Learn to type at a decent speed, and learn the keyboard shortcuts and commands that will let you perform trivial coding tasks. On a similar note, learning a few common command line utilities for file searching will greatly decrease your downtime when not furiously adding lines of code.
Figure out the right communication tools between developers (and QA + product + design) is important too. Version control is standard nowadays, but also avenues for code reviews, discussions, and a wiki for keeping around tidbits of info. Project and bug tracking is necessary to capture actionable work, and I’ve found agile-style daily syncs with weekly emails a good balance of understanding the context at a local and company level.
People
Okay, so this stretches the definition a bit, but meetings, distractions, and constant project churn absolutely destroy productivity. Meetings, most will learn to manage themselves and schedule them together or block out coding time. Some programmers like coding with headphones, but earplugs also work, and it’s not unreasonable to have a relatively quiet, distraction-free work environment as well. As for project work, let your manager or project person understand the conditions for optimal development.
Know Yourself
Everybody codes slightly differently. I’ve found rigid solutions like the Pomodoro technique to not work for me; and while some can stay in the zone for hours, I find going 1-3 hours of work followed by a break works well for me. That feeling where you’re mostly-burnt-out and half-mindlessly-coding is one step beyond where you want to want to be at the end of the day.
It’s no coincidence that top software firms measure results more than hours, and let their developers manage their own schedules and projects. People who make it into these companies have largely figured out how their workflow is structured and it wouldn’t make sense for the company to disrupt that productivity.
I’m trying something slightly different, in repurposing some of my Quora answers onto this blog and dispersing it to a wider audience. The original question and answer is here.
