I Don't Want to Work Anymore, Ever, on Anything. But They've Learned to Squeeze Results Out of Me

A brutally honest essay about developer burnout, the dysfunction of corporate Agile rituals, the conflict between engineering craftsmanship and ticket-velocity culture, and the existential trap of golden handcuffs in the software industry.

Editor's Context

This article is an English adaptation with additional editorial framing for an international audience.

  • Terminology and structure were localized for clarity.
  • Examples were rewritten for practical readability.
  • Technical claims were preserved with source attribution.

Source: the original publication

Header illustration

A crappy morning for a remote worker always starts the same way. If the child's crying couldn't drag me out of bed, then my wife's nagging will do the job with certainty. It's a frantic nine in the morning, the daily sync-up is in an hour, and as usual, nothing got done yesterday. I quickly brew coffee and get to the computer. Five minutes before the call, a pull request with enterprise-quality code solidly joined the build queue. I go out for a smoke, but on the way my phone blared — I foolishly installed Skype on it, and now work can reach me anywhere. The smoke break is postponed; I prepare to be indignant that someone called me before the scheduled time. I threw on my headphones, accepted the call. Instead of the usual woman manager, some guy I didn't know started the call. "Hey everyone, Anya is sick, I'll be filling in for her." Okay, who cares, they could've sent us a dog as a manager with equal success — nothing would change.

The guy quickly changed my mind:

— Don't you have a practice of using webcams on dailies?
— No, why the hell would we need them?
— Blah-blah-blah, study, blah-blah, using webcams increases team productivity
— Uh, where's the connection?
— Blah-blah-blah, success, overcoming, teamwork, millions of opportunities, blah, Blah!!!

Under a heap of words, very simple things are always hidden that nobody ever says directly. Ideally, he should say: "Without a webcam, I don't believe you're listening to me." And I should reply: "I'm not going to listen to you, but I'll keep hiding that." And if you dig deeper, the conversation is very simple:

— Don't want to work.
— You have to.

I've been writing code every day for years and I know perfectly well that if I don't want to work on something, it'll come out both slow and bad. The businesses I've dealt with introduce KPIs, and they show that I often don't work very well. The business doesn't like this; it starts demanding improved metrics. Demanding from me, from the lead, from the manager, and from the manager's manager too.

That's where each of us starts contributing to improving those metrics. The head manager introduces webcams on syncs, for example. The regular manager forces us to estimate tasks more precisely, which makes us stop thinking about how the problem should be solved — instead we think about how quickly we can call the ticket resolved. The lead breaks tasks into smaller ones. And I, instead of writing systematic, robust code, just fire off small, dumb fixes that close tickets. KPIs improve. The business writes all these steps in a notebook, hangs it at the entrance of the head office, hires a keeper of the notebook, and subordinates all development to this artifact.

That's how the numbers are born that they then use to prove to me — the rituals work. And at that moment I'm mentally thanking all the gods that I'm not writing medical software. The little pieces of crap that I call my contribution to the project will, someday very soon, fail. Somewhere some business will lose some money, someone will get fired, someone will bring new numbers to their boss proving that their testing department doesn't work properly, and they'll bring their rituals there too. But nobody will die, I'll get my money, and I'll add Agile as a case skill to my resume.

This corporate practice only eats budget, converting it into lying reports that show how much this practice improved and accelerated everything. Based on these reports, management gives Agile more budget, and Agile produces even more reports. But this system has no tail-call optimization, the stack will run out, the company will go bankrupt, the managers will talk about failures you need in order to gain new experience, and they'll go bury the next company.

And I understand them. We live in a world where human life is, like, the highest value, but human desires are worth nothing. Who cares what you want — you got paid, work. It's just that business methods for influencing employees have evolved. Instead of punishment, they started hacking our unwillingness to work and squeezing results out of us like oranges against our will.


I've been rewarded many times — given bonuses, raises, simply praised. But this always happened after I closed a ticket ahead of the estimate, or knocked out several tasks with a single PR. Meaning, I was told they were happy with my work only when I gave them speed.

Such a wild emphasis on speed at the expense of quality isn't a strategy, it's a coincidence. Because speed, unlike quality, can be measured without straining your brain. Their stupid business values are only what a project manager can see. In the end you're faced with a choice: either you're a crap-maker or a bad worker. Yes, some people find the energy to convince everyone around them, to push their line, but definitely not the majority of us.

We're never hired as crap-makers, and we're not taught to be ticket conveyor belts. But you start working, and they silently hint: "How about you, Phil, work a bit faster, with the minimum possible quality, you know, so it doesn't fall apart literally today."

Sometimes the system glitches, I write good code, and nobody notices — be grateful they didn't chew you out for blowing the estimate. Then I come to an interview, and they ask me to talk about cases I'm proud of. I retell those exact moments when I did something well, ignoring Agile and managers. And they say: "Awesome!!! People like you are exactly what we need." But two days later they write in Slack: "I don't understand, you've already spent two days on a task that here takes 20 minutes. We need to get on a call and discuss your progress."

