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.)

Subscribe now

I spend a lot of time reading technical blogs, learning from people who share their experience, their thinking, and their knowledge. Honestly, I feel grateful to those who do it. Some resources are completely free, others are paid, but the value they bring has helped me a lot.

Things I’ve Experienced

I’ve worked on several projects and with many colleagues—some with little experience, some very experienced, and sometimes even real superstars.

On some projects, certain business logic existed only in the heads of a few people. Whenever something happened, we had to message them: “Is this correct?”, “Should it work like this?”

Sometimes we finished coding something only to realize later that it didn’t match the business requirements at all, so we had to redo everything from the beginning.

Time passed, the team changed many times, but the bottleneck stayed there—because no one else could replace those people.

And this doesn’t even touch deeper business logic yet. In almost every organization’s IT system, there are always some “tips” or knowledge that only a few people know.

Something simple like:

• logs inside a pipeline

• how the cloud architecture is organized

• how to debug through monitoring systems

Whenever something goes wrong, the team has to ask the person responsible for that system.

Asking once or twice is fine.

But asking the same question many times clearly means the team has a problem.

The Obvious Consequences

The first consequence is a huge waste of time.

Imagine asking someone for help. You send a message, explain the issue, go back and forth discussing it, and wait for them to solve the problem.

That’s the ideal case.

I once created a ticket to debug a bug… and then silence.
Maybe the person responsible was on vacation. 😄 (Sorry, time for holiday.)

The second issue is team dependency on one person or a small group of specialists.

If those people are still around, it’s fine. But if they go on vacation—or worse, leave the company—then suddenly the company is in a hurry to find someone else and transfer knowledge.

But how can someone explain everything they’ve learned over many years?

Often the person receiving the handover is new and doesn’t even fully understand the system yet—let alone the important knowledge that exists only in someone’s head.

Another consequence is that people in the team cannot grow together and don’t feel a sense of achievement.

Yesterday I had a conversation with a close friend. He said something very interesting:

Only when people feel a sense of achievement will they try harder.
When they feel they’ve lost their value, they will start doing things carelessly.

I think that sentence is very true.

Growing together is also a way to share work and responsibility, instead of letting everything depend on a single person.

The Mindset I Realized

Share knowledge and experience with others

I was once a junior developer who benefited from the experience shared by many people.

So why, when I finally gain knowledge, would I not share it with people who have less experience?

Sharing knowledge doesn’t make me weaker or less competitive.
Actually, it’s the opposite.

It helps others gain skills, and it also reinforces my own understanding.

Sometimes while explaining something to others, I suddenly realize that my own understanding still has gaps.

Whether you are experienced or not, try sharing something with someone else—you might be surprised by the result.

Never stop learning

Whether you are a fresh graduate or a senior engineer, you should keep the mindset of learning and improving.

Personally, I always keep one thought in my mind:

I am nothing.

This isn’t about being pessimistic or putting myself down. It’s simply reality.

Sometimes I think I understand something well, but the deeper I dig, the more confusing it becomes. (For example, learning Kubernetes 😅).

There will always be someone better than me.

Maybe I’m good in one area, but in many other areas I’m still at zero.

Try solving the problem before asking others

This habit has helped me a lot.

When a problem occurs (like a bug), instead of quickly reading logs and asking the system owner or a more experienced person, I try to investigate the root cause first.

I explore everything I can access and control, and try to solve the problem myself.

I only ask others when:

• I don’t have enough information

• or the issue is urgent and debugging is taking too long

Once I receive the answer, I remember it so I don’t ask the same question again and waste both of our time.

Stay curious

Whenever the company gives me access to something, I’m always curious to explore what’s inside.

That way, when something breaks, I can quickly find where to look.

A simple example: when joining a project, the source code is what I interact with the most. Sometimes if someone asks which class contains a specific method, I still remember it—and roughly what it does.

I don’t need to know every detail.
Just knowing where it is and what its role is already makes debugging much easier.

