How to Be a Productive Dev

Feb 24, 2020 · 13 min read

For this post I’m going to explore some of the ways that have helped me and may help you become more a productive dev. I’m not going to talk about practices such as Agile, Scrum or DevOps because those are focussed on teams. In this post I want to focus on the individual developer and how they can improve their own productivity.

The Developer

Let’s start with the obvious, but often overlooked (and most important) area, the developer.

Your Health

Eating unhealthy food and a lack of exercise not only make you feel bad, they have a huge impact on performance. The brain needs a good source of fuel to function and in the same way an athlete needs to fuel their body correctly, the brain needs the right kind of nutrition to fuel it.

Stress can also affect performance dramatically. If your feeling stressed at the office (either because of work or for personal reasons) try to find ways to unwind and relax before you continue. For me, listening to chilled music or calming sounds such as recorded rainfall or ocean waves can help. Also, go out for a walk and get some fresh air.

Sleep is a big one, it’s vital you get enough sleep. I always think it would be good if workplaces provided a quite sleeping area for those of us with kids, so we could take a quick 30-60 minute power nap. It may seem like a waste of time, but you will be so much more productive after having a bit of extra sleep and you will easily make that time up.

Not everyone likes to exercise, but it does boost brain activity plus a whole bunch of other things. I find running dramatically helps with my ability to concentrate, solve problems and come up with new ideas.

Brain Training

There are various approaches to brain training - a program of regular activities intended to maintain or improve one’s cognitive abilities. However, my preferred approach is to learn a new language. I’m not talking about a new programming language, but an actual spoken language. There are many benefits to learning a new language, helping improve people’s thinking skills and memory abilities.

My wife is Mexican, so her first language is Spanish, and admittedly my Spanish is not that great! But I couldn’t speak a word of Spanish before we met, and learning has helped with my ability to multitask and remember things.

Positive Attitude

Having a positive attitude can increase productivity in the workplace. It’s easy to focus on the negative stuff, but by putting a positive spin on every challenge you face, you will fare much better. There are many ways to help keep you positive, and by having a more positive attitude towards work, the rewards will extend beyond just the office and into personal life.

Reduce Cognitive Load

Don’t try to take on too much at once. You can only think about one problem at a time and there more you place in your head, the less productive you will become. Usually, problems will be too large to keep in your head at once.

What I do, is break them down into tasks small enough to keep in your head at a time. Write them all down, in order, on paper (alternatively notepad or whatever you prefer) and just work on one at a time. This way you can flush everything else out of your head and just think about a single ‘bite sized’ task at a time. You will get through these tasks much faster than you would have otherwise.

Time Management

Break down your time into smaller intervals with a small break in between. This is known as the Pomodoro Technique and traditionally breaks time down into 25 minute chunks. There are usually six steps to the technique, but these can be adjusted to suit you:

Decide on the task to be done.
Set the pomodoro timer (traditionally to 25 minutes).
Work on the task.
End work when the timer rings and put a checkmark on a piece of paper.
If you have fewer than four checkmarks, take a short break (3–5 minutes), then go to step 2.
After four pomodoros, take a longer break (15–30 minutes), reset your checkmark count to zero, then go to step 1.

So for example, if you work an 8 hour day (excluding lunch), you can break that down into 16 intervals of work with 14 breaks of about 5 minutes between.

Software developer and music producer Carl Franklin has created a productivity tool called Music to Code By precisely for this technique. It’s worth checking out.

Focus

This may seem obvious, but it’s very easy to loose focus on the task in hand. It’s important not to let side issues distract you from the problem you are trying to solve. If something unexpected comes up that’s not directly related to the task you are working on, make a note and come back to it later.

Minimize Distractions

Make sure there aren’t too many distractions in your workspace. Remove clutter from desks, close down unnecessary windows, browser tabs and put your phone out of sight. The fewer distractions, the easier it is to focus on what you are doing.

Avoid Context Switching