I'm tired of explaining to everyone around me that there are tasks that shouldn't be decomposed, that a "temporary" solution now will spawn a hundred similar ones in the future, and those will spawn even more workarounds... Every such change to a crap project makes it even worse, regardless of the quality of the person who made it. For me, these are self-evident truths; for business, I'm a dangerous fool who argues with their numbers.


Yes, I can spend my whole life making some garbage, or I can build important things, or even be at the origins of a great project, like some Stallman or Torvalds, so that later the success-seekers kick me out because I'm an old toxic jerk who ruins their community. The problem is, none of this matters. The clueless success-chasers who sooner or later start controlling any important process will ruin everything.

The success-seekers manage to turn anything into faceless, disgusting pop-garbage. They figured out that programmers enjoy developing, and invented the concept of "Drives you." They figured out how to tell those who are "driven" from those who aren't. Created hundreds of patterns to shove any worthwhile idea into a shiny plastic box and make it as ordinary as possible. Stripped all uniqueness from everything I'd want to do.

They did it because that's their whole success-seeker essence — there's no uniqueness in them, and they eliminate it everywhere they can see it, because they hate and fear it. In the end, I'm offered an industry that's creative by nature, in which there's no option for uniqueness. It's very simple — you, Phil, are a cog in the machine. Don't want to be one? Great. That's our favorite type of cog. Here's a pile of money, get used to it so you don't even think of leaving us and trying to do something independently. Here's your cookies, cool office, remote work, community, conferences-parties, amazing coffee, respect, the ability to do nothing at work, anything you want — just don't you dare say our world isn't real.

My motivation to do good work isn't influenced by money, team-building, corporate spirit, or company goals. I work for the sake of engineering self-actualization — that feeling when you open your pull request and think, "damn, this is amazingly done." When every commit of yours improves the project's codebase, and thousands of your ideas work harmoniously with thousands of your colleagues' ideas, forming a coherent system. That's real magic, and honestly, that happens to me very, very rarely.

I'd prefer to forget most of my "contributions." Ticket in resolved, money on the card, another week of life lived only so that I could live it. And I turned out to be yet another "idiot who worked on the project before..."


The success-seekers and other biological waste my well-being depends on have gone off to bomb something and won't read this far. So we can start talking about the really important things.

The thing is, I've realized — I don't want to work. Like, at all. Not just "I want to rest" or "I need to figure out how to be productive" or "find something I enjoy doing." I don't want to work at all, absolutely, ever, on anything.

Even if I imagine ending up at an ideal company or starting my own — the problem won't disappear. Artificial motivation isn't enough to change this. And I would very much like to want to work all the time. But I don't control this. So I force myself.

We're wired so that when we face an unsolvable problem day after day, we invent a value system in which this problem doesn't exist. So I start lying to myself that if I'm not writing code and not sitting at the computer, it doesn't mean I'm not working — I'm supposedly thinking about the task. And if I'm not ready to write code right now, it means I don't yet have a vision, and I shouldn't write code yet. This is, of course, severe self-deception.

Companies account for the fact that people don't want to work five days a week, eight hours a day without breaks, and fight against it. With money, values, and other corporate tools. This only makes things worse. I was working as much as I could. They come to me and say — now we're paying you more, but you should also work more. And I can't. But I don't admit this to myself — a deal is a deal — and I agree. And I start working more, more, and worse. This makes me unhappy; I start hating the profession and corporations. And then they come and ask me to work even more. And I agree again.

There's no escaping this vicious cycle. I can no longer afford to go even one month without earning at least two hundred thousand. I can't do anything on the side. Even if I do nothing all day for work, my conscience won't let me work on something of my own. And most importantly, I'm starting to believe that, damn it, this is exactly how it's supposed to be. My words at meetings, when I copy the sheep-like project managers while laughing hysterically to myself, are gradually ceasing to be irony. I've been pretending to be a success-seeker for so long that I'm slowly becoming one of them.

It's terrible, but this is the only thing saving me. You know how philosophers proposed solving the Sisyphus dilemma — "die right now or live a meaningless life full of suffering and die anyway"? They said — "become a success-seeker and push the boulder with a smile on your face."

So, folks, let's smile and push.


Together with arttom, I now host a podcast called "We Are Doomed." It's all like in the articles — maximum directness about development, the industry, money, and interviews.

Why This Matters In Practice

Beyond the original publication, I Don't Want to Work Anymore, Ever, on Anything. But They've Learned to Squeeze Results Out of Me matters because teams need reusable decision patterns, not one-off anecdotes. A brutally honest essay about developer burnout, the dysfunction of corporate Agile rituals, the conflict between engineering craftsmanship...

Operational Takeaways

  • Separate core principles from context-specific details before implementation.
  • Define measurable success criteria before adopting the approach.
  • Validate assumptions on a small scope, then scale based on evidence.

Quick Applicability Checklist

  • Can this be reproduced with your current team and constraints?
  • Do you have observable signals to confirm improvement?
  • What trade-off (speed, cost, complexity, risk) are you accepting?