Photo by Jarek Ceborski on Unsplash
When I was a junior engineer, one of the best advice I got from a seasoned principal engineer was to batch things, stack rank them in preferred order (by time, size, impact, or priority), and execute. And, be careful when batching them. Batching them by function increases productivity as it minimizes context switching cost.
At the time, I didn't pay much attention to that advice because I "thought" I could multitask well. So for me, the cost of the context switch was already minimal. I don't need to divide the task by function. I could drive a car and listen to the radio. I could clean the utensils and watch TV. And I could eat food and have a conversation.
To many of you, it's probably evident that functions already separate the above tasks. Even though I was multitasking, the two tasks were separated by firm functional boundaries, i.e., physical and mental, and the cost of context switching is already significantly less.
But when it comes to work, especially engineering work, the cost of multitasking skyrockets. Because (for software engineers) all tasks fall under cognitive function. And as a result, it requires a lot of context switches.
Trying to code and listening to music falls under cognitive functions. Naming a variable while listening to your favorite songs' lyrics may result in cognitive overload. You are more likely to name a variable after the singers/songs name than what the variable is supposed to reflect (true story).
This is true for physical function as well. Imagine trying to clean utensils and cook food at the same time. They both fall under physical function, and the switching between them is a huge waste of time. Cleaning hands, wiping them, cleaning water droplets, make sure soapy water doesn't splash near cooked food, etc., takes time whenever you switch from washing dishes to cooking food. 
Over the years, I have learned the true cost of context switching, and it's huge. And, I see it constantly underestimated all the time, even by senior leadership.
One of the effective ways to counter context switching costs is by following the sage advice of batching. More tactically, batching tasks by function. I personally use it extensively and have taken it several steps further. 
I take the tasks within a function and sub-divided them further into smaller functions. For example,
Writing code and reviewing code are now two separate functions within the same cognitive function. Even writing/reviewing code for two separate code bases are two separate to all emails is an email function. Even that is further broken down into triaging email function and responding function. (best post of how to use Gmail more efficiently by Andreas Klinger)


Batching has greatly increased my productivity, and I can't even compute how much stress it reduces on daily basis. But why does batching works?
Why batching-by-function give a productivity boost?
If we look into the first principles behind batching, we can identify that batching reduces the scope of the task and makes it specific. Every task requires identification, understanding, and then execution. Batching separates all tasks into specific buckets. Saving the context switching cost of jumping from one bucket to another.
The best analogy is sorting forks, knives, and spoons when we are putting them in drawers. We can throw all silverware together. But then finding a spoon in that pile will take time whenever we need a spoon. The task changes from getting a spoon (execution) to finding a spoon (identification). And that's a cost we want to avoid.
If we sorted the silverware and batched them while putting them in a drawer, we saved on finding each item's cost. This is further optimized by combining sorting silverware other utensils (bigger sorting function) as they come out of the dishwasher.
The same is true for tasks that have cognitive function. Imagine time savings after you have batched the PRs to review, bugs to fix in a given repo, meetings to attend at a given day, writing peer-reviews, replying to emails, responding on slack, etc.
Now you may be question that batching is also work and it takes time. Is it really wort it for all tasks?
My answer is to always batch. Depending on the task's size, batching may take the same amount of time as it will to complete the task. And on a few occasions, batching may take even more time than the actual work. But batching is also a skill that needs to be developed.
Practicing on smaller tasks will make you more efficient for bigger ones. At senior levels, the cost and impact of batching becomes really visible. Practicing low risk and low impact work helps avoid costly mistakes. And allows you to come up with a personal level for the sub-functional division that works for you. Once you become proficient at batching, you can then decide to skip it for smaller tasks if you still wish.
I hope this helps you get more productive and get more things done year!!
If you like this post, please share it with your colleague and consider signing up for more of such content.

Source: Substack.com

Powered by NewsAPI.org