Are you a freelancer who wants to get more done in less time? Or do you want to be more productive within your software development team? Speeding up your software development can only be a good thing.
I will be sharing five things that I have found have helped keep me productive as a developer.
When I say speeding up your software development, I don’t mean learning a faster way to code or replacing how deployments work in your company. I’m talking about things we can all make sure are happening. All the non-code “stuff” doesn’t hinder the act of writing code.
These suggestions should all be within your power to influence.
Reasons To Develop Efficiently
But Toby, why would I want to work faster? I will get paid the same regardless.
That is certainly a point, not a great one, in my opinion, but a point!
There are extrinsic reasons for getting more done in the day. I run my own business, so the time I spend on non-billable work is costing me money.
If you work on a team, your managers will notice if you are more productive than your peers, which can lead to promotions or pay increases.
That is a whole other topic. What drives me are the intrinsic benefits I get when I feel like I’m moving fast.
It is worth pointing out that when I say “feel like I’m moving fast” I do mean “feel like”. There are numbers we can attribute to things like how long it takes your laptop to boot up in the morning, but it is all relative. Some things take 2 minutes that feel like forever; the same 2 minutes on another task would feel lightning quick.
I’ve found that when I’m able to develop quickly a few great things happen:
I Am Less Distracted
With tighter feedback loops I’m way less likely to take a “quick” Twitter break. Removing micro-breaks leads to more blocks of meaningful, productive work.
I am much more satisfied with my work when I’ve had these long blocks of time.
I Do More
Amount accomplished is hard to quantify, but when I take the time to make sure my development is happening fast, then I get more done in the day.
We’ve all had days where it feels like we’ve been fighting with the computer. Be that having to restart the router or doing some maintenance before you can tackle what you want to get done. It stands to reason that when you’re not doing that, you will do more.
I Enjoy Software Development
When I can move quickly, I enjoy software development. I’m a simple man, with simple pleasures, I like to type something, hit save, and see something change on the screen. It is MAGIC, or at least has felt like magic for close to 20 years now.
As far as I’m concerned the more of that endorphin hit I can get the better.
Five Ways To Develop Software Faster
As I mentioned at the start, these tips aren’t “get good”. If you learn all the methods in your chosen libraries by heart, you will get more done than those of us who don’t do that. I’m not very good at that sort of thing, so I can’t recommend it!
These tips are agnostic of any language or framework; in fact, some of them don’t even need you to be at a computer!
1. Have Your Machine Running Well
Using a slow machine is like trying to use a pen that sometimes decides to stop working even though it still has ink.
If you take your job seriously, you want useful tools for it. Having good tools doesn’t mean you spend seven billion on a new Macbook, but it does mean you should consider:
- Shutting down or removing applications you don’t use
- Clearing out old/unused files
- Performing basic performance tasks
- Keeping your battery healthy
- Upgrading parts of your setup that no longer function as you like
I have a monthly task to review the applications on my machine and decide if I still need them. Some things I have for specific projects or because I was testing something and I can remove them. So many applications add little tasks that hit the network or consume RAM over time. It is surprising how sluggish your computer can get with things you don’t even use.
For general performance and disk maintenance, I use CleanMyMac.
Five years ago, I wrote an article about breathing life into an old Mac. The advice still holds up.
Money permitting, you should consider if there are parts of your setup that are holding you back. Looking after what you have will improve things for you, though, without needing to spend large amounts of money.
2. Limit Distractions
Your environment has such a significant impact on how you work, but so many of us won’t invest in making it better. If you work from a particularly noisy room, is there a better room that if only you took a few hours to sort you could use? If you can hear background chatter, would a pair of noise-cancelling headphones help?
- Limit external stimulus. Noises, extra screens, etc
- Limit notifications. I promise you don’t need a push notification for half the stuff you have push notifications for
Removing noise and clutter from your environment is going to help an incredible amount. I’m writing this from my living room, but my noise-cancelling headphones mean I could be anywhere.
A lot of people have the mindset that they need to reply, or at least view an email as soon as it comes in. Let me challenge you to at the very least, let an email sit for an hour before you look at it. If nothing terrible happens then push for longer.
3. Look For Fast Feedback Loops
Fast feedback loops refer to the cycle between an action and its consequence. The faster I can see the outcome of my change, the better.
What feedback loops impact your day to day development will depend on the type of work you are doing. Here are some areas that I focus on:
- Getting feedback from tests
- Having local changes reflected in my browser
- Finding out that my code has passed linting
- Viewing my recent changes in a production-like environment
Feedback loops are generally things that you will often be doing. So time spent improving them is usually time well spent. For example, if it takes 10 seconds to load your testing framework (not uncommon), then every time you run a single test you’ve to wait 10 seconds. Imagine how much more you would test if that were half the time?
The easiest way I’ve found to improve feedback loops is to imagine what perfect would look like, and work out what is different between what you have now.
In the case of fast tests, you can search for “faster $TESTING_FRAMEWORK” to get some ideas.
Don’t be afraid to defer slow feedback loops. If linting your code takes 20 seconds, why not do it as a pre-commit hook. If your machine isn’t the fastest, and you need to run the entire test suite before submitting anything, consider setting up a private environment you could push your code to, freeing up your machine, and you, to focus on other tasks.
4. Block Out Time For Non-Dev Tasks
You’ll notice that when talking about limiting distractions, I didn’t mention anything about meetings or other non-development tasks.
Some developers think of meetings as distractions. There is a whole other blog post in debunking this nonsense. The short version of my thoughts on this is that meetings are part of your job, get over it and get good at them.
Given that to be a useful developer, there are plenty of non-development tasks you need to do, it makes sense to optimise your development time around them.
Ways I’ve tried to do this in the past are:
- Checking emails at set times
- Blocking out time on shared calendars when I’m not going to be available
- Scheduling calls or meetings for set times in the day or week
- Setting aside an hour in the week to catch up on tech blogs I subscribe to
When I said “tried to do” I do mean try because sometimes you don’t have any power over what company policy is or when things happen.
My advice for when it feels like there is nothing you can do to block out time in advance is at the very least to let your project manager or team know.
It is impractical to plan to spend a certain amount of time on technical work if that work gets broken up by related but unplanned work. Highlighting this as an issue is the first step to positive change.
5. Know When To Stop and Move On
Software development is hard, and often a problem will stump you. Over the years I’ve got better at knowing when spending more time right now on a problem is not the right call. There is only so much good you can do banging your head off the same problem.
There are plenty of techniques you could use to help, such as rubber ducking, pairing, asking the internet. I’ve found that often switching tasks is enough to offload the problem to a much smarter part of your brain to continue to work on it.
Knowing when to stop is tough to get better at. I try and notice when I’m going in mental circles, either by searching for the same term or redoing a previous attempt. When this happens, I know that more digging isn’t going to be productive.
I often write a couple of notes in the ticket and pick up the next task, or jump into a non-dev task for a bit. You will not lose as much context as you fear you might.
Give These a Try
This advice comes from years of trying to be good at my job; I hope they benefit you.