Ground Cover: When Implementers Become Ticket Machines
You used to care about craft. Now you just want the queue to stop. Here's how you got here—and how to get your soul back.
There's a moment when the spark dies.
You remember when you cared about code quality. When you'd refactor just because something felt wrong. When you'd write tests not because they were required but because they were right.
Now you look at the ticket queue. Forty-seven items. You close one, three more appear. Close three, five more appear. The queue never gets shorter. The finish line never gets closer.
So you adapt. You stop caring. You close tickets. You don't refactor because refactoring isn't in the ticket. You don't write extra tests because extra tests aren't scoped. You become efficient at precisely the work that's asked, and nothing more.
You've become a Ticket Machine.
Welcome to burnout, Ground Cover style.
The Ticket Machine Descent
It happens in stages:
Stage 1: Enthusiasm You join the team excited. You care about quality. You go the extra mile. You refactor adjacent code when you touch a file. You write thorough documentation. Stage 2: Overwhelm The queue is endless. The extra effort isn't recognized. There's always more work than time. You start cutting corners—just to survive. Stage 3: Optimization You learn what "done" means: the ticket is closed, the test passes, nobody complains. Quality beyond that is wasted effort. You optimize for ticket velocity. Stage 4: Numbness You stop feeling bad about cut corners. You stop seeing the technical debt you're creating. Work becomes mechanical—input tickets, output code, repeat. Stage 5: Cynicism You resent the architects who don't understand the grind. You mock the mentors who have time to teach. You've seen too many initiatives fail to believe anything will change. Hope becomes a liability.
This is the Ticket Machine. Functional on the outside, hollowed out within.
Why Organizations Create Ticket Machines
This isn't a personal failure. It's a system failure.
Infinite demand, finite supply. Organizations treat development capacity like an infinite resource. "Just add it to the backlog." The queue grows forever. No one says "we can do 50 things well or 200 things poorly." Measurement by throughput. Productivity is measured by tickets closed, not quality delivered. Incentives optimize for volume, not craft. Invisible quality. Refactoring doesn't show up in metrics. Tests beyond minimum coverage don't show up in metrics. The extra effort is invisible—and therefore unrewarded. Replaceable mindset. Ground Cover developers are treated as interchangeable. "Anyone can close tickets." This dehumanization creates the conditions for burnout. No slack in the system. Every hour is allocated. There's no time for thinking, refactoring, learning. 100% utilization = 0% improvement capacity.
The Way Out
If you're a Ticket Machine, here's how to reclaim your soul:
1. Accept that it happened. You're not a bad developer. You adapted to survive in a dysfunctional system. That's rational behavior. The first step is noticing it without shame. 2. Identify what you've lost. What did you used to care about that you've stopped caring about? Testing? Code quality? Documentation? Learning? Name it. 3. Reclaim small moments. You can't transform the whole system. But you can reclaim small moments of craft. One refactoring per day. One test beyond the minimum. One piece of documentation you'd want to read yourself. 4. Set boundaries on the queue. The queue will never be empty. Accept that. Set a sustainable pace—not the maximum you can theoretically produce, but a pace that leaves room for quality and sanity. 5. Make quality visible. Track the bugs you've prevented. Document the refactoring you've done. Advocate for your craft. If quality is invisible, it's unrewarded. Make it visible. 6. Find allies. Other Ground Cover developers feel the same way. Find them. Commiserate. Strategize. Collective action is more powerful than individual suffering. 7. Consider leaving. If the system is fundamentally broken—if leadership genuinely doesn't care about quality—consider whether this is where you want to be. Some organizations can't be fixed from inside.
The Organizational Fix
If you're a leader watching developers become Ticket Machines:
Stop measuring tickets. Or at least stop making ticket count the primary metric. Find ways to measure quality, sustainability, and capability growth. Create slack. 15-20% of time should be unplanned—for refactoring, learning, improvement. 100% utilization is a recipe for burnout. Recognize quality work. In performance reviews, in public recognition, in promotion decisions—celebrate craft, not just output. Right-size the queue. Stop pretending you can do everything. Prioritize ruthlessly. Say no to work that doesn't matter. Treat developers as practitioners. Not resources. Not ticket-closing machines. Practitioners with craft, judgment, and professional identity.
The Choice
Here's the truth: you have more agency than you think.
The queue is real. The pressure is real. The dysfunctional system is real.
But you still choose what kind of developer to be.
You can close tickets mechanically, accumulating debt and dying inside. That's a choice.
Or you can decide: "I will do this work well, even if the system doesn't reward it. I will maintain my standards, even if no one notices. I will care about craft, even if caring is hard."
That's also a choice.
The queue will still be there tomorrow. The question is: what kind of person will you be when you face it?
Next in series: "Nitrogen Fixers: The Joy of Teaching (And Its Hidden Costs)"