Productivity habits for software developers

Writing code is fast. And a few lines of code is capable of doing incredible things. Then why can building software take so long?

While I can't give a concrete answer to that question, over the years I have found several areas where employing certain habits can significantly boost developers' productivity.

In this post I'll outline some of these habits, and provide a few resources for stepping up your productivity game.

Understanding Requirements

When we are writing software we are usually trying to meet a set of requirements, often provided by another person. In order to be productive, we need to "produce" working code that meets those requirements.

Generally understanding the requirements is not the time consuming part, the producing part is. And if you produce a solution that does not meet the requirements, you will have to go back and produce more code. Nothing will waste your time more than working on the wrong thing.

Alternatively, if you take extra time to review and understand the requirements it can significantly lessen the amount of rework on a given task.

Good habits to follow:

If requirements are written down, read them 2-3 times. If they are not, write them down so at the very least you are clear on what you're delivering.
Always spend time brainstorming any assumptions you can think of and write those down as well. Get clarification on these assumptions before writing any code.
If requirements change, be sure to update the written requirements so everyone is clear (including you) on what to expect from your work.

Designing Before You Code

Once you have your set of requirements, it can be tempting to jump straight into coding. Don't do it! Code needs to not only be written, but designed. Whether you are adding code to an existing codebase or starting on a brand new project, it should be done according to a design.

Understanding and following a design from the get-go can have a significant impact on your productivity, and will often prevent you from painting ourself into a corner. Without planning and designing your approach you'll need to rely on trial and error to get something to work which is incredibly inefficient, can result in both rework and excess troubleshooting, and may go against previously established designs and patterns.

Once you've developed your initial plan, your planning is still not done. Things will change, realizations will be had, and you'll probably need to modify your plan; and that's OK! As long as you are following and iterating on your plan you'll be much more productive than the alternative.

Good habits to follow:

Write down your plan in the form of comments in your code. Every function, file, or variable that you think you'll touch should have some sort of comment around what you plan to do.
Draw pictures of the existing design and/or the design you plan to implement.
Review your plan with a colleague.
Do a proof of concept if you're not 100% sure how something will work.

Breaking Down Work

Another aspect of planning is understanding what you'll be doing and when. To do this you should break your work into chunks -- each equating to one small/medium sized pull request -- and decide the sequence which you'll work on them.

When starting on a particular "chunk" it can also be helpful to break it down further into subtasks. Having a small manageable task can reduce the barrier to entry when starting work, and makes it easy to jump back in when you've lost context for a while.

You will be much more productive once you've removed the mental overhead of deciding what your next immediate task is, which is a very common distraction.

Good habits to follow:

Keep your chunks of work visible so people know what you're working on and can hold you accountable.
Reduce the burden of context switching by breaking your work into small tasks, or at the very least writing yourself a note when you are about to switch contexts.

Over-communicating

Communicating early and often about your work can not only boost productivity, but is also essential for career growth; strong communication is an invaluable skill for developers. It is one of the best ways to prevent rework, and can save you from many hours of troubleshooting.

Often colleagues will have amazing insights into not only how to solve a problem, but what the right problem is to be solving. Communicating about what you're working on opens up the door for lots of helpful feedback and help.

Good habits to follow:

Track your work in a place that is visible to everyone, and keep it up to date.
Review work with other project stakeholders frequently so you can incorporate their feedback early.
Be proactive about asking questions around your approach as well as your code.
Communicate potential trade-offs (something businesses rely heavily on developers for) and loop in stakeholders so they can help decide the best solution.

Hibernating

Once you have your design, established a plan, written down your tasks, and collected feedback...hibernate! You will be most productive when you have a distraction free environment, and this should be a top priority if you want to be productive on a daily basis.

Do what you need to do -- block off your calendar, put on headphones, go to a coffee shop -- to get a few hours to focus and into a "flow" state. This is when your work actually gets done and is probably the most important aspect of being productive as a developer.

