This post was originally posted on my blog
One of the new developer tips I gave in my previous post, Tips for New Software Developers, was
Tip 3: Set boundaries on work hours from the very beginning...but work hard and efficiently during those work hours.
I talked about how I've worked hard to become more and more efficient but didn't provide any additional details. In this post, I'll cover the key productivity tips that work well for me. But first, it's important to establish the core principle that underlies all of these productivity tips:
The key to high efficiency is to **consistently* maximize the amount of consecutive hoursyou spend working on the things that matter most*.
This is by far the most important takeaway from this post. All of the tips I'll give are just ways I've found to achieve this. At first this may sound simple, however doing all 3 of the bolded parts takes a lot of discipline and practice.
I've already written about the way I manage myTODO list so I won't spend too much time on it. However, looking at the core principle of productivity above, you can see that it ensures you're thinking about priority on a daily basis, which covers the "consistently" and "the things that matter most" parts of the principle.
One more note on this before I move on: In order to be highly productive, you have to exercise ruthless prioritization. I like that phrase, because it gets across how aggressively you need to prioritize. One analogy I often use is to picture a ladder. You can expend a lot of energy climbing the ladder as quickly as you can. But if it's leaning against the wrong building, all that effort is waste. Your time is a resource. Spend it wisely.
The TODO list helps me know what I need to work on. The final piece of the core principle is to spend "consecutive hours" on these important tasks. In the office, interruptions are the primary obstacle to achieving this. Here are the ways I minimize interruptions:
Ah meetings. No developer I know likes them, but they can be a necessary evil of the job. Here are my tips for meetings:
Early on while I was in college, I learned shell-scripting, and it has been an invaluable skill throughout my career. Being good at scripting gives you the power to automate mundane tasks away very quickly. Because I've used shell-scripting for so long, I always find it surprising when I see developers manually performing repetitive tasks that could easily be scripted. This happens much more frequently than I'd like, especially when working on "non-coding tasks," like design documents, updating bug trackers, etc.
I've found myself saying to people, "Don't forget you're a developer! Be a developer!" What I mean by that is developers should not restrict their coding skills just to production code. Computers enhance productivity tremendously, and being a developer means you have the ability to make computers solve customized problems for you. Obviously, there's a bit of quick cost/benefit judgement that should be employed. Don't spend an hour writing a script when you only have to do the task once and it takes 5 minutes to do manually. However be aware that there's also a long-term benefit in building your scripting skills to the point where you can whip out a script in 10-15 minutes that saves you hours.
I have a pretty long commute to and from work, and it turns out to be the perfect time to listen to tech talks, audiobooks, and podcasts. This turns a normally tedious part of my day into an opportunity to learn about various tech topics.
Last and certainly not least is to exercise and get enough sleep. It can be extremely tempting to work late into the night. You feel like you'll squeeze a few more hours out of the day and get ahead. But what I've learned and relearned (and relearned) in my career is that it always ends up evening out or setting you back. You may get a few hours of work in in the middle of the night, but then you can hardly function for the entire next day. Also, when your brain is exhausted, you take longer to do tasks that would normally be pretty easy. This can have psychological consequences since it can trigger Imposter Syndrome anxiety. Finally, when you're exhausted, you tend to make mistakes that can create more work for yourself. It's just not worth it.
This tends to be a very difficult one for developers to follow (me included!). I think it's because of programmer stereotypes (the image of the lone coder working through the night), but I can't stress enough how important this one is!
Hope this helps! Again, these are just the tips that have worked well for me, but anything that helps you achieve the core principle I described at the beginning of this post works. Give them a try and let me know what you think. Do you have additional productivity tips? Let me know in the comments.