Developer productivity: Why I stopped writing clean code first
Developer productivity relies on momentum, not perfection. Learn my "Draft-First" workflow to stop overthinking and start shipping code faster.
I used to spend the first hour of every feature agonizing over directory structures and interface definitions. I wanted the code to be perfect before the logic was even sound. The result? I’d burn out by lunch, having barely touched the actual problem I was supposed to solve.
Everything changed when I shifted to a "Draft-First" approach. Instead of trying to write clean code on the first pass, I treat my initial implementation like a rough draft in a text editor. It’s ugly, it’s repetitive, and it’s often held together with duct tape. But it works. By decoupling the creative act of solving a problem from the mechanical act of refactoring, I’ve found a way to maintain developer productivity even when the requirements are ambiguous.
The Problem with Early Perfectionism
When you try to enforce clean architecture or perfect abstraction while the core logic is still fuzzy, you’re essentially trying to solve two hard problems at once. You’re fighting the syntax of your framework while simultaneously trying to map out a complex business process.
I call this "premature optimization of the workflow." It’s the primary reason many of us struggle to get deep work done. You get stuck on a naming convention or a dependency injection pattern, and your brain loses the thread of the actual algorithm.
I remember refactoring a payment processing module last year. I spent about three days trying to make it "extensible" before I’d even successfully hit the API endpoint. I was deep in a hole of abstraction. When I finally cleared my workspace and started over, I just wrote a single, 150-line procedural function. It wasn't pretty, but it worked in 45 minutes. From there, cleaning it up was trivial.
Implementing a Draft-First Workflow
My software development workflow now looks like this:
- The "Brain Dump" Phase: I write code without worrying about tests or modularity. I use
console.logorprintstatements instead of a debugger. If I need a helper function, I just write it inline. - The Verification Phase: I run the code. Does it solve the problem? If yes, I commit the messy state locally. This creates a "safe point" so I can experiment without fear.
- The Refactor Phase: Now that the logic is proven, I look for patterns. I extract classes, move files into their proper modules, and add unit tests.
This process isn't just about speed; it's about reducing the cognitive load that leads to context switch tax. By staying in a flow state during the draft phase, I finish the "hard" part of the work before the inevitable distractions of the afternoon set in.
Comparing Approaches
| Feature | Clean-First Approach | Draft-First Workflow |
|---|---|---|
| Focus | Structure & Syntax | Logic & Correctness |
| Speed | Slow (High friction) | Fast (Low friction) |
| Refactoring | Frequent, mid-flow | Batch, post-flow |
| Cognitive Load | Extremely High | Manageable |
When to Stop Drafting
There’s a clear danger here: if you never refactor, you end up with a codebase full of technical debt. I treat my "Draft-First" phase as a temporary state. If I haven't cleaned up my draft within about 24 hours of starting a feature, I force myself to pause and refactor.
I’ve also found that using simple CLI tools helps me manage this transition. I rely on small scripts to keep my environment clean, which you can read more about in my guide on protecting attention with engineering tools.
I'm still not perfect at this. Sometimes I fall back into the trap of over-engineering a simple CRUD endpoint because I’m bored or trying to be "clever." But the Draft-First method is my safety net. It reminds me that code is a tool, not a museum piece.
Next time you feel stuck, try intentionally writing bad code for an hour. You might be surprised at how much faster you reach the finish line.
Frequently Asked Questions
Does Draft-First lead to bad architecture? Not necessarily. It actually helps you discover the right architecture because you’ve seen how the data moves through the system before you try to formalize it.
Should I skip tests during the draft? I don't skip them entirely, but I write them after the draft is working. Writing tests against a moving target is frustrating; writing them against a stable, albeit messy, implementation is much easier.
How do you handle team code reviews with this? I never push my draft code to the main branch. The "Draft-First" workflow happens entirely in my local feature branch. By the time it hits a PR, the code has already been through the Refactor Phase.