Good habits to follow:

Know your best working hours and develop a schedule where you are able to work during that time.
Let teammates know when you'll be unavailable and why, so you don't feel guilty ignoring emails or messages.

Testing & Refactoring

Writing tests as you code probably won't save you multiple hours of coding, it will save you multiple WEEKS! It can be hard to see the benefit in writing tests when you are initially building something since it increases the time required to complete a feature. But it does help in two specific ways: 1) framing the problem you are trying to solve, and 2) making refactoring less error-prone.

When you've properly framed your problem it becomes much harder to end up working on irrelevant tasks, which is probably one of the most common distractions and productivity killer for developers.

Refactoring code is a crucial tool for staying productive; it's one of the best ways to quickly understand how things are working both now and in the future (and your colleagues will thank you). Being able refactor without the risk of breaking things is a great way to boost productivity.

Good habits to follow:

If possible try to use test driven development when writing code.
Keep track of test coverage; high coverage increases the ease of refactoring.
Separate your chunks of work into refactoring OR feature/bug development work, not both at once.
Focus on functionality and tests first, then refactor for cleanliness and readability.

Knowing Your Tools

Whatever tools you use, make sure you have a deep understanding of how they work. If you don't, set time aside to learn them. Examples of things you should know are: keyboard shortcuts, automation tools, framework APIs, programming language quirks, and the list goes on.

Using your tools in a streamlined way will likely only save you a few minutes per day, but this time really adds up over multiple months. Taking a few hours away from work to understand your tools will pay major dividends after using those tools over long periods of time.

Good habits to follow:

Automate as much as possible. Terminal aliases are a fast and easy way to automate parts of your workflow.
Invest serious time into learning, and staying up to date, on any programming language(s) you use frequently.
Before you use a library/framework, read the docs! Even if you won't be using all of the features, it's extremely helpful to understand the surface area; you never know what features will come in handy and save you time.

Managing Time Efficiently

This seems like an obvious way to boost productivity, but it's easier said than done. As a developer you'll likely only have 2-5 hours a day to "produce", so you need to make those hours count.

Be conscious of how you are spending your time. One hour of extremely focused time can be much more valuable than multiple hours of unfocused time. If there are particular things you find yourself wasting time on repeatedly, write them down and figure out ways to reduce that time.

Good habits to follow:

Don't pre-optimize or write super generalized/flexible code, until it's absolutely needed.
DO optimize for simplicity. Make code easy to read with minimal complexity.
Take breaks. Sometimes the best solutions to problems come to us during breaks, not while writing code.
Commit often so you're not keeping track of large sets of changes.
Don't be afraid to wipe out changes if you get stuck or aren't sure you're building the right thing.
Capture additional work in your notes, but put it aside to work on later.
Use a system like GTD (Getting Things Done) to help manage a variety of tasks, both development and non-development related.

Conclusion

While these habits are relatively simple, making them part of your daily routine can be quite a challenge. Try to pay extra attention to how you are spending your time each day. When you are doing something that you shouldn't, take note and be sure to work on it again the following day.

While I personally have benefited from many of these habits, I find myself falling back to bad habits all of the time. Writing down your habits and/or discussing them with colleagues is a great way to keep them top of mind.

Additional Resources

Here are a few resources that I've found very helpful when trying to optimize productivity.

Books

The War of Art by Steven Pressfield
Getting Things Done by Davis Allen
Atomic Habits by James Clear

Software

Trello (trello.com) - for task management (although Jira is a more popular tools for development teams).
Evernote (evernote.com) - for storing notes, documentation, cheat sheets, etc.

Techniques

Pomodoro - break work into 25 min increments with 5 min breaks.
GTD - learn more in David Allen's Getting Things Done book.
"Eat the frog" - a phrase derived from a quote by Mark Twain encouraging you to start the day by working on the most important/difficult task. There is also a book (which I haven't read) called Eat That Frog! by Brian Tracy.