As Software Engineer, nearly everyone encounters a work-prolonging blocker that is procrastination. The causes of procrastination are many and the solution is not clear-cut. In this post I talk about work, how and why it is divisible, and the way to make use of a checklist to break the cycle of continuous procrastination. At the end, I share an example of real-world engineering task along with its possible checklist.
Reality Of Work
You will realize that work – any work, not just a programming task – is always composed of smaller tasks, all of which are composed of further subtasks; this goes on and on, more like a nested tree, till a single task is no longer meaningfully breakable into more components. Ironically, software engineers should be the ones to identify this pattern, having been introduced to divide and conquer algorithms and recursion as beginners.
Humans spot the subtasks up to a certain level, after which unconsciously they tend to group all the subtasks into one big identifiable unit, not realizing that it is further breakable. Take for example the following task:
Drive To Work
Usually, we never think of it as divisible, although it very much is:
- Find the car’s key
- Quick look at the tires
- Open the garage door
- Open the car door, sit, and close the door
- Start the car
- Spray water on windshield and run viper to clean it
- Wait a few minutes before reversing the car out of the garage
- Get out again to shut the garage gates
- Get back into the car, put it into drive, and start moving
- Navigate the traffic and so on…
I could be pedantic and list down hundred other small subtasks that are involved in getting you to reach office while driving. But you get the idea. The whole task is like a step-wise algorithm that we need to run to accomplish it, one step at a time.
However, we rarely appreciate that drive to work is composed of these subtasks. It appears to us as one unit, and we’re not bothered about dividing it any further.
How Is Creative Work Such As Programming Different From Routine Work?
The reason we don’t give a second thought to chores is that we have memorized the sequence. In other words, we won’t be able to accomplish our task even if one step is out of order or incomplete.
But creative work is different. On one side of the creativity spectrum you have a blank canvas to fill as you please, while on the opposite end you have to be creative within limitations and a pre-defined framework. Programming lies somewhere in between.
This naturally means that in contrast to the above work to drive example, where we know the steps beforehand, you’re not 100% sure about the nature of the creative work and what steps you need to take to finish it. That is what happens to the software engineers frequently, which results in crushing feeling of overwhelm, that eventually culminates in procrastination.
How Is Checklist Effective?
Once you realize what is overwhelming you, it’s easier to use divide and conquer – that you know only too well – to your advantage, and concentrate on parts rather than the whole.
This is psychologically effective, too. You need an entrance to the work mode, that you can’t find looking at a big and dull task before you. But having listed down the subtasks you only need to attempt one subtask at a time with complete and undivided attention. Once you achieve it, the dopamine automatically pushes you to start the next subtask and so on it goes, much like an AK47 where you need to pull the initial trigger to start the stream of firing bullets one after another. By achieving first subtask, you trick yourself into the work mode!
How Many Subtasks?
The natural question that follows this checklist advise is that how many subtasks you should aim for?
Obviously, no one is stopping you from listing down too little or too much. But as with most things, moderation is always the key. As a general guideline, the more daunting a subtask is (however small), the more you should ensure that it makes the list.
Flat Checklist Or Nested?
Another obvious question that arise is: Should we split the tasks into subtasks recursively or should we keep the list flat?
I personally prefer a flat list, because however many subtasks you manage to create they will have to be done in isolation. So you might as well put everything in a flat list and avoid the overkill of nesting.
If a subtask is indeed complex enough to warrant a further breakdown, it should be better as it’s own separate checklist.
Paper, Notepad, Or A Cloud Application?
Whatever works for you. Some people find pen and paper appealing, because they feel like planning. A default computer or mobile app, like the built-in notepad, also serves the purpose; so does a downloadable cloud application like Google Keep. The added benefit of a cloud app is that you can access and modify the list from any device and anywhere.
Having a checklist with an option to check/uncheck the items, and with a feature to move the checked items to the bottom, is much easier to work with because of the visual cues.
Let’s wrap it up with an example of a checklist for real-world task you can get as software engineer.
Add Notification Dropdown
The task is to add a new feature Notification Dropdown to the front-end application. It appears in the header and behaves much like Facebook’s notification dropdown does.
Assume that it’s React application, with Redux and Redux Saga for state management, and tailwind for styling. Here’s how the checklist would look:
Create a git branch “notification-dropdown” off “master”
Add a new directory “notification-dropdown”
Add files “index.js”, “container.jsx”, and “row.jsx” in the new directory
Add UI and styling code to “row.jsx” component
Add UI and styling code to “container.jsx” component
Create and style a notification bell icon for new notifications
Add action, reducer, saga files for notification dropdown, and fill them with boilerplate Redux code
Integrate notification APIs with Redux code
Integrate the Redux code with the notification dropdown UI
Double check that the UI is according to the designs
Ensure the dropdown is showing the live notifications
Create a pull request and ask your lead for code review
Do the review feedback changes, if any
Deploy the code in test environment and move the to “QA”
Do the QA’s feedback changes, if any
The same list in Google Keep:
With checked items:
The above checklist can be reduced or extended as per your personal preference. All the items are actionable to the extent that they take you one step closer to the completion of the parent task without overwhelming you.