What 16 years of software engineering taught me about growth

Key takeaways:

• Technical excellence alone doesn’t make great engineers: writing, community, experimentation, and managing imposter syndrome compound just as much as code quality.
• Document for your future self, not just your team. The engineers who write things down move significantly faster than the ones who don’t.
• Imposter syndrome never disappears, your relationship with it does.

---

“Learning is not compulsory… neither is survival,”  said American business theorist W. Edwards Deming.

Over the last 16 years, I have worked across three very different worlds of software engineering. These span IT service-based companies in India churning out client projects, product companies in North America obsessing over user metrics, and the chaos of building my own startup after leaving a full-time job.

Each experience taught me something different about what it actually means to grow as an engineer.  The clearest lesson across all three was this: technical excellence alone doesn’t make great engineers.

Software engineering extends far beyond writing code. It’s about solving problems, building user experiences, and continuously evolving your approach. New libraries, architecture patterns, and platform updates arrive constantly. It’s easy to feel overwhelmed or fall behind. Developing your practice through deliberate effort isn’t optional; it’s a career-long necessity.

The practices that shaped my career – writing, building community, experimentation, and managing imposter syndrome – showed up in every environment. However, what drove them, and what was at stake if I ignored them, looked completely different depending on where I was.

In service companies, ignoring documentation meant chaotic client handoffs. In product companies, skipping community meant slower growth. In my startup, avoiding experimentation meant stagnation.

Below, I’ve outlined these four practices and why each one matters regardless of where you are in your career. Most of my examples come from Android development, but these principles apply universally whether you’re building web apps, backend services, or mobile experiences.

Writing

Documentation is not an afterthought. A well-written README file, inline comments explaining the “why” behind a decision rather than just the “what,” and decision records help your teammates understand the reasoning for implementation choices.

When my team migrated a 12-year-old Java codebase to Kotlin in under a year, the engineers who had documented their technical decisions and tradeoffs, even informally, moved significantly faster than those who hadn’t. You will forget why you made a choice six months from now. 

Write and make notes about your work for yourself first, then you can understand the feature or architecture better and communicate it to others.

Writing doesn’t always have to be public; it can be a personal journal of your technical decisions, questions, tradeoffs, and learnings. I keep mine in Apple Notes or a Google Doc. Sometimes you’ll be the only one who reads it. That’s fine. Your future self will thank you and those notes come in surprisingly handy during performance reviews.

Use a structured approach for development. Discover the problem and user needs, define scope and constraints, develop the architecture with clear tradeoffs, and deliver through testing, release, and measurable outcomes.

Start by being clear about what you’re trying to achieve before writing code because not every solution needs to be perfect. Sometimes “good enough” is the right answer. I learned this the hard way in my startup where over-engineering early features without validating usability cost us valuable time.

What matters more is being intentional about tradeoffs and grounding your decisions in a clear set of engineering principles, whether that is readability, performance, or testability, so you can stay consistent and align your team around how and why decisions are made.

Practical tip: keep a “learning log.” Every time you make a significant decision, briefly note what you chose, why you chose it, and what you learned. Reading entries from a year ago will remind you how much you’ve grown and occasionally make you ask, “what was I thinking?” At least you’ll know why you were thinking it!

Building community

The “lone coder” image is everywhere in movies. In practice, it’s a myth that costs engineers real growth.

I have watched talented engineers burn out trying to solve everything solo. The best features I’ve shipped were never the product of one person working in isolation – they came from collaboration, debate, and someone catching what I missed. When I was building my startup, I realized quickly that without a community to pressure-test my ideas, I was just running on personal conviction. That’s a dangerous way to make technical decisions.

Community doesn’t have to mean a formal network. It can be your immediate team, an online forum, a Slack channel, or a local meetup. What matters is having people around you who will challenge your thinking, share what they know, and tell you when you’re overcomplicating something.

Just as importantly, community gives you a place to vent about AI tools that confidently fail to generate unit tests for legacy code or a platform update that broke half your features overnight. That shared frustration is more valuable than it sounds. It reminds you that you’re not dealing with these things alone.

Code reviews are one of the most underused learning tools in engineering. Giving and receiving them isn’t just about catching bugs, it’s about understanding different approaches and tradeoffs. Some of my biggest technical learnings came from code review comments I’ve received.

