As a developer, my daily job is essentially a stream of requests, features, and bugs coming from management or alerts raised by other teams.
Over time, I’ve developed a specific mindset: Development work can be a little late, but debugging and fixing issues for other teams should be done as fast as possible.
If a teammate is blocked or a customer experience is degrading, that becomes the top priority.
The “Frustrated Customer” Test
Personally, when I am in the role of a customer, I feel the same.
Right now, I’m a customer of a home insurance company. I called them to request a certificate for my insurance contract because their system had a problem. It took them several days to send it, even though I needed it urgently. It drove me crazy. I only wanted to switch to another insurance company because the experience was so bad.
But if they had sent me what I needed immediately, I would have been very satisfied—and I would not hesitate to recommend them to my friends whenever they need home insurance.
We are the “Support” for the Revenue-Generators
In my opinion, the dev team inside a company plays more of a support role than a direct revenue-generating one.
Think about it: humans were trading goods and building business empires long before technology existed. We shouldn’t glorify ourselves too much or think we are the most important part of the machine. Instead, we should collaborate to create value.
For me, the people who deserve the best support are those who search for customers, interact with customers, or work on things related to customers (like preparing quotes) that directly generate revenue for the organization.
If the system is already stable and you are developing a brand-new feature, but another team reports a bug, you can’t say: “I’m busy with my own tasks. I have a lot to do. Please wait until I finish.”
We should evaluate urgency based on one metric: Does this impact the customer experience or organization revenue? If yes, handle it first. When the customers are happy, the whole system benefits—including us.
The “Context Switching” Myth
Some people say: “Context switching gives me headaches. I can’t focus.”
Honestly, I don’t think that’s the whole truth. Headaches happen when you try to juggle three massive projects at once. But when a system is stable, most issues are just small patches or quick fixes.
If an issue is large enough to cause significant financial damage, you should pause your work. The cost of ignoring it is much higher than the cost of your “flow state.”
The Developer’s Unfair Advantage
As a developer, you actually have many advantages compared to other roles in IT such as DevOps, Architects, or SREs.
Of course every role has its strengths, but for me, being a developer is one of the most interesting roles.
When I’m a developer:
I can work with almost every other team. Nearly every request eventually goes through the dev team, haha. Developers are both the center and a kind of relay station for technical and business requests.
I get to understand both the business side and the IT system that supports that business. In many ways, developers see everything from A to Z. When something goes wrong, a dev can often start debugging before even escalating the issue to other teams.
Switching roles becomes easier. If one day I get bored of development, I can explore DevOps, Architects, or SREs more easily. Once you have strong technical foundations, learning new areas becomes less intimidating.
On the other hand, moving from those roles into development can be a bit harder (not impossible). But I would bet that the time and effort needed for someone to transition into a dev role is usually greater than the other way around.
My Personal "Code" for Growth
To keep my “simple” mindset sharp, I try to follow these four principles:
Understand the business as much as possible.
You learn it by asking people, by developing new features, and by fixing bugs. Over time your understanding of the business grows. Once you understand the business, the way you see problems and solve them becomes much better.
You no longer need to ask people too often, which saves time. And when you master the business context, you can fix issues without constantly worrying about unexpected side effects somewhere else. Things are under control.
Don’t be afraid of having a lot of work.
What matters is organizing it well and understanding the priority and workload. The more you do, the more you learn. The only way to avoid mistakes is to do nothing.
Every task gives you something in return. The harder the task, the more value you gain after finishing it—and the faster your skills improve.
Share your knowledge and experience with others.
This is extremely effective. Every time I explain something, it’s like reading and memorizing it one more time. I also need to find a way to make others understand it. At the same time, it reduces my workload so I can focus on more difficult tasks.
Sometimes, when explaining things to colleagues, I even realize gaps in my own understanding.
Don’t be afraid to try, and don’t be afraid to make mistakes (small ones, of course).
Those moments make you remember lessons much more clearly than when everything works perfectly the first time.
Conclusion
Personal growth doesn’t happen overnight. It only comes from steady accumulation: learning with curiosity, working hard, and constantly improving so we don’t fall behind.
Maybe not everything I think is correct.
But if this way of thinking helps me improve a little bit every day, that’s already enough for me.
(If you enjoy these kinds of engineering stories, you can subscribe to receive the next ones.)