Most people work about 40 hours a week, some more, others less. Given that you have 168 hours a week, maximizing your achievements does not scale with maximizing the amount of time spent on work. Instead of focusing on quantity, a significantly better way is to increase the quality of your work. I will give you ten tips that may help you get more things done in less time while continuously increasing your quality standards.
1. Multi-tab syndrome
I have tested multiple software developers on this topic. The absolutely worst example I have seen spanned about 50 browser tabs across 4-5 different browser instances. Some people find an interesting article and keep it open for weeks.
Your favorite browser is not a good place for managing your reading backlog. Notice that it is hardly possible to rank your tabs based on urgency, importance or even topic. I personally use a Trello study-board for all the videos, podcasts and articles I would like to digest.
Opening 10 GitHub tabs does not help you either. Bookmarking your GitHub repositories is sufficient. You can also have a daily todo list and it is also fine to add GitHub links to your action items.
Regarding development environments, Sublime Text can locate any files using
Command/Control + P. If you open too many files at once, right click on the leftmost file, then select the "Close Tabs to the Right" item from the context menu. If you develop a package with 4-5 files, keep only those files open in your editor, nothing else.
Simplicity will eventually pay off.
2. Daily and Weekly planning
I mentioned that I use Trello for organizing my reading backlog. Trello is quite useful for managing daily activities too. All you need to do is create a board with all days of the week and rotate the days. If you want to measure how much you got done, estimate the complexity of your tasks and add a "Done" column to your board. You can then count your velocity daily or weekly.
There are multiple ways to assign complexity to your tasks. The easiest one is to start assigning some meaningful numbers, then learn from the actual results. You will get better at estimations over time.
If a task is too complex, break it down. It is not advised to assess tasks that take more than just a couple of hours.
Only measure productive work and try to avoid non-productive activities.
I tend to plan at least a week ahead. I know my top level goals and I break them down to smaller tasks. Whenever full planning is not possible, I leave enough empty slots for unknown tasks and update them later.
I address my tasks from top to down. When a new task appears, I insert it based on my own perception of my priorities.
Notice that there is very little thinking involved when it comes to selecting my next task. I just look at the board and select the first card on the list belonging to today.
3. Strategic planning: learning and development
There is more to life than just planning one week ahead. Let it be learning, growing a business or reaching the next career step, control is better than waiting for what life gives you.
When it comes to learning and development, abundance of information is the number one obstacle that I tend to cope with. There is just too much information out there to digest everything. Therefore, specialization and a learning path is essential. If you are a CTO, you may already know that you have a lot to learn, most likely as long as you deal with technology. The same holds for all software developers, regardless of experience.
I tend to decide yearly on what I am going to focus on and revise these learning goals at least 4 times per year. Preparation is vital in being productive.
Scheduling your learning also allows you to stay objective. Instead of jumping from one trendy thing to another each week, a consistent approach is worth more in the long run.
4. Start with a blast
About ten years ago, I listened to quite a lot of self-help advice while jogging. I still remember the calm and monotonous voice of Brian Tracy giving me the advice "Eat that frog!". According to his advice, you have to start your day by eating your own frog, which is your "biggest, hardest, and most important task".
I figured out that Brian's advice never worked for me during my professional career. First of all, I don't hate my work, therefore I don't feel like eating frogs at all. Second, suppose that we called the "biggest, hardest, and most important task" as our frog for the day. Assuming that we can identify such a task, it would be quite selfish to block multiple teams each morning just because we have to eat our frog. Would you really tell your team "sorry, I have to eat my frog first"? If I can unblock tasks on the critical path by giving them half an hour of focus, it is a no-brainer decision. If you help other teams, they tend to return the favor by eventually helping you out.
I am also sceptical about eating frogs because I am used to working with people who have an internal drive to accomplish things. Good developers don't think in terms of frogs. They just solve any problems they get. The order of solving these problems depend on their daily and weekly priorities.
A lot of people start work slowly. They sit down, drink a coffee, check their mails and slowly try to switch to work state. I tend to do the exact opposite. It often happened that I deployed an update right after logging in. Other times, I caught someone on the way to my seat to discuss something important. Usually, when I sit down, it takes me 20 seconds to identify that there is nothing urgent, then I open my Trello board and start my first task for the day.
5. Focus vs interruptions
What does focus mean to you? Do you still give priority to whoever appears in front of your desk? Do you read your incoming emails? What other distractions draw your attention away from solving a problem?
I learned from professional poker players about real focus. Suppose a poker player earns 50 dollars an hour. One mistake can cost him 500 dollars. Lack of focus may punish these people by ruining ten hours of their work. Software developers are not punished this way, therefore not every developer reaches the state of real focus.
While developing software does not require you to focus on your screen, it does require your mind to be fully on the problem you are solving. Context switching takes time. If you look at each and every skype message or email you receive while working, you will be significantly less productive than people who just focus.
My advice to you is to create filters that will only notify you in case of top priority and emergency situations. Don't worry about your surroundings, if they see how much you stand out from the crowd when it comes to being productive, they will cooperate with you. You can even mute your Skype such that it only notifies you if a given word is mentioned. Email clients can handle even more complex filters.
Don't be afraid to reject people coming to your desk. I noticed that some people work like a stack: even while performing a critical task, the person visiting them gets their full attention, regardless of the importance of their request. This request can only be interrupted by another visitor making it more likely that the most important tasks will not be dealt with until all the noise is handled.
When I had to perform a critical task, I just told my visitors that I was busy and that I would get back to them within an hour. In exchange for their cooperation, I highly recommend always following things up within the promised time frame. If it is not possible, a message saying that you have more urgent things to do is also fine, accompanied by the expected time when you would eventually follow things up. People trust you more if you are reliable and they also let you manage your own time.
Later, I also made it clear when I was not available because of focusing on a development task. You can even use a signal indicating that you are only willing to handle urgent or important interruptions. Less important requests ended up in my inbox. Urgent and important requests were still handled. Other teams were not blocked just because of my focus mode.
It takes some time until people adjust to these rules, but productivity-wise the transition is worth all the efforts.
6. Batching repetitive tasks
If you refuse to handle requests with low importance and urgency, you will receive more emails and other notifications. If you don't want people to feel like they write to
/dev/null, you have to follow these requests up with a reasonable response time. This response time depends on the situation you are in.
Responding to all your messages immediately is tempting, but it is also a huge time waster.
Initially, I was very curious about the contents of a message. It is not easy to let this habit go as the act of opening an email is pleasurable in the short run and you may not even realize the pain of getting less things done at the end of the day.
The most efficient way to handle communication is to batch it. While continuous context switching is a waste of time, spending 15-30 minutes twice a day to handle all communication may even save you an hour every day.
The same principle holds for other tasks such as weekly planning, overview of milestones or unblocking blocked issues. The only thing that should not be batched is your break schedule. You deserve to have quality time away from your computer, preferably at least 5 minutes every hour.
7. Avoid and limit meetings
When I first worked with a company having a culture based on meetings, I soon found myself calculating the amount of money the meeting costs the company assuming an average hourly rate. Then I asked myself if the conclusions drawn from the meeting itself was really worth the amount of money or not. You can guess that if I had time to think about such things during a meeting, the answer was often implicitly not.
When I was new to meetings, I observed the kinds of mistakes people made:
- getting bored and still not leaving
- changing topics to out of scope items
- lack of properly specified agenda
- lack of preparation
- lack of documenting the topics and decisions of the meeting
- substituting an inefficient communication channel with a meeting instead of improving the channel itself
- talking while you should be listening, interrupting others
Most items are obvious. I would like to clarify only the last one. I was deeply interested in why people tend to interrupt each other. After a while, I got the answer. While a minority of people did tend to ignore and disrespect others, the number one reason for interrupting others was lack of confidence. People are not confident that they would remember their own idea. Motivated by the fear of losing an idea, they just shoot it, interrupting whatever is going on.
I also observed how I handled similar situations. Most of the time, I kept my idea in my head, sometimes for minutes. There were occasions when my thought became irrelevant. Other times, someone else said the same thing and my thought became redundant. If these two things bother you, it is an ego problem. If you feel the fear of losing a valuable thought, I can help you with a piece of advice: instead of interrupting others, I suggest writing your idea down. A keyword is often enough for you to follow the idea up. After a while, you will figure out that you don't even need to look at your records.
8. User testing for developers
All developers have bad habits. Let this be about handling your development environment, switching tabs or settling for a buggy development build of an application, there are things that hold you back on a regular basis. Some people rely on their mouse too much. Others don't display the Git branch and status they are working on. Others fail to address a knowledge gap that makes them look up the same thing over and over again.
You may not be the right person to point your own problems out. If you can ask someone else in your environment to have a look at your coding habits, do it! You may receive cutting edge advice on how to be more efficient. Alternatively, you can spend some time with someone else, trying to decode what your peer does better than you. Technology, such as text editor plugins are easy to copy, while habits are a bit harder to pick up. Although some people look real geniuses while coding, they may have just spent a couple of days more than you on studying and tuning their development environment.
9. Follow things up
Issues tend to get blocked while the assignee asks a question and fails to receive an answer. A team tends to unblock issues faster if each and every team member is trained to follow things up. If you block an issue, schedule when you would follow it up in case no answer came, respecting the usual response time of other people. The addressed person may have just handled two or three interrupts and may have just forgotten about your request.
If you are responsible for moving a milestone forward, following up all blocked issues from time to time makes sense. Even if you are a trainee developer with zero experience, taking the initiative in following things up pays off.
10. Take enough breaks
Software development is a mental activity requiring a clear and efficient thought process without distractions. Working for 6 hours without interruptions results leads to lowering your quality standards. The only way to keep up with quality work is to take a break even before you feel you would become tired. Spending 5 minutes an hour on recreation allows you to work more efficiently.
Sometimes you will become tired without noticing the transition. If you feel that your concentration is not good enough anymore, take a walk or do anything that would cheer you up. Even a silly pattern interruption sequence helps. Some people start dancing after solving a difficult issue. While such a routine is amusing, I have observed that these people tend to keep up the same level of concentration all day. When in doubt about what to do during your break, moving is important, as well as drinking a glass of water.
Taking breaks also includes holidays. Recreation breaks break your usual pattern and allow you to let some of your disturbing patterns go after your return.
If you are sick, go on sick leave! You won't be a hero if you work while being sick. You will rather be the villain capable of infecting others in exchange for some low productivity work.
Fortunately, fear as a motivating factor is dying out. Companies have to compete for talent and real talent will leave bad companies. In some countries, it is still a hard decision to go on sick leave. In my opinion, productive people need proper recreation to stay productive.
Self-employed people can also have sick leave by teaming up and working slightly ahead of schedule. However, there are cases when the terms of your contract do not allow you to go on sick leave. In these unfortunate situations, symptoms have to be treated, the points of the contract have to be fulfilled, and proper recreation has to be scheduled. If this experience repeats itself often, you are doing something wrong on a strategy level and I seriously suggest revising your working conditions.
These ten points have given you enough ideas to organize your daily routine. Although change will not come overnight, if you consistently focus on improving your efficiency, you will get better. At first, you may even expect to deal with some overhead. If you are consistent, some of these changes will eventually become habits boosting your productivity.