Reflections: Things I Learned
There’s a lot about being an engineer that you only learn by doing. This blog is a list of few things that have stayed with me.
There is a lot about being an engineer that you only learn by doing. This blog is a list of few things that have stayed with me, surprised me, and changed the way I think.
Picking the right trade-off is everything
Most decisions will not have a right answer; rather, they will consist of a set of good tradeoffs.
Some days you will be juggling between increasing a metric vs keeping the website up. Some days debating about tech debt vs moving fast. And some days on increasing reliability or building a new feature. In conversations like this is where you grow.
As engineers, we often find ourselves craving technical correctness. But in reality, it's all about judgement, knowing which corners you can and cannot cut.
Trade-offs are not a sign of failure. They are a core part of the work. The earlier you get comfortable making them, and owning them, the more effective you become.
Code is the easy part
When you are first starting out, coding can feel like the entire job. Commits and pull requests are the most visible features.
But, over time, I realised that the real challenges were elsewhere: talking to a frustrated user, owning a broken system during an outage, and unblocking a teammate who is waiting for you.
Writing code is simple (not always); the logic either works or doesn't. But engineering is far more than that. It's about how you deal with pressure, responsibility, and communication.
You don’t need to have an answer always
There is sometimes a hidden pressure we put on ourselves to always know what to do. To have a clean solution, a clear plan, and a quick fix.
However, sometimes the best solution is to say, "I'm not sure yet, but I will figure it out."
It's easy to think that expertise means having all the answers. However, in practice, it often involves asking better questions, remaining calm in a moment of uncertainty, asking help when needed, and trusting that you will learn your way through it.
Consistency is all that matters. Showing up daily, even when things are unclear or fuzzy is sometimes all that is needed.
The emotional side is real
No one tells you how emotional this journey can be. The uncertainty after a failed project. The happiness in a clean release. The joy of seeing someone use what you built. The challenge when things break. The gratitude when a teammate steps in to help. The little wins that mean everything to you.
What surprised me the most was how deeply personal this work is. Sure, it is code. It’s systems. But it’s also people. It’s identity. It’s the constant, quiet process of figuring out what kind of engineer and person you want to be.
It’s easy to think engineering is purely rational. But the truth is, most of us care a lot and that’s what makes the work meaningful.
Growth isn’t always obvious
As engineers, we are obsessed with numbers. Doing X increases it by Y. However, growth will not always feel like this.
Growth isn't always obvious. It occurs when no one is watching. It appears later, when you realise you handled a situation better than you would have a year ago. When you believe you handled a difficult situation better, approached a problem differently, or collaborated more effectively.
Not every day will be a drum roll, but if you show up and strive to be 1% better, that is progress.
Writing is a superpower
For years, I have made it a habit to write down my thoughts whenever I am faced with a difficult decision or problem. Not for anyone else, only for me.
At first, it was just a way to clear my head. But over time, I realized it was more than that. Writing helped me notice patterns. It helped me go back to the old decisions with a fresh perspective. Sometimes it even helped me avoid making the same mistake twice.
We often think clarity comes from more data. But clarity also comes from thinking slowly.
Product building is hard (And that’s the fun part)
No matter how good the architecture is or how clean the codebase looks, if you are building a product, you are stepping into a world of ambiguity. Requirements will change as the product matures. Priorities will shift as demand changes. Users will not always use it the way you expect.
Product building is an iterative process. You try something, ship it, observe, learn, collect feedback and iterate. Sometimes you're figuring out the right problem rather than the right solution.
What’s hard and also incredibly rewarding is becoming comfortable with the chaos. Learning to ask why before jumping to how. Developing the instinct to question: Is this the right thing to build? before thinking How fast can I ship this?
Over time, I have realized that engineering is not just a function for product, it is product. Every abstraction, every error message, every retry mechanism is part of the user experience.
At the end of the day, it’s not about being perfect. It’s about being patient, constantly learning, staying curious, and enjoying the work along the way.
What are something’s you have learned in your own journey?