I don’t know about everyone else, but I’m someone who really enjoys sharing knowledge—and also listening to others share theirs.
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.)