With over 15 years of experience in software development, I’ve worked across various domains—everything from backend and infrastructure to frontend, mobile, and IoT. I’ve seen the industry evolve, and I’ve been part of projects that have stood the test of time. In fact, the very first project I worked on is still alive and running with the same backend and frontend we built 14 years ago, with absolutely minimal updates since its launch.
Throughout my career, I’ve learned that success in software engineering isn’t just about technical skills. It’s about the lessons you pick up along the way—many of which have nothing to do with code.
Your attitude and your willingness to continuously grow will set you apart. The most valuable insights always come from experience.
Let’s go over the software engineer career advice I’d like to share with you based on everything I’ve learned. Today, as a senior developer, these experiences shaped my career.
Advice 1: What users think matters
In software development, it's easy to get lost in the technical side of things—clean code, efficient algorithms, and scalable architectures. But something that’s just as important, often overlooked, is the user’s perspective. When you're deep in a project, you might assume that the domain doesn't matter as much, especially if it's something you're not personally invested in. But what you’re passionate about might not always align with the end-user’s passion, and that’s something developers must keep in mind.
Take the example of a food recipe site I worked on. The technology behind it was incredibly advanced for its time, a developer’s playground, really. We had image processing for search by color, multi-resolution photo storage, and even the ability to generate and print custom cookbooks. But for most of the users—many of them women from an older generation—it wasn’t the tech they cared about. They were there for the recipes, the community, and the recognition they earned. They shared their decades-old family recipes, took pride in their awards, and even invested in DSLR cameras just to upload professional-quality images of their dishes.
These users were so passionate about the recipes that when two of them accused each other of recipe theft, it escalated to the point of threats—serious enough that we had to pull their message logs at the request of the police. For them, this wasn't just a hobby; it was a deeply personal endeavor, and they saw their contributions as part of their identity.
This experience taught me a valuable lesson
Even if the technology is impressive, it’s not what makes or breaks a product for the users. It’s the emotional connection, the community, and how well the software serves their needs that matters most. It may seem trivial to you as a developer, but to the user, it can be everything. So always remember—the user’s opinion isn’t just important, it can be the defining factor between success and failure.
Advice 2: A bad client doesn't mean a bad project
Every software developer has likely encountered a “client from hell”—one who makes your life difficult with unrealistic demands, lack of trust, or constant second-guessing of your work. But just because a client is difficult doesn’t mean the project can’t be a rewarding experience.
A few years ago, my team and I faced one of these nightmare clients. Calls were an endless cycle of explaining every little detail, only for them to bring in unqualified contractors who botched basic tasks. The client’s expectations constantly shifted, and getting paid without a fight? Forget it. We were tempted to throw in the towel more than once.
But there was something about the project that kept us going—it was complex, challenging, and offered an opportunity for growth. We dealt with 5 repositories, a mix of frontend and four microservices, Dockerized environments, Postgres, and ElasticSearch. Not to mention, we had to figure out how to deploy this into a banking intranet, totally isolated from the internet, while maintaining data collection services. This pushed us out of our comfort zones for 6-7 months straight, constantly forcing us to find creative solutions.
Then came the blow. An email from my boss: “Stop all work. The client says we’ve caused damages with unmaintainable code and copy-pasting.” They sent over a 10+ page report, put together by one of their contractors, accusing us of incompetence. Morale hit rock bottom. But instead of giving up, we decided to fight back, and it was one of the most satisfying moments of my career. We ran our code through six different software analysis tools—and every one of them returned excellent scores. We meticulously countered every argument in that document and came out with our heads held high.
Growth comes outside your comfort zone
The truth is, a bad client doesn’t define a project. In fact, the difficulties we faced brought our team closer and pushed us to learn new tools and strategies we wouldn’t have explored otherwise. The experience also showed me that growth often comes from the least expected places—outside your comfort zone when everything seems to be falling apart.
So, while you may not enjoy dealing with certain clients, remember that the project itself might still be an incredible learning experience. The difficult clients will come and go, but the lessons you learn from these situations will stay with you forever.
Advice 3: Keep an open mind: You might not always have (or need) the full context
As developers, we often like to have a complete understanding of a project before diving in. But sometimes, you won’t have all the context—and that’s okay. In fact, it might even lead to some unexpected learning opportunities.
I remember one project where my initial reaction was, “This is too simple for me—can’t they give it to a junior developer?” The task seemed basic: build three API endpoints for user registration and login and two more for tracking users' locations every minute. On the surface, it looked like a straightforward project for a mobile app with about 30,000 users. “I’ll have this wrapped up in a week,” I thought.
But once I started to dig deeper, I realized just how wrong I was. Tracking 30,000 users every minute meant handling 500 requests per second—this was going to require some serious scaling, load balancing, and database optimizations. Suddenly, a “simple” task turned into a seven-week project that stretched my abilities. I had to learn about read/write database separation, performance tuning, and scaling systems in real time. It was a crash course in performance optimization that I wasn’t expecting but desperately needed.
In the end, the project wasn’t just about building a few endpoints—it was part of a larger research effort. We sent the database dump to Cambridge University for analysis, and a few months later, I found out that the project had been part of the BBC Pandemic initiative. They were simulating how a virus might spread in a rural area of 30,000 people, using one individual as Patient Zero to model transmission over time. The project even won an award for best medical research in 2018!
What did I learn?
Had I dismissed the project initially, I would have missed out on the opportunity to work on something impactful and to push my technical skills in unexpected ways.
The lesson here is that you won’t always have the full picture, and sometimes the most unassuming projects can be the ones that teach you the most. Keep an open mind, embrace the unknown, and take every project as a chance to learn something new.
To get more awesome advice on the importance of security and how attitude can help you in engineering, check out our blog.
Top comments (0)