Does being the office's official "fixer" sound familiar?
I’m sure you know exactly what I’m talking about. That slightly masochistic sense of pride you feel when someone on the team says: "This is an absolute mess, let Roberto look at it—he always saves our skin." For many, many years, I thrived on that. I thought being a good developer, and especially a good teammate, meant having a request inbox that was always open and responding with a firm "sure, count on it" to any last-minute change, critical bug (which usually wasn't that critical), or feature dreamed up during a Friday afternoon meeting.
I believed, quite naively, that saying yes to everything made me indispensable. That it gave me an aura of efficiency and commitment that no one else had. But what I didn't see was that while I was collecting those "yeses" like medals, I was digging a pit of exhaustion and frustration that almost made me throw in the towel on this profession I love so much. And not only that: my code was starting to look embarrassing. When you try to please everyone, you end up doing nothing really well.
The day my brain said "enough is enough"
I remember the exact moment everything changed. We were in the middle of a major launch for the kind of client that doesn't let anything slide. My to-do list was already unmanageable, but I kept accepting "quick" design tweaks, validation logic changes the Project Manager had just dreamed up, and a couple of refactors that, according to a teammate, "wouldn't take more than ten minutes."
It was ten o'clock on a Thursday night. I was at my editor, wide-eyed, trying to understand why a function I had written myself two hours earlier wasn't working. I realized I wasn't just physically tired; mentally, I had become a crashed processor. My capacity for critical analysis had completely vanished. I had said yes to so many things that I no longer knew what the real priority was. In the end, we delivered something that barely worked, full of hacky fixes and technical debt that would haunt us for months. That weekend, instead of resting, I could only think about how much I hated the project and, by extension, my job.
Why do I think learning to say no is so important?
After that episode, I had a very honest conversation with myself (and my pillow). I realized that my inability to set boundaries wasn't a virtue—it was a weakness. When you say "yes" to a last-minute change without evaluating the impact, you are being irresponsible. You are risking the stability of the system and the quality of the final product. Being a professional isn't about doing everything you're asked; it's about knowing what's right for the project.
I began to understand that people didn't respect me more for always saying yes. On the contrary, they saw me as the easy go-to, the path of least resistance. If someone needed something quick and dirty, they came to me. If someone wanted a serious analysis and a robust implementation, they looked for others who knew how to defend their time and their processes. That realization hurt, but it was the engine for change. I understood that my value as a developer doesn't lie in my speed at patching things, but in my ability to build sustainable solutions.
What I've learned in this "rehab" process
The first "no" I dropped was terrifying. It was in response to a request to add a complex filter to a dashboard when we were already in the sprint closing phase. I remember my heart racing. But I did it constructively: "I understand this filter is useful, but adding it right now risks the stability of what we've already tested. We can include it in the next sprint with the time it deserves." And you know what happened? Nothing bad. The Project Manager nodded, noted the task for later, and thanked me for the heads-up.
I've learned a couple of fundamental things since then. First, that a "no" in time is actually a "yes" to quality. By turning down an extra task, I'm ensuring that the tasks already on my plate are finished with the necessary rigor. Second, transparency builds trust. Now, when someone asks me for something, my response is usually: "Let me analyze the impact and I'll tell you if it fits into the current schedule." This gives me space to think and shows that I take my work seriously.
Curiously, my relationship with the team improved drastically. By stopping being the "technical errand boy," I started participating more in architecture decisions. My opinions began to carry more weight because people knew that if I said something could be done, it was because it was actually viable and safe. I became a benchmark for judgment, not just execution.
Final reflections
If you're reading this and you feel identified—if you feel that knot in your stomach every time you get a Slack notification asking, "do you have a sec for a quick thing?"—my advice is simple: start small. You don't need to be an impenetrable wall tomorrow, but start questioning the requests that come your way. Ask about the impact, ask for clear priorities, and above all, value your own time and mental health.
At the end of the day, the code we write is a reflection of our mental state. An exhausted and resentful developer writes code that, sooner or later, someone will have to fix. Setting boundaries doesn't make you a worse teammate; it makes you a better professional. And believe me, once you take the leap and see that the world doesn't end just because you said something can't be done right now, the freedom you feel is incredible. Now I enjoy my work much more, my deliveries are much more solid, and most importantly, I’m sleeping soundly again without mentally reviewing last-minute commits I never should have pushed.