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:

• Emails do not require immediate responses. If you get an email, fight the urge or reading it immediately. Ignore it. Because you know regardless of what email it is, you can respond to it later. If this is urgent, they will call you, or even come to your desk. People would like a quick response to their emails, but they will not mind a delay (an hour, two hours, or even 4 hours). So you don’t need to take each email as an urgent email. You can close the email client completely, or even uninstall it and use the web version if you want.
• Emails can be done in batches, and at your least productive time at at people’s least productive time. When you are productive the least, do your emails. Do not do your emails in the morning, because you will get a response quickly from your co-workers, and your work is lost. Rather, I suggest that you respond before you leave home. You will not get response from people who are already gone, and you will not be distractive by their responses until the next day. So why waste your time?
• Not all emails need to be read. Unsubscribe to every mailing lists that prove unhelpful. Mark senders as spam if they do not unsubscribe you. If a mailing list tends to be unhelpful, but they rarely put helpful information, then unsubscribe to it and ask one of your coworkers to let you know if there is something important that comes up on that mailing list. Sometimes, even emails from your coworkers are not helpful. Some went to suggest that any email in which you are listed as CC is not important and therefore you should not read it. It is you who can decided what is important and what is not.
• Email is not the only communication medium. Sometimes, you don’t need to respond to the email by an email. If you can call, or walk to the sender desk, then you should, and save yourself some time. If the email is related to miscommunication between many people, then schedule a 5 or 10 minute meeting to clarify. Don’t think that emails is the only way to resolve questions.

Automate

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.