Another example: when I was given read-only access to our company’s AWS development environment, I explored what services were running and how much the company was paying for each service every month.

These small curiosities accumulate over time.

Sooner or later, everything feels like it’s in the palm of your hand. When a problem happens, you can quickly identify where it comes from instead of guessing and wasting time debugging.

What Should We Do?

People often say we should write documentation for projects.

That’s true.

But if documentation is written carelessly, it can become a disaster—wasting time and creating confusion.

Hopefully, as AI improves, writing project documentation will become easier.

During daily work, teams should gradually share business logic so everyone understands it. Work becomes much more effective when knowledge isn’t locked inside one person’s head.

Teams should also organize regular sharing sessions:

• business logic

• technical topics

• or anything useful

Experienced people share with newer team members.

That’s how work and responsibility can gradually be shared among the team.

One brain can never compete with many brains working together. Sometimes other people can even spot mistakes you didn’t notice.

Everyone should also try to think deeply about their own tasks. This improves both skills and thinking ability.

And regularly learn from outside sources—blogs, discussions, or even AI.

Conclusion

Keeping knowledge to yourself will not make you richer.

But sharing knowledge with others will definitely make your life easier.

Haha.

That’s right.

(If you enjoy these kinds of engineering stories, you can subscribe to receive the next ones.)

Subscribe now

Calm Before the Storm

When I first joined, I spent my days getting familiar with the systems, my new colleagues, and the culture.

In “real life,” I’m actually quite an introverted person. But at work? Not really 😄. Whenever I don’t understand something, I ask immediately. I refuse to let myself stay blocked.

Luckily, within a month, I felt well-integrated with the team. That’s exactly when the high-stakes tasks I’d been promised during recruitment started to land on my plate.

What Did the System Look Like at That Time?

At that time, the backend system was a collection of about 10 small microservices written in Spring Boot.

• Communication: We used RabbitMQ to pass events between services.

• Deployment: Everything was dockerized and deployed together using AWS Elastic Beanstalk.

• The Pain Point: Every single deployment caused about 4–5 minutes of downtime.

Because of that gap, we were stuck deploying only during low-traffic periods—unless there was an urgent hotfix that couldn’t wait.

The Mission

The boss handed me a specific challenge:

“With your AWS experience, find a way to deploy services individually without interrupting the system. Use Kubernetes if you have to.”

For a seasoned DevOps engineer, this might sound like a Tuesday. For me? It was daunting. My background was primarily in backend development; my DevOps experience was limited to small personal projects, never a living production system.

What was in my toolkit?

1. An AWS Certified Solutions Architect – Associate certificate.

2. A lot of time spent on tech blogs and YouTube.

3. ...That’s about it.

I want to give a huge shout-out to Viet Tran for his AWS tutorials and Nguyen Van Manh for his DevOps insights. One specific mindset from Manh’s talks stuck with me:

Don’t make things complicated.
A pipeline only has two important stages: build and deploy.
Everything else is secondary.

The AWS explanations and advice from Viet Tran also helped me understand which services to choose and how to approach the problem.

The Great Deployment Debate

Now I was standing in front of three options for deploying Docker containers on Amazon Web Services:

• Amazon EKS

• Amazon ECS

• Amazon EC2

EC2

I quickly rejected this option.

Using EC2 with docker-compose or docker-swarm would require a lot of effort to deploy and maintain.

Maybe it could be the cheapest option, but for someone with limited DevOps experience like me, it felt risky.

Actually, the existing Beanstalk deployment was already similar to this model.
Beanstalk created ECS clusters and deployed services on EC2 instances.

EKS

Even though I had no Kubernetes experience, I believe I could learn it if I had enough time.

After all, AWS already manages the hardest parts.

Using EKS would also look great on my CV and allow me to explore Kubernetes more deeply.

But this was clearly a trade-off.

If you only have a small number of services, using EKS can feel like using a huge knife just to kill a fly.

It’s powerful, but maybe too complex.

Managing Kubernetes properly also requires someone with solid experience. Otherwise, you might spend all day debugging infrastructure issues.

