How I stopped my procrastination: Insights into developer mindset

You’ve been at your job for years, you know how to write code good enough to get you by comfortably, yet every now and then there’s a ticket, a ticket that lingers on-and-on on that kanban board, red with delays, reschedules and “is this done?” comments. “I’ll pick it up first thing in the morning” is what you told yourself yesterday, and the day is already dusking off.

We as programmers and developers are likely to procrastinate, and there are good enough reasons for it. And being lazy might be one of them, but the documentation of our brains is much bigger than that.

Why programmers are likely to procrastinate

Cognitive overload 😵‍💫

As problem-solvers, we tend to use the ‘most-contextual’ part of the brain way too often, i.e the Frontal Cortex.

The frontal cortex is responsible for executive functions, which involve analyzing information, identifying patterns, decision making, and most importantly, doing-the-right-thing-even-if-it-is-the-hard-thing-to-do actions.

For these seemingly-simple tasks, the frontal cortex needs bucket-loads of energy, exhibiting a very high metabolic rate.

We, as mere mortals with anti-bluelight glasses, have fixed reserves of energy, and when we expend them, compromises start to occur.

Behave’s author Sapolsky point out that when the frontal cortex is overloaded, subjects become less prosocial, they lie more, are less charitable, and are more likely to cheat on their diets.

“Willpower is more than just a metaphor; self-control is a finite resource”,

he says, stating that doing-the-right-thing-even-if-it-is-the-hard-thing-to-do is not merely an emotional and moral choice, but is far deeply tied to the physiology of the brain.

I’m just a kid

We have all had our fair share of beginner-developer moments. When we plowed through nights and days trying to learn and retain how that x language or y framework functions. And the number of times we almost gave up.

But after a certain threshold, coding didn’t seem to have that big of a draining effect. And there’s a good reason for it.

When we practice and learn something, we start shifting the cognitive processes to the more reflexive (stemming from a reflex action, an automatic “muscle memory”) parts of the brain, like the cerebellum.

And once that is achieved, we reduce the burden of computation on the Frontal cortex, making the tasks less energy-taxing.

Decision Fatigue

Cognitive tasks are not limited to logic-oriented, calculative, cautious tasks that one does as a programmer.

It also includes a seemingly simple task: Decision making, like using the correct approach to write readable code, or something as simple as which task should I ship first?

And like cognitive loads, decision-fatigue is tied to your energy reserves too, and can ultimately affect your productivity.

Process rather than Procrastinate

Now that we have broken down Procrastination, it's time to actually tackle it.

1. Germinate

To achieve anything, whether it’s your jira-ticket’s completion, or a side project, one must start to build. “Am I taking the most efficient, readable, perfectly orchestrated approach to solve this problem”; the friction of uncertainty and self doubt usually make it hard enough to begin with.

Opening your laptop is the first victory to overcome the code-block. And the only way to do that is to have something certain, some anchor that doesn’t give you any unease.

I’ve had times where I tried to find a perfect time window to start programming on a weekend, that was me trying to find a unicorn.

So I made it a point that at a certain hour in the morning, I will open Monkey Type and try to hit the day’s first 80+ words a minute.

It’s something I stole from Atomic Habits, and it helped immensely. This simple ritual in the first 5 minutes of my day consisted of adrenaline-rushed, muscle-memory reflexes that had nothing to do with uncertainty of my task.

Thus, I could be eased into opening my IDE to complete that Jira ticket, whose dread had haunted my jira board for a week.

2. Granular-ize

Something I learnt fairly recently is to plan in a way that your programming journey will have little to no decision making once you start with writing code.

Everything else can, and should be pre-planned, into its utmost smallest task-granules, making things as clear as they possibly can be.

The concept of Engineering Requirements Document (ERDs) was something I looked down upon as a corporate scut-work for the upper management to feel included in the process.

Turns out I was wrong, and it’s intended to make sure that all the decision fatigue occurs during initial stages, and the rest of the shipment of tickets spread throughout the week remains relatively unharmed from taxing your Frontal cortex’s energy reserves.

3. Game-ify

Updating my Jira tickets on my kanban board didn’t give me enough belongingness to the fruits of my labor. Neither was I able to track my personal progress of what I completed, what I shipped and what I spilled.

So I kept a set of my mini daily tasks on a local Microsoft’s To Do list. The satisfying chime of completing the task gave me a big boost on being on track, without having to worry about what is left undone and what is yet to be picked up.

Since this was personal, I could add tasks like “get a brownie on 3 completions” and wait for it to ping up when I marked it as done.

Motivation is a cocktail of neurotransmitters, make sure you zap your brains with some hits, every now and then.

Another tool that can help in the same is Middleware’s Project Overview. It systematically gave the reason for my spills and overcommitment in a sprint, and can help give an overview of your Jira Boards and Projects.

4. Gauge, Grapple and Give-up (not totally)

Friction in the building process goes far beyond decision-fatigues. You fail at something for long enough and you are likely to not want to do that thing anymore.

It's wise to gauge the problem, allocate a time-duration, and wrestle with the problem with all your might. But when you know that it’s time-up, ask for help.

You need to make a voluntary decision to make the problem smaller than your hands, or add more hands to it.

There’s nothing wrong with an extra set of limbs, or brains. Homo erectus showed the first signs of ordered-socialization within communities, and then came homo sapiens with their big-brains of computation. Companionship precedes cognition, at least within evolution.

5. Conclusion

We as developers often forget how human we are, I mean we are running services that cater to millions of humans.

Who are we, but gods on keyboards?

But, something as little as a missed breakfast can affect our productivity, and something as big as a system-failure can drive us to work harder. We are complex machines with simple values.

As a developer who would rather write a script for an hour, rather than clicking 4 buttons in 4 seconds, I can vouch, it’s always wise to fix a process rather than the absolute problem. Fix habitual actions, and you fix procrastination.