I started a career in programming because I enjoyed spending countless hours on my computer, whether I was gaming or browsing the web. Every time I wondered how a game worked or how a webpage could display information so quickly, I was fascinated. To find answers to my questions, I started learning about programming.
My first experience with programming was through a book about Java that a friend gave me. With some help, I learned the basics and created simple apps just for learning purposes. However, my first real opportunity came from another friend, and I will always be grateful and indebted to them for that chance—an internship in .NET. This is how my programming “career” started, along with my love for .NET and the entire Microsoft environment. It came with many challenges, but without challenges, programming would be boring.
The first project I worked on was a car rental desktop application. It was hard to build without much documentation, but my boss helped me understand what I needed to do and, more importantly, how to do it. I want to thank him—without him and this opportunity, I would never have become a programmer.
To prove that I was a good choice for my employer—and to prove to myself that I could turn this opportunity into something meaningful—I gave it everything I had, learning as much as possible and contributing wherever I could. After the internship, I was hired by the company and started working on real production applications. Since it was a small company, the workload was heavy, but I didn’t mind—I loved what I was doing. In my opinion, this was beneficial because programming was my dream job, and I was eager to grow my skills and expand my knowledge.
After two years, I was put in charge of a client with multiple projects in the same business. I was part of a team of three, working alongside two student colleagues. My responsibilities grew to include helping them understand the business and guiding them. At that time, I didn’t fully understand what it meant to be a “mentor”—it was a big word, and I didn’t know how to mentor someone.
Helping them was a real challenge. I didn’t know how to start, how to help them learn faster, or how to make them better. In reality, I was afraid they could become better than me. Now I understand that this was a mistake—the true mark of success is when your apprentice becomes better than you.
In my mind, I was an excellent developer, and my code was flawless. In reality, I was just a fool. Perfection doesn’t exist in programming. You can be a good developer, even an excellent one, but never the best. Keep your feet on the ground. You are not the best, and you will never be the best. At most, you can be a key player in your company, but you must also be part of a team. Having an “I am the king of the world” mentality will not lead to anything good.
Sometime later, I had a new colleague who was a better programmer than me—he knew more design patterns and had a deeper understanding of distributed architecture. He was an excellent developer. When he joined the team, I felt both happy and envious at the same time. But deep down, I felt betrayed. I convinced myself that everything he did was better than what I did. His work was praised, and while the recognition was well-deserved, I felt that his contributions were slightly overrated. This only fueled my resentment.
Eventually, I decided to leave the company, but it wasn’t a pleasant departure, and I don’t want to go into details about that. What I do want to talk about is the real problem—because it wasn’t my colleague, and it wasn’t my boss. The problem was me. I didn’t know how to handle the truth. Another issue was my perspective on work. At that point, I took my job very personally. From a company’s perspective, however, clients and business growth are the priorities. Back then, I was too focused on trying to prove I was the best, when what really mattered were the projects and the team. I realize now that I was being selfish, and I regret the way I handled things.
Many developers today strive to be the MVP, believing they know everything and avoiding team communication, refusing to accept that they might be wrong. However, taking this approach can be detrimental—not only to yourself but also to your employer. What I’ve learned in my eight years of experience is that you must listen to your colleagues. Working in a team means being part of an engine—if you work alone, you risk breaking that engine. Being a team player is difficult, but it’s possible. When I finally realized that the problem was with me and not with the universe, my perspective on work changed. This shift didn’t diminish my abilities or make me less competent—on the contrary, it made me better.
I know that listening to others is hard. But try it. It will make you a better developer.