Also, it’s equally valuable to talk through a problem before you’ve even started solving it. I’ve lost count of how many times explaining a complex issue to a colleague revealed the answer. I avoided code reviews early in my career because I was terrified people would discover I was just stack-overflowing everything. Turns out, everyone was doing the same thing. 

Beyond your immediate team, the broader engineering community is more accessible than it appears. LinkedIn, Slack channels, Reddit communities like r/androiddev, and local or virtual meetups are all genuine entry points. Contributing to open source libraries you use daily is one of the fastest ways to understand how experienced engineers structure code at scale.

Experimentation

In service companies, experimentation was quietly discouraged. Billable hours left little room for curiosity, and time spent exploring was time not invoiced. Product companies were different. Innovation hubs and hackathon weeks created structured space to try things without consequence. In my startup, there was no such structure. Experimentation wasn’t a perk, it was survival. Pivot or die is not a metaphor when you’re the one taking the final decision.

The most honest thing I can tell you about learning a new library or architecture pattern is that reading blogs or watching videos is not the same as building with it. You won’t understand the tradeoffs until you’ve faced them yourself. I have a folder full of half-finished side projects that never shipped and never needed to. They taught me more than most production work because the stakes were low enough to actually break things intentionally.

The other thing experimentation builds is intuition. The more patterns you’ve tried, the better your instinct becomes when choosing an approach under pressure. That instinct doesn’t come from documentation, it comes from experience. When I rebuilt the Wattpad comments experience using Jetpack Compose, it started as an internal experiment before it became a production feature. The only reason it worked was because I took calculated risks of trying out new technology.

Staying current matters too, especially on mobile platforms. UI libraries evolve constantly. OS ships new features regularly. Engineers who only learn through Jira tickets fall behind. Engineers who experiment stay sharp.

A practical habit: block one to two hours a week for unstructured learning time. No tickets, no meetings, just exploration. I try to do this on Friday afternoons. If you want to try a new approach in production without the risk, use feature flags. Test internally, iterate, and only ship when you’re confident. It removes the fear of experimentation from an environment where failure has real consequences.

Managing imposter syndrome

Every engineer I’ve worked with has felt it. The quiet fear of being found out, of not being good enough, of making the wrong call on an architecture decision that can’t easily be undone. It shows up differently depending on the environment.

In service companies, it was the fear of not knowing the client’s domain well enough. In product companies, it was the fear of making a call that would affect millions of users. In my startup, it was the fear that every decision I made alone could sink the whole thing.

Imposter syndrome never fully disappears. John Ternus, Apple’s incoming CEO, admitted in a 2024 commencement speech at the University of Pennsylvania that, on his first day at Apple, he wasn’t sure he belonged – that everyone around him seemed smarter and more confident. Someone with 25 years at Apple and a CEO title ahead of him felt it too. That should tell you something. 

I’ve felt it at every company I’ve worked at, and I’ve seen it in engineers far more experienced than me. What changes is your relationship with it. The fear of breaking things in production is real and worth respecting but it shouldn’t freeze you. Production incidents happen to everyone. What matters is how you respond: transparently, methodically, and without blame. Blameless postmortems exist for a reason. 

The most damaging form I’ve encountered is analysis paralysis, leading to overthinking architecture decisions. My startup years cured me of this. Perfect code that ships late is worthless. Timebox your decisions: give yourself a deadline to research, prototype, and decide, then commit. You can iterate. You can’t recover lost time.

Two habits that actually helped me: saying “I don’t know, but I’ll find out” out loud, without apology, and deliberately celebrating wins like a tricky bug fixed, a messy class refactored, or a teammate unblocked. These aren’t small things. Treating them as small is what feeds the imposter.

Growing as a software engineer

I didn’t learn any of this cleanly or in order. Documentation discipline came from painful handoffs in service companies. Community came from the isolation of startup life. Experimentation came from product teams that gave us space to fail safely. Managing fear came from all three, repeatedly.

For engineers, these four practices compound over a career. For engineering leaders, the questions are slightly different: 

• Are you creating the conditions where your team can actually practice them?
• Does your team have psychological safety to experiment?
• Is documentation celebrated or treated as overhead?
• Are code reviews learning opportunities or gatekeeping exercises?

The engineers who grow sustainably aren’t necessarily the most technically gifted. They’re the ones who stayed curious, built relationships, tried things outside their comfort zone, and kept moving despite the fear.

Get articles like this in your inbox

Choose your LeadDev newsletters to subscribe to.