We may like to think we are good at multitasking but context switching is a real problem for developers. Like most other devs, I use the ‘earphones in means I’m in the zone’ trick to try and deter would be interrupters.

But there will always be the inevitable interruption, usually it’s my boss who starts off by saying ‘Craig, question for you…’ and after the internal rage has eased and his question has been answered, I’m left in a sort of void state where I can’t remember what I was doing before being interrupted. It takes most developers around 15 minutes to regain focus after being interrupted.

Tooling

It’s clear that good tooling makes a huge difference to productivity. Just imagine having to edit all your source code using Notepad instead of Visual Studio (or what ever IDE you use)! However, many of us probably aren’t utilizing some of the great tools out there, usually because we just don’t know about them.

There are a whole bunch of great tools and tips just for Visual Studio alone, but there are also plenty of productivity tools for all disciplines out there.

Don’t forget to automate where possible. From unit testing frameworks such as NUnit or end-to-end testing frameworks such as Selenium or cypress, there are plenty of tools out there to help you. Many devs write custom scripts to automate mundane tasks, such as aggregating files. One of the big areas you should learn about if you aren’t already familiar is continuous integration (CI) and continuous deployment (CD) or continuous delivery (CD).

Another essential part of tooling is your workstation setup. I personally have three screens, plus an adjustable desk that lets me stand or sit down with the press of a button. I tend to have emails/research/Stack Overflow on one screen, code I’m editing on the 2nd and output/web browser or more code on the 3rd screen. I find this works well for me, but everyone is different, so you need to find what works best for you.

Building Features

Let’s have a look at some ways we can optimize our productivity when it comes to building new features or even starting new projects.

KISS

We’ve all heard of the KISS (keep it simple, stupid) principle, but developers love to make things complicated! In many cases, the simplest solution will probably be the best. It can be tempting to try and plan ahead to foresee potential feature requests or anything out of the current scope and this often leads to scope creep. Just stick to the plan and everything will (usually) work out just fine, and on time!

Leave Detail Until Later

When designing and building complex systems or features, it can be a little overwhelming trying to get your head over all the complexity, while trying to design an elegant solution. The trick is to not get bogged down in all the detail, at least not to start with. There are three main ways I tend to approach this:

Break the system down into smaller, isolated areas, such as a bounded context. This helps manage the code in a more modular way whilst also following some good architectural practices.
Have a multilayered architecture (at least three-tier) and only focus on one layer at a time. It usually helps to focus on the layer with the highest level of abstraction first, but don’t worry about how other layers are going to interact with each other to start with, you can solve this problem later.
Design by interface first when creating complex objects like services, even if you think you don’t need one. There are two main reasons I love interfaces. Firstly, they allow you to clearly define a contract without having to worry about the implementation detail. Secondly, they create another layer of abstraction, that, combined with dependency injection (DI) gives you the ability to pass in different implementations of the same interface without breaking or having to refactor any existing code.

Let’s explore the third approach by example. Suppose I want to create a service that calculates someones age, before I have to think about the the task of actually implementing it, I can define an interface to make clear what I intend to do. This allows me to think about what I need as input (parameters) and what we will return once the age has been calculated, without having to think about anything else.

public interface IAgeCalculator
{
    int CalculateAge(DateTime birthDate, DateTime currentDate);
}

The example above shows one way of solving this problem (well the contract part for now). I take the persons date of birth and then ask for the current date. We could remove the second parameter and just use DateTime.Today, but it gives us more flexibility to ask for the date, so we can calculate a persons age on a specific date. We then return an int which gives us the age in years. If we wanted more granularity, we could return an object with the persons age in years, months etc - perhaps a time span. But, as I mentioned above, it’s usually best to keep things as simple as possible to start with.

Of course, the implementation for this example would actually be relatively simple, but the point I’m trying to make is don’t start by asking how, start by asking what.

Don’t Prematurely Optimize

It can be tempting to spend too long optimizing on an algorithm before you’ve even deployed it to production, just because you think it will be slow and you can speed it up by making a few tweaks. Many argue that premature optimization is the root of all evil, and I generally agree with that.

