8 Ways To Drastically Boost Your Developer Productivity
Introduction
These eight productivity tips will supercharge your productivity as a developer. You’ll save hours of time which you can then invest in other activities.
This is not a complete list of everything you should be doing, but these things alone will drastically improve your productivity if you are not already doing them.
How small amounts of time from repetitive tasks add up
Let’s say you are writing code in an old Java monolith and your flow for every change you make looks something like this:
- Save the file (1 second)
- Build Project in IDE (5 seconds)
- Deploy application war file into old J2EE container (30 seconds)
For every change, it takes 36 seconds before you can get feedback and try out your changes. This might not sound like a lot, but if you are doing this for every change this might happen 50 or more times per day. That’s 1800 seconds, or a half an hour that you could have spent doing other things.
Over a 5 day working week, this adds up to 2.5 hours of time lost. Over a typical working year, that’s 469800 seconds or 5.4 days of time lost that you could have spent doing other things. So by solving this problem, you’ll gain an extra week of productivity.
Your average developer has a lot of repetitive tasks they could automate. If automating one repetitive task saves you 36 seconds and the equivalent of a working week per year, automating 5 similarly time-consuming tasks will get you back 5 weeks per year.
How would I solve this specific problem? Use a newer framework with Hot Reload support. Just save your file and the change is automatically compiled and deployed without the need to restart the container. Newer Java frameworks such as Spring Boot support this feature. We’ll go into more detail about Hot Reload later in the article.
Automating repetitive tasks with scripts
If there is one thing that could boost your productivity the most, it’s automating repetitive tasks with scripts. I highly recommend writing Bash Scripts because it makes it easy to chain multiple commands together and these are the same commands you might frequently run on a day-to-day basis.
A lot of modern development is done on the command line with commands like npm install. There is IDE integration for some of these things, but I highly recommend learning and using the command line for one reason: It’s scriptable. Generally, it’s also faster to type a command than it is to point and click several times in your IDE to perform the same task.
Whenever you find yourself repeatedly doing the same thing or typing in the same set of commands, consider putting this into a script. Once this is done properly, the script will always run the commands in the correct order and will never make a mistake.
It might run in under a second compared with you taking say 30 seconds (which as we mentioned before, can add up over time).
Scripts also mean you don’t have to remember the complex syntax for common commands, although you can also use shell aliases for that.
A few random scripts I have set up locally:
- Back up my local database
- Dump the latest copy of the testing database and automatically import it to my local database. It calls the previous script to take a backup first, of course!
- Start and configure multiple interdependent microservices locally. It’s a pain to do this manually but easy with a script.
Use a real debugger instead of printing variables
I’ve found debugging especially useful when exploring unfamiliar codebases that I didn’t write. You can easily see the results of even the most complex logic written in weird ways. It’s much easier to reason out complex, convoluted logic when you can run it line by line and see how things change.
If you’ve ever used console.log() in JavaScript, var_dump() in PHP, System.out.println() in Java or a similar function in another language to print a value to the console so that you can see what’s going on inside your code, you might know how tedious it can get if you are trying to debug something complex.
You print one value at a time and you generally need to write a new log statement for each value you want to see. If the value you are looking at changes, you need to log it again. Its a bit like poking around with a blindfold or in the dark. Lets not forget the possibility that you might accidentally commit your debug statements!.
Human working memory is limited so once you’ve manually printed enough variables, the values will start to disappear from your mind and then you’ll have to print them again or write them down somewhere and update them as they change. Trying to keep everything in working memory takes valuable brain resources that you could redirect towards making your code work the way you want it to, following best practice or writing clean code.
Enter the debugger: Set a breakpoint in your code then run your app. When your app reaches the line you set a breakpoint on, you’ll be able to see all variables in scope in the debug tab.
There is no more need to juggle lots of values in your working memory. With just one action, you can now see everything instead of just one value at a time.
I started with just debugging my own application code but as time went by and I became more experienced, I found I could get great insights by debugging framework and library code (such as the code for express). I was able to find answers to questions that weren’t even listed in the documentation for various frameworks and libraries, which were often incomplete or poorly written.
The debugger always tells you what these frameworks and libraries are really doing, regardless of the accuracy or completeness of their documentation. I often find it faster to debug a framework or library before I read their documentation — complex concepts can take lots of words to explain but a debugger can get you the answers quickly.