And the cost isn’t small either.

Even if you do nothing, maintaining a cluster already costs around $100 per month 😄

ECS Fargate

In the end, I chose AWS Fargate with ECS.

It’s an AWS-native service and already provides everything I needed:

• Load balancer

• Auto scaling

• Rolling updates & Blue-green deployments

It’s lightweight and serverless.

Basically, I let AWS handle most of the infrastructure and focus on developing the application instead 😄

The cost was reasonable and the service was very beginner-friendly.

It took about three weeks to bring the system to production. There were adjustments along the way, of course, but the integration was smooth.

Today

Today, that ECS infrastructure is still running perfectly. I’m convinced it was the right call.

Sometimes, being a good engineer isn't about choosing the most "powerful" or "trendy" technology; it’s about choosing what fits the situation best.

I still wonder what would have happened if I’d gone the EKS route. Maybe it would have worked fine—but I have a feeling every time I looked at the AWS bill, I’d get a little bit of a heart attack 😄.

(If you enjoy these kinds of engineering stories, you can subscribe to receive the next ones.)

Subscribe now

But a few months before that, I had already started thinking about finding another job instead of staying where I was.

The decision happened quite quickly. I prepared my CV and started applying to job posts on LinkedIn.

After a little more than one month and a few interviews, I found a new company.

Behind this quick decision was actually a trade-off:
being willing to step out of my comfort zone.

The Old Company Was Completely Fine

At my previous company, everything wasn’t just fine — it was very good.

My manager and colleagues appreciated me, and I also felt that I was bringing real value to the company.

I had worked there for more than three years. I knew the projects very well, almost every line of code felt familiar, and the technologies we used were modern.

The salary was good, and there were yearly bonuses.

Overall, there was nothing to complain about regarding the working environment or the company culture.

One Small Problem…

The only issue for me was this:

The company was a subsidiary of a large corporation, and all compliance rules were decided at the group level.

I understand that when an organization becomes very large, clear processes are necessary to keep things running smoothly.

So the organization was divided into many specialized teams, each responsible for a specific area.

My role was simply developer.

That meant my job was to build features and push the code to git.

After that, I just waited for the pipeline to deploy to staging or production.

If something went wrong, I had to send a message to another team so they could debug it.

Even a small feature required creating a ticket and getting approval from another team before deploying to production.

What Started to Frustrate Me

Because of this process, many things felt slow.

Whenever there was a problem, I had to ask another team to help. I couldn’t touch anything except the code.

It made me feel a bit restricted.

Sometimes a very small change could take a whole week before reaching production.

Another issue was learning.

Outside of coding, I also wanted to understand:

• infrastructure

• databases

• cloud systems

• monitoring

But if I was always asking someone else to debug things, and never doing it myself, I felt that I would never really understand those areas deeply.

What Did I Actually Have at That Time?

To be honest, not that much.

I had experience as a full-stack developer:

• Java with Spring Boot

• JavaScript with React

And I had the AWS Certified Solutions Architect – Associate certification.

I studied and prepared for that exam on my own and managed to pass it.

Honestly, I should also thank that certification — because it helped me realize how little I actually knew 😄

What Did the New Company Offer?

Interestingly, the technology stack was almost exactly the same as my old company.

The main difference was that they were building their system with microservices, something I had never worked with before.

The new company also needed someone with AWS experience to help modernize their infrastructure.

That sounded exactly like what I was looking for.

Since it was a startup, I knew I would have the opportunity to touch many parts of the system and learn much more.

Stepping Out of My Comfort Zone

In the end, I decided to leave my old company.

I wanted to step out of my comfort zone and challenge myself.

I wanted to improve, learn more things, and understand systems beyond just writing code.

At my new company, I always try to work with a learning mindset.

Technology moves very fast, and I hope I don’t fall too far behind.

Conclusion

So far, everything has been going well.

Hopefully it will continue that way in the future 😉

(If you enjoy these kinds of engineering stories, you can subscribe to receive the next ones.)

Subscribe now