I’d argue the focus should initially be on getting it working. Once it works and does exactly what was specified, then make it clean and finally optimize - but only if necessary.

Quality over Quantity

There is often pressure to get things to production as quickly as possible, but we have to be careful not to rush and take shortcuts. Doing this can quickly lead to technical debt, which in the long run costs a business much more money and headache.

It may feel like you are saving time by rushing a feature or fix to get it into the next deployment, but

Write Documentation

It may seem like a time consuming task in the short term, writing documentation (usually in the form of code comments), but in the long term it can save enormous amounts of time and hassle. I’m not saying you should document everything, some things are quite clear. But sometimes code just doesn’t make any sense unless we explain it (fully) and the best place to do that is often using code comments. I used to think of it as writing a note for future developers, but the reality is that I often need to read my own comments to remember what something was for.

Debugging

Debugging code can consume enormous amounts of our time - it’s not uncommon for devs to spend days on end trying to fix a single bug. Let’s have a look at some of the ways you can optimize the debugging process.

Diff

If this bug has been introduced since making some changes, start by comparing those changes with the previously working version (this is where good source control and tools like WinMerge can come in handy). By looking at just the changes between versions, we can usually narrow it down to just a few lines of code (or sometimes just a single line).

Attention to Detail

Often we can overlook something obvious because we are not paying attention to the small details. Common errors that can easily go unnoticed can include:

Mistyping a string
Referencing the wrong variable
Assigning the wrong value to a variable property
Using the wrong comparison operators (e.g. >= instead of <=)
Forgetting to assign a value to a class member

Tooling

As I discussed above, good tooling can make a big difference and this includes debugging. Visual Studio comes with some great debugging features like breakpoints, stepping (into or over), inspecting variables or other class members, autos, watches and also inspecting the call stack. By becoming familiar with these tools you can save a lot of time and pain trying to pinpoint the problem.

Refactor Complexity

Is the code you are trying to debug too complex? Is it trying to do too much? Does it adhere to the single responsibility principle (SRP)? If the code is too complex to understand or is not following SRP, then perhaps it needs refactoring into smaller, bite sized units that can be more clearly understood and debugged.

Process of Elimination

It often helps to isolate the problem through the process of elimination. I normally approach this in one of two ways:

Make a hypotheses as to approximately what line(s) of code might be causing the problem by scanning through the source code. Put a break point on the first and last lines you think could be causing the problem (e.g. null reference exception), then debug and step through, inspecting each value of each line as you go until the problem is (hopefully) found.
Comment out as much of the code (you are currently focussing on) as possible - sometimes this can be everything (e.g. a Razor page). Run the project to make sure it works; if it does not work then you need to comment out more code, but if it does work then you know the bug lies somewhere in the commented out code. Go through, uncommenting line by line and then re-running the project until it fails.

Pair Programming

I’ve previously discussed the pros and cons of working as a one person dev team, but I didn’t mention pair programming. Depending on the specific task you are working on, pair programming may or may not be more productive. The main advantage to pair programming is that you have two brains working on the same problem at the same time. I prefer this way of working when trying to debug errors rather than develop new features.

The other advantage of pair programming is that you are simultaneously sharing knowledge of the system with your co-worker. So if there is a problem in the future and you are not around, they will be able to work on it without needing to ask you any questions.

Ask For Help

Don’t forget to ask work colleagues for help when you are stuck, even if you think they can’t help because sometimes just the act of explaining the problem can help you solve it. I’ve solved many problems by explaining them to colleagues! Also, other people will see the problem in different ways and may have different approaches they can suggest.

If you work on your own or none of your colleagues can help with the problem, then the chances are that Stack Overflow will have an answer!

Conclusion

If you are a dev, you already know the importance of productivity. Becoming a more productive dev takes time and patience, so don’t expect overnight improvements.

Do you have any productivity tips you want to share? Let me know in the comments below.