🚀 Executive Summary
TL;DR: Engineers often fall into “productive procrastination,” spending excessive time organizing productivity systems like Jira or Emacs org-mode instead of doing actual development work. To combat this, the article proposes three strategies: using a minimalist `stupid_log.txt`, integrating tasks directly into the codebase with `TODO` comments and pre-commit hooks, and strictly time-boxing meta-work to prevent over-optimization.
🎯 Key Takeaways
- “Productive procrastination” provides a dopamine hit of accomplishment without the risk of failure, leading engineers to over-organize systems like Jira or Emacs org-mode instead of shipping code.
- Integrating task management directly into the codebase using `TODO` comments, CI grepping, and pre-commit hooks (e.g., for “FIX_NOW”) minimizes context switching and forces immediate action on flagged issues.
- Strictly time-boxing “meta-work,” such as tweaking IDEs or ticket workflows, to specific, limited periods (e.g., Friday afternoons) prevents it from becoming a daily distraction from core development tasks.
SEO Summary:
We’ve all fallen into the trap of tweaking our Jira workflows or Obsidian graphs instead of fixing the actual memory leak; here is why we succumb to “productivity porn” and three battle-tested strategies to stop shaving the yak and start shipping code.
The Productivity Trap: When Optimization Becomes Procrastination
I’ll admit it. In 2019, I spent an entire three-day weekend configuring a “perfect” Emacs org-mode setup. I wrote custom Lisp functions to sync my tasks with GitHub issues and color-code them by urgency. I felt like a god of efficiency. I walked into the office Monday morning, fired up my terminal, and realized I hadn’t actually written the migration script for prod-db-01 that was due by noon.
The irony? My fancy org-mode setup crashed because of a missing dependency, and I spent the first two hours of Monday fixing my to-do list instead of the database. We call this “bikeshedding” or “yak shaving” in the industry, but let’s call it what it really is: hiding.
The “Why”: It Feels Like Work, But It’s Safety
Why do we do this? Why do we spend hours searching for the perfect VS Code theme or restructuring our Notion dashboard? Because organizing work gives you the dopamine hit of accomplishment without the risk of failure.
When you are organizing, you can’t break production. You can’t accidentally drop a table on us-east-1-rds. It feels safe. It is “productive procrastination.” You are convincing yourself that you are sharpening the axe, but you’ve been sharpening it for six hours and the tree is still standing there, laughing at you.
The Fixes
If you find yourself tweaking your system more than doing the work, here are the three levels of intervention I use to snap myself (and my junior engineers) out of it.
1. The Quick Fix: The “stupid_log.txt”
When I catch myself over-engineering my task management, I force myself to downgrade. I close Jira, I close Trello, and I open a terminal. I use a single text file. No tags, no colors, no notifications.
I use a primitive alias that appends text to a file in my home directory. It’s ugly, it’s hacky, and it works because it removes the ability to “fiddle” with the system.
# The "Anti-Productivity" System
alias todo='echo "$(date +%Y-%m-%d) - $@" >> ~/stupid_log.txt'
alias tasks='cat ~/stupid_log.txt'
# Usage
$ todo Fix the SSL cert rotation on lb-public-02
$ todo Email Dave about the AWS bill2. The Permanent Fix: Git is the Only Truth
For DevOps engineers, context switching is the enemy. Every time you leave your IDE to check a productivity app, you lose flow. The permanent fix is to move your “system” into the code itself.
If a task is related to the codebase, it lives in the codebase. We use TODO comments that our CI pipeline actually grep’s for. If I need to refactor the auth-service, I don’t make a ticket immediately. I go into the code and leave a breadcrumb.
Pro Tip: We configured a pre-commit hook that blocks commits if they contain the string “FIX_NOW”. This forces us to actually do the work we flagged before we can push.
# python/auth_controller.py
def validate_token(token):
# TODO: This validation logic is legacy and creates latency.
# Refactor to use the new JWT library by Q3.
# Ticket: OPS-402
pass3. The ‘Nuclear’ Option: Time-Boxed Meta-Work
Sometimes you really do need to organize your system. But you need to treat “organizing” like a dangerous radioactive substance: handle with strict limits.
I have a rule for my team: You are allowed to tweak your environment (shell, IDE, ticket workflow) only on Friday afternoons after 2:00 PM. If you catch yourself looking up “Best Obsidian Plugins” on a Tuesday morning, you have to stop immediately.
Here is the reality of the trade-off:
| Activity | Perceived Value | Actual Value |
|---|---|---|
| Color-coding Jira Epics | High (Feels organized) | Zero (Code is not shipped) |
| Writing a bash script to automate deployment | High | Very High (Saves hours) |
| Researching “Better To-Do Apps” | Medium | Negative (Time sink) |
Stop configuring. Start building. The perfect system is the one that gets out of your way.
🤖 Frequently Asked Questions
âť“ Why do engineers often spend more time organizing productivity systems than doing actual work?
This phenomenon, termed “productive procrastination” or “yak shaving,” occurs because organizing systems provides a dopamine hit of accomplishment and a sense of safety, avoiding the risks and potential failures associated with actual development tasks.
âť“ How do these proposed fixes compare to using comprehensive productivity tools like Jira or Obsidian?
The proposed fixes prioritize simplicity and integration into the development workflow over feature-rich, dedicated productivity apps. They aim to reduce the “fiddle factor” and context switching inherent in external systems, pushing task management closer to the code itself.
âť“ What is a common pitfall when trying to stop “productive procrastination” in engineering?
A common pitfall is the failure to strictly adhere to the chosen intervention, such as reverting to complex systems or allowing meta-work outside designated time boxes. The solution involves disciplined commitment to minimalist tools or strict time-boxing to prevent re-engagement with over-optimization.
Leave a Reply