As a developer, your productivity is not gauged by how much code you churn out, but by how much value you deliver. Gone are the days where lines of code are a worthwhile performance metric. If you want to master your craft and hone your productivity, you will need to embrace the age-old adage — “Work smarter, not harder”.
These are 5 methods and principles you can employ today to start seeing immediate returns in your productivity.
Be deliberate in what you want to achieve
There is no way to know how productive you are if you have nothing to measure against. One of the biggest boosts to productivity you can get without having to do much at all is to set deliberate goals for what you want to do today and this week.
At the start of each week, take a moment to think about 3 things you want to have ticked off by the end of Friday. These should be high-level items, and your daily objectives will help you meet these goals.
At the start of each day, consider what you have accomplished so far this week, and what you would need to do today to stay on track. Write down 3 objectives somewhere (I prefer a physical medium, but apps like Sunsama work great for this too). As you go through the day, when you finish a goal, tick off the item.
It can take a bit of calibration to get a good feel for how big these tasks should be. I found myself writing down far too much at first. I was lucky if I was able to finish the first item on the list. After about a week of tweaking, I’ve reached a scope that works well for me. This technique is invaluable when it comes to projecting how much work I will get done in a week, and making it happen.
Don’t write perfect code
Not straight away, at least. Many developers have fallen prey to the temptation to write perfect code in a single go. It rarely happens. Think of writing code the same way you would draw a picture. Start with a rough outline of what you want, and iteratively add details until you end up with something great.
Leonardo da Vinci didn’t paint the Mona Lisa by perfecting her head before moving on to her neck, he worked through countless iterative refinements over the whole image.
A good principle to help remember this is the “3 E’s of code”
- Effective — Write the code solve the problem
- Efficient — Improve the code to make it more optimised
- Elegant — Refine the code to make it beautiful (don’t skip this step. Efficient code isn’t worth much if no one can read it)
In that order. Don’t start the next step until the previous one is complete.
This methodology ties in well with the next point.
Use TDD wherever you can
Test-Driven Development is great. It is basically a free productivity boost. Writing your tests as you go and refactoring code once it passes fits in perfect lock-step with the 3 E’s mentioned above. Don’t write your tests after you are finished with the code. If you do this, one of two things are likely to happen:
- You will be told to skip the tests and move on
- If you do write the tests, you will base them on the output of the code, and if you have bugs, so will the tests
Writing tests as specifications — distilled business requirements — ensures that your code is working as you write it and that the testing cannot be skipped. This results in higher quality work, fewer bugs, and less cause to come back and rework things later. If that isn’t a productivity gain, I don’t know what is.
Work in batches
A fact of life for most jobs is that you will often receive small tasks which people ask you to do. Being a developer is no different, and depending on your role you might get a couple of these a week, or dozens of them per day!
The key thing here is that many of these tasks are not urgent at all, and can be delayed without any adverse impact. If you delay enough similar tasks, you will be able to group them all together and action them all at once. This approach of doing the work in batches has various benefits. On the one hand, you are reducing the amount of context-switching you do, so you will naturally get productivity gains there. You will also be able to consolidate the setup and teardown overhead associated with small tasks. In most cases, the setup work required to do one task is the same as the work required to do 10 similar tasks. consolidating this overhead can save you a lot of time which could be better spent elsewhere.
Be Relentless
Perhaps the most important thing when it comes to getting stuff done. Sometimes you have to just power through. Using the other tactics described above will put you in a position to identify the work which needs to be done, and give you tools to do it efficiently, but at the end of the day, you just have to do it. I set myself a hard requirement of AT LEAST checking off the first item on my 3 item list every day. On good days I can get two or three high-level items checked off, but if you check off one meaningful objective each day — as long as you have set yourself valuable targets — you will be smashing out work and ticking boxes like nobody’s business.
