On Productivity

Being productive is difficult on its own, and being productive as a software engineer is even more difficult. Software engineers use their computers or phones all the time for work, and these two devices are the cause for low productivity in many cases. Moreover, the field of software engineering and software development is moving so rapidly that catching up with the new technology is proved to be futile. Hence, being productive is a challenge. I have collected some tips over the year that I hope you would find helpful.

Avoid emails

Here is usually what happens during a typical day: you come to work, and the first thing you do is read your email. You find few emails that are important (maybe related to a bug in a software, or a feature, or even a code review), you naturally act (responding, viewing a link in the email, etc.) It takes you sometime to respond and act. You are finally done with all of your emails, and are ready to start working. Lo and behold: someone responds to your email, and their email takes your attention. You read it, and respond to it. You are finally are ready to work. But not yet, because another person emails you back for more clarification. You respond to them again. The first person responds as well to thank you. And you are finally ready to work. By that time you already spent 30 minutes dealing with your inbox.

This could be your story, and it used to be my story: I spent too much time reading emails. Here are some tips that I hope would help you manage your time with emails:


Automate all the things.

It will surprise you, but you might find many tasks during your day that you can automate. If it is how you filter your emails, then consider a rule in your email client to do this job. If it is checking ERROR logs on a server, then write a script that automatically logins to a server, run a grep to find errors (or better yet upload the logs to a central place). The possibilities are many.

But finding these opportunities requires patience and discipline. You need to think about every task you do, and ask yourself: have I done this before? If yes, then it is an opportunity to improve. At a company I worked for, every time we want to approve an updated version of a software, we had to submit a request and send an excel sheet with the package/library info. This can take a while. So after realizing how time consuming this task is, I decided to automate this process, to read all the packages approved, check to see if any of them has been updated, and then create an excel sheet based on the result. So this task that usually took few hours, took a minute after the automation. And it was automated to send an email with the list of packages to approve every week, so that I do not have to babysit this process anymore.

The bottom line is: there are many opportunities for automation. Finding them is not easy.

Know your editor

Your editor is a tool that you use often. As a programmer, you spend much of your time writing and reading code (hopefully) and it would be of a great help if you know how to use your editor, very well. Learn how to navigate quickly, how to more from place to another and back. Learn the tricks of editing quickly. Learn how to build, debug, run, and test on the fly. These might save you few seconds, but the accumulated value can be long minutes. Not only that, but learning your editor might expose you to features you did not know about the editor you are using.

Learn about different editors, but commit to one if possible (sometimes this is easier said than done). I personally used many editors, but I use vim (or neovim) when I can. The good (or bad) thing about vim is that the shortcuts stick forever: every time I use a new editor, I have to find a plugin that emulates vim commands and shortcuts. If you use Visual Studio, then stick with it and learn its features and shortcuts. If you use VSCode, then check out the plugins it has and how to use them effectively. If you are an emacs user, then spend time reading about how emacs works and how to use it. I read two books on vim, and even though I don’t remember most of them, I got the features I need to work with vim, and I will probably remember that there is a feature I need when I run into problems.

I hope these are helpful. I found these to be important in my career so far. Please let me know if you have other tips that could increase one’s productivity.