Not a career guide and not a roadmap. This is simply me looking back.
“The real value is not in the product. It is in the person you become in order to make it.”
The first time I touched code was near the end of eleventh grade. My father had
bought me a used laptop, brought back by hand, to get me ready for the entrance
exams and the university years ahead (I suppose he was certain I would pass). At
first I had no idea what to do with it. I only had one question: how does anyone
make something out of nothing? What I mean is, how does anyone build a world of
their own, the way a game is a world? We had a computing class at school and I
think I had some aptitude for it. They taught us Pascal, how to program the
solution to a quadratic equation, and I kept wondering how lines like these
could
ever add up to a world. So I started learning to code through online courses,
web
first, then Android, and at some point I even published an app to Google Play.
For most of my final year of high school, outside of class, nearly all my time
went into code, even though back then it was only a hobby.
At the end of that year I decided to sit the exam for something software related, Information Technology or Software Engineering. I got into Information Technology at Ho Chi Minh City University of Technology and Education (HCMUTE). It was not because the field was fashionable. It was because teaching myself no longer felt like enough. I wanted to make something of my own, a world of my own, an empire of my own. That is what the dreaming of youth told me.
I started working in my third year of university, the milestone where I stepped
into adult life by choosing software as the thing I would pursue professionally,
which sounds a bit like sport when I say it out loud. I began as a mobile
developer working in Flutter. Very few people in Vietnam were doing Flutter
then. React Native was the preferred option and Flutter was a newly rising name.
I chose Flutter for a simple reason: it was easier to install than React Native.
At that first job I worked directly with a tech lead who became my model for what this work could be. Working alongside him, I had the feeling that he was a craftsman rather than a person who wrote code. His code was careful, meticulous, and extensible, and I want to lean on that word "extensible", because for someone who had only ever coded alone, on instinct, extensibility was a foreign property, and school did not teach much about it either. His code felt like it could stand for years (two or three, easily) without a line needing to change, no matter how the business plan or the product shifted underneath it. Perhaps he could see through time and prepare for what was coming. He worked the way a sculptor works, attentive and absolutely focused on the piece in front of him, which is what Richard Sennett[02] means in The Craftsman (2008): "The desire to do a job well for its own sake." He was a large source of inspiration for me, and I began to care about making a good product the way a craftsman would, patiently, diligently, with attention. Looking back, that was a good and unusually rich stretch of time for growing that instinct, mostly because the company was small and there was not much of a race to run.
It was also at this company that I ran into the first ugly thing, and it came from me. I was terrible at working in a team, and much worse at communicating than I had believed. I could not state my own thinking or my own solution clearly. I could not clarify a requirement. I hated having my code reviewed. I wanted to go back to working alone. I knew, of course, that nobody builds anything large by themselves in this profession, and probably in any profession, so I decided to fix it. I learned to speak more clearly and more precisely. I learned to see code review differently, not as fault-finding but as a way of raising the standard of the whole team. Slowly it got easier. It was not the work of a single morning, but once you agree to take the first step, sooner or later you arrive.
After that I moved to my next company, and there I learned a fair number of other important things. It was an outsourcing shop, also small but a little larger than the first, and there I worked directly with clients across the whole cycle: requirements, implementation, validation, operations, and the rest. That was lucky. I also led a few projects there, despite being the youngest person in the company at the time.
What I understood there is that working with clients and operating in production is a challenge of a completely different kind from staying inside R&D. The weight on your shoulders is far heavier, because you are facing the client and at the same time protecting the interests of the colleagues standing behind you. There I learned how to divide work up, or rather, how to decompose it first, which is the correct order. I learned when to ask for more people and when not to, when to accept a missed deadline and take the shouting instead of burning everyone out with overtime to make a date. The Mythical Man Month[01] was one of the books that helped me most during that period, and I would suggest it to anyone about to lead (or already leading). A lot has changed, especially at the speed the industry moves now, but the core principles have barely moved at all.
At this second company I also found another good thing, another kind of joy in software: the smile on a customer's face. Honestly, from eleventh grade until the moment I noticed this, everything I did in this field came from a personal ego that said "I want to build something wonderful of my own", not "I want to make something wonderful for the world" or help anyone in particular. On a project building an application to manage hospital beds and shift schedules, I got to work directly with nurses, orderlies, and hospital administrators, and to hear their feedback firsthand. They told us the application had made their daily work a little lighter, that they no longer lost as much time as before and could spend what was left on themselves, resting a little, and that it made them happy. What I felt hearing that was a kind of floating gladness: making something good is also doing something good, and it can help people like that. From that moment on, alongside the personal ego, the customer's smile became one of the things I built toward. Can this product make them smile? Can it make their life a little better?
But knowing the customer's smile is also a curse, and I think it will haunt anyone who wants to build something meaningful, who wants to see their own effort actually reach a person and change something for them. It haunts because it is genuinely rare in this line of work. The numbers that track user and customer experience rarely make it back to the people who built the thing with their own hands, the R&D team, the developers. Whoever is haunted by it ends up stuck in an endless loop between "I want to make something meaningful" and "is it actually meaningful". This is the next ugly thing I think developers should watch for. Handle it carefully.
I learned plenty of other things at this second company, in code and outside of it. I stopped focusing on patterns and started focusing on principles, on what things actually are. I learned that the skills that are not code are also essential skills in software: communication, expectation management, responsibility toward the client and the user. Many nights spent awake debugging, working through production incidents with colleagues, taught me about technical debt and about the experience of the developer. My standard for code moved from ready to production-grade. That stretch is a large part of how I became the person I am now.
After nearly three years at the second company I resigned and moved to the third, this time a large multinational software company working in security. It was a particular kind of journey, because even before I joined it had already taught me something: people only see you through what you show them, so show them plenty. I do not mean showing off. I mean showing everything you are actually capable of. Be confident. Prepare so thoroughly that you almost cannot be wrong.
There I worked inside a large system and everything was different. The clients
were large, well-known enterprises, and naturally their demands were high. Small
clients prize versatility, creativity, and speed. Large clients prize durability
and stability above all else. Terms like SLA and SLO had to be honoured more
closely than ever. Working inside a large system is intellectually stimulating
in
a way I genuinely enjoy.
New good things arrive with new ugly ones. In a large system, "process" is always a barrier to the "speed" that software wants, and coordination between teams and departments always meets friction. The hardest part is office politics. I do not hate it, it is inevitable in any large organisation, but I was drained by how much room it took up inside decisions. There I learned another important lesson: focus on the things that actually matter. And have the courage to do it. Why courage? Because in a typical large company every activity has to be tied to profit, and the things that matter usually take a long time to produce any. Managing conflict, delegating, and training team members are the other skills you need in that environment.
Across seven years in this profession as a professional developer, and more than ten since the first line of code, the number of beautiful things this work has given me is not small.
Programming satisfies something in me. I want to understand everything, I want to try making everything there is, and programming gives me that feeling. It gives me the sense that I can make something new out of nothing, that I can take an idea in my head and give it a body in the world. And sometimes there is even a bit of magic in it, the kind that pulls a "wow" out of a user.
Programming pays well relative to most fields, and I think I joined during the golden age of it, so the economic upside has been real. I have been able to support myself since my first days of work, and to help my family a little as well.
Technology and software require you to keep learning and keep sharpening. There is no such thing as "that is enough". Something new is always being born and you always have to learn it. That keeps me moving forward. It is motivation and pressure at the same time. In this profession it is not an exaggeration to say that standing still is walking backward. Although honestly, in the modern world, every profession is like this. Knowledge keeps being made.
These are the bad things I have felt in this profession so far. Calling them bad does not mean they are evil. It means that for me they drain energy faster and more heavily than ordinary things do.
People are on this list not because people are bad. What I mean is that solving problems that involve people is always harder than solving problems that involve systems. With a system you can prepare, you can have a fallback, you have metrics to measure and logs to read. With a person you have none of that. You do not know what they are thinking, and each person is a distinct individual who has to be handled differently. Some are highly skilled with an ego too large to fit in the room. Some are ordinary in skill but are the emotional heart of the team. Some speak beautifully and do little, and some speak little and do a great deal. Learn not to judge by appearance. Observe, check a little, be warm but keep some distance, and above all hold your own boundaries well.
Technology companies are permanently obsessed with speed. It seems to be a tradition of the field: build fast, release fast, keep the lead time short. You have to get used to it, and yes, the pressure that comes with it is a given.
Your working environment has an enormous effect on you. A good one can make you feel you would give everything to this company. A bad one drains you, and every working day feels like hell on earth. If you ask me how to tell a good environment from a bad one, the best answer I have is to feel it out. If you go to work and feel light, comfortable, in decent spirits, it is probably a good environment. If not, it is a bad one. There is good news and bad news here: no environment stays good or bad forever. And when it no longer fits, leave as quickly as you can.
I list these as the ugly because of how they act on me. What I mean is that these are not external things. They are inside the body and the mind.
The longer you work, the more health becomes the thing you have to watch in this profession, because of the unbroken mental pressure, sitting in one place, moving very little. Your condition degrades. It will not collapse suddenly, it goes slowly and quietly. Back pain, high blood lipids, stress. Take better care of yourself. A good chair and regular exercise will help a great deal if you are going to stay in this field.
People tend to think burnout is something caused by working too much, by too much stress. I do not think so. Burnout shows up when you cannot see any meaning in what you do every day. It is a symptom of the curse of the customer's smile I described above. Plenty of work can cause stress, and stress deserves attention too, but burnout comes from somewhere deeper. If you suddenly feel that every meaning you were chasing has vanished, if you feel hollow, you are probably burning out, and believe me, you need a real stretch of rest to look again at where you are going. Beyond physical health, mental health is the thing this profession has attacked in me the most.
Well, only because I still like it. That is all. I still want to make something. I still want to feel the customer's smile. I still want my mind stimulated by hard problems.
I have been in this field long enough, and it has given me plenty of chances to grow, to get better, and to earn a living as well. Maybe one day I will work in another field, but software and technology will always be part of my life and my work.
If I could meet myself at twenty, taking the first professional steps on this road, I would tell that younger version a few things.
There is a great deal more, but on the road of work and in life the lessons arrive at the right time on their own. Go and live them yourself.