How to Work Faster as a Software Developer
If you're like me, you want to get your work done as quickly as possible. Here are 8 different techniques I've been trying to help become a more efficient programmer
5 min read
23 Apr, 2021
During lockdown I've felt quite burnt out. To combat this I've been trying different techniques to become a more efficient programmer (aka "coding faster"). If I can achieve this I can work shorter hours as my manager has a very flexible / reasonable view on work - "as long as the work is done" - which I really appreciate.
How to code faster
So what techniques could I implement to become a more productive / efficient software developer? Or in other words: how to code faster? Well, I don't have all the answers but here are some strategies which I believe have helped a lot during the last 6 months.
Some of these techniques are only applicable for side projects but most can also be applied to full time jobs.
🖥️ 1. I invested in an ultra wide 49" monitor
They aren't cheap but it's been one of the best investments I've ever made as it has dramatically improved my productivity. A significant amount of time is saved by not having to move windows around. Even though it may seem small, these small wins add up. I believe it's a key factor in being able to work faster. For example, I now have all of my required 3 windows open at once on the same screen!
- The app
- Visual studio code
- Stack overflow
It's been one of the best purchases I've ever made as it allows me to code much more efficiently. It's definitely an expensive investment (~$1,250) but I think it has already paid for itself i.e. every second not moving windows around = $$.
Here is the monitor I purchased:
⚖️ 2. I've put more emphasis on applying the 80/20 rule
Pareto's principle suggests that 20% of activities account for 80% of the results, e.g.:
- 20% of drivers cause 80% of all traffic accidents
- 20% of a company's products represent 80% of sales
- 20% of employees are responsible for 80% of sales
And similarly, 20% of code produces 80% of the business value. I've therefore been more ruthless when developing features for 4dayweek.io. For example:
- Do I really need 2 password fields on a sign up form?
- Do I really need to create a "forgot my password" automated form?
- Do I really need to optimise for tablet when it accounts for 5% of web traffic?
- Do I really need to use Kubernetes?
I've also been trying to adjust aspects of my non-coding work, eg.:
- Trying to avoid irrelevant meetings (it's ok to say "I'll email you instead")
- Turning my camera off when I'm not a key person on a call
- Putting less energy crafting the "perfect email response"
🍅 3. Being aware of Parkinson's Law + Pomodoro technique
Parkinson's law states that work usually "expands to fill the time available for its completion." By instead breaking large pieces of work up into smaller tasks and working solely on them for a short period of time (e.g. 30 minutes) the effect of Parkinson's law can be mitigated. This is also know as the Pomodoro technique.
The main reason for using this technique is because the human mind can only concentrate for around 20 - 30 minutes at a time. Coding / working for longer periods of time is inefficient.
In fact, I've been writing this article for about 30 minutes now and my concentration is starting to fade, so I'll continue after a short break 😇...
Ok, I'm back - the article continues 👇
💻 4. Using the same programming stack again and again
Efficiency is bred from repetition; the more we do something in a particular way, the faster and more efficient become. As a tech enthusiast / nerd I often want to build using the latest trendy programming language but instead I've tried to stick to 1 tech stack and use it for all of my projects.
For example, I've been using Golang + ReactJS for the last 6 years and recently I've been tempted to try Rust & NextJS but realistically this is a waste of time. I can code Golang + ReactJS in my sleep and it is more than good enough to achieve my end goal, so why should I change?
p.s. I'm not saying "don't learn new technologies". All I'm saying is:
I think it's better to "master the minimum number of technologies which achieve 90% of the desired outcome".
⚡ 5. I've been utilising no code / low code tools
This wasn't an option when I was learning to code but now there are a wealth of no/low code tools which I can use to achieve many common tasks.
For example, a few years ago I built a small Go program to:
- Read data from a database
- Periodically send out a tweet based on the data
The program took around 3 days to complete from start to finish. Last week I used Zapier to do almost the same thing, except this time it took me < 1 hour. See below for the configuration:
📝 6. I've stopped writing unit tests (for side projects!)
A controversial one. I'm definitely not saying stop writing unit tests in your full time job, but I do think writing unit tests when you are creating a side project is mostly a waste of time. When I've been building this website for example I've instead focused my energy on "speed to market" rather than "bug free" code.
I worked at a startup years ago and they lived by this mantra:
The shortest path to "good enough".
I really think it's the best strategy in the "early days" - some may disagree.
🤝 7. Where possible I've outsourced work
This doesn't apply to a full time position but if you are working on a side project (even if it earns $0!) I think outsourcing some sandboxed and small projects is a good idea.
You can think of it as putting a dollar value on your time. It can be "cheaper" to outsource the work if you are freeing your time up to work on higher value tasks. Even if your side project makes $0, the potential of earnings should be factored into your "hourly $ rate" (i.e. an average amount somewhere between success and failure).
For example, I recently needed to write a small, one off, piece of code to scrape data from a website. I could either:
- Build it myself: If I say my time is worth $50 per hour (to make the numbers easy) and it takes 2 hours, it'll cost me "$100".
- Outsource this work: If I outsource this work on a platform such as UpWork I could have it implemented for $20. This is similar to freeing up "$80 of my time", which equates to 96 minutes to work on something else (i.e. $80 work at $50 per hour).
From my experience though, not all work is easily "outsourcable" and I would only recommend doing this for small, sandboxed, non-critical projects.
🤖 8. More automation
If I need to do a task more than once a week, I've been asking myself: "can I automate this?". For example, when I've been adding jobs to this website, I wanted to email the company to let them know, which quickly became exhausting. So instead, I created a Zapier automation to automatically email the relevant person each time a new row was added to my Postgresql database - a huge time saving.
I am definitely not a ruthlessly efficient coder but since making these changes I really feel like I'm shipping faster than I've ever done and as a result, I've been able to rest more. So hopefully some of these techniques can help you become more productive as a software engineer!
My next job is to stop procrastinating on HackerNews... 😅
For more articles like this follow me on Twitter 👍