Sometimes the most obvious, trivial things end up being the ones that truly make a difference in your day-to-day.
For years, I worked in setups where I was mostly the sole developer on a project. Sure, there were other stakeholders (designers, PMs, clients) but essentially, the codebase was my baby. I’d get the specs, build the thing, deliver the result. That was it.
This setup taught me to care deeply about the final details. The interface, the animations, the polish: that’s what people judged me on. When you deliver a website or an app to a client, they don’t see your clean architecture or clever abstractions. They see the result. If it looks and feels good, you’ve succeeded.
After a while, you learn what people look for. Designers focus on spacing, typography, alignment. Clients on branding, assets, content. You adapt to those patterns, minimise feedback, and move fast to the next project.
The problem is, that’s not real growth.
When you optimise to avoid feedback, you also avoid improvement. You stop being challenged. You never get exposed to better ideas, new approaches, or the subtle blind spots in your work. The fewer comments you get, the more you stagnate.Even if you think you’re doing great.
It took a job change for me to realise this. In my new environment, where development is taken seriously and every PR is reviewed by multiple people, I suddenly felt exposed. Every comment on my code felt personal. Every suggestion felt like an attack. But it wasn’t, it was feedback. Constructive, respectful, useful feedback.
It took some humility and reflection to see that I wasn’t actually good at taking feedback. I was just rarely getting any.
Then came the next realisation: I wasn’t good at giving feedback either. I’d always seen myself as the junior in the room, the one who should absorb, not advise. So even when I had thoughts or ideas that could have improved something, I’d keep them to myself.
But giving feedback is just as important as receiving it. It forces you to look critically, to analyse decisions, to articulate why something works or doesn’t. It’s a form of respect for your teammates, your craft, and the product you’re building together. Staying silent when you could help is its own kind of negligence.
Of course, not all feedback is good feedback. It needs thought, context, and empathy. No one benefits from noise or nitpicking. Finding the right balance takes time. I’m still learning. I still hesitate more than I should.
But I’m starting to see this as part of a larger process: growing not just as a developer, but as a person. Learning to give and take feedback gracefully isn’t easy. It’s uncomfortable, sometimes even painful. But it’s also the only way forward.
Growth doesn’t happen in silence.