I've overcome countless challenges in my career; servers crashed, networks went down, critical ERP modules failed. But what truly exhausted me, what cost me sleepless nights, was never a line of code I wrote or a server setting I configured. What pushed me to the brink was the expectations of others and my own self-imposed delusion of "I can handle everything." What I understood late when burnout hit was the fact that the biggest technical debt is actually the unnecessary promises we make to ourselves.
The experiences I gained over the years, especially my 20 years of field experience in system architecture, networking, and enterprise software development, taught me a lot. However, the hardest of these lessons was recognizing my personal boundaries and being able to say "no." Whether working on the most critical modules of a production ERP or building an architecture from scratch for a bank's internal platform, I always acted with the thought, "if I push a little harder, it will work."
The True Cost of Constantly Saying "Yes"
I realized far too late how destructive the technical consequences of constantly saying "yes" could be. In a client project, on April 28th, when the disk filled to 100% and the system crashed, while searching for the root cause, I saw that this problem was actually the sprouting of seeds planted months ago, in moments when we said, "we'll do this too." Postponing necessary maintenance, features pushed live without adequate testing – all were indirect consequences of those "yeses."
In another instance, when I wanted a new feature for the financial calculators of my side product, I put myself under unnecessary pressure by thinking, "this is easy, I'll handle it." As a result, we experienced performance drops under sudden loads because I couldn't properly configure the connection pool in PostgreSQL. This seemingly simple error was actually a reflection of the "I can get everything done" pressure I put on myself.
⚠️ Invisible Technical Debt
One of the most insidious factors leading to burnout is viewing technical debt solely as code or infrastructure deficiencies. Yet, the biggest technical debt often stems from accepted but unrealistic timelines and our desire to exceed our own limits. This debt has much broader impacts, such as performance degradation, system instability, and even team morale breakdown.
The Human Factor Behind Technical Problems
Over the years, I've seen that most technical problems originated from non-technical decisions. When I inadequately calculated the number of VLANs while designing a network segment, the root of this error was actually the lack of time allocated for sufficient analysis at the beginning of the project. Or when I couldn't correctly choose Redis's OOM eviction policy, the reason was the pressure to "go live as soon as possible" instead of having enough R&D time.
In my opinion, enterprise software architecture is often about organizational flow, not just software. When developing an ERP for a manufacturing company, designing the "purchase-produce-ship-invoice" flow, how much of the processes we could optimize, how much we could automate, actually depended on the answer we gave to the question "how much load can we take on" at the start of that project. If we overloaded ourselves, there were inevitably disruptions somewhere in these flows.
Drawing Boundaries and Learning to Say "No"
In an incident last month, while configuring SystemD timers, I wrote sleep 360 and caused a service to be OOM-killed. While this might seem like a simple error, it was actually a result of the underlying pressure to "get it done quickly." Such small, hasty errors can accumulate over time and turn into major problems. Although I solved the problem by switching to a polling-wait mechanism at that moment, the real lesson was how careful I needed to be under time pressure.
Finally, I understood that the most valuable things for me were my time and energy. Now, when discussing the scope of a project, I put not only the technical requirements on the table but also the team's mental bandwidth and potential signs of fatigue. Saying "no" when necessary means saving the project rather than sinking it. This is not laziness, but a smart strategy for sustainability.
My New Normal After Burnout
Today, at this point in my career, I do my work more consciously and sustainably. I know my own boundaries better and evaluate projects from a more realistic perspective. Even with the spam blocker app I developed for Android for one of my side products, before adding a new feature, I carefully consider how much it will impact me and my current workload.
This wasn't something learned overnight; it came through many years of experience, making mistakes, and learning from those mistakes. Coming to the brink of burnout forced me to stop and reflect, and it showed me what truly matters. I understood that protecting our own health and boundaries is just as important as technical excellence.
So, what was your biggest "yes" mistake in your career? What lesson did you learn from it? Share in the comments.
