In June 2012, I started my first job at Contus in Chennai. My title was Application Developer. My job was building and maintaining Magento extensions for apptha.com, a marketplace for Magento modules and themes.
I knew PHP. I did not know Magento’s EAV architecture, its observer pattern, its layout XML system, or why a product query could join fifteen tables and still feel normal. I learned those things by breaking them repeatedly.
That was 13 years ago. Since then: Contus to BORN Group to Cognizant (six years, mostly on Newell Brands) to PickYourTrail, where I’m now Associate Director of Engineering. Magento to Laravel to React Native to Go to Python to AI systems. Agency work, Fortune 500 consulting, product company, startup. The technology changed constantly. Some other things changed more slowly, and the slower things are the ones worth writing about.
This is not general advice. I have no interest in writing a list of virtues. This is specific to what I’ve actually seen compound over the arc of that career and what I’d go back and tell myself if I could.
Systems thinking didn’t come naturally: I had to choose it
The first few years, I thought mostly in features. Ticket in, code out. The gap between “this works” and “this is well designed” existed, but I didn’t feel it urgently. I felt it in code review comments, then in debugging sessions, then eventually in the moment where I had to rewrite something I’d built six months earlier because I hadn’t thought about how it would need to change.
The shift happened gradually. At BORN Group, working on client projects where the team turned over and I had to maintain what someone else had built. At Cognizant, working on a large e-commerce platform (Newell Brands) where the surface area was big enough that you couldn’t reason about any piece in isolation. You started to see that a feature wasn’t a feature, it was a node in a graph of dependencies, state assumptions, and data contracts.
Once that view clicked, I couldn’t unclick it. And it made me faster, not slower. Thinking about the system before writing the code meant fewer rewrites. It meant the code I shipped was easier for other people to understand. It meant I asked different questions in meetings, not “what should this button do” but “what state is this button reading from and who else reads that state.”
The thing I’d tell a junior developer: features are visible, systems are structural. Learn to see the structure beneath the ticket. It takes time, but it’s the multiplier that keeps compounding.
Breadth felt like distraction: it turned out to be pattern recognition
At some point in my late twenties I had a mild crisis about the fact that I’d worked across too many things. Magento, then Laravel, then React Native, then Go, then Python, now AI pipelines. I worried I wasn’t deep enough in any of them.
I was wrong about that, but not in the way I expected.
The breadth didn’t replace depth, I have real depth in specific things. What it did was give me a template recognition system. When I was building the chat pipeline at PickYourTrail, I recognized a grouping-and-flush problem I’d seen in a completely different context years earlier. When I was designing the allocation engine, the state machine pattern came naturally because I’d seen booking states evolve in exactly that way at Contus. When I was evaluating whether to use DSPy for structured LLM output, I already knew what “inconsistent labels from an underconstrained prompt” looked like from debugging Magento EAV inconsistencies in an entirely different era.
The patterns don’t transfer automatically, you have to do the mapping work. But the raw material for the mapping is there, and that’s worth something.
If you’re early in your career and you find yourself jumping between technologies, don’t panic. Go deep where depth is available, but don’t confuse narrowness with depth. Some of the deepest systems thinkers I’ve worked with have wide backgrounds.
Open source was about clarity, not audience
I’ve published a handful of open-source packages over the years, eav, layout-core, aspect-me, mods-framework. None of them are famous. Some have a few hundred stars. That’s not why I built them.
I built them because writing code for a public audience changes how you think about it. When you write for your own codebase, you can rely on implicit context, you know what the assumptions are, you remember the constraints. When you write for strangers, you have to make those assumptions explicit. You have to think about the API surface. You have to think about what happens when someone uses it in a way you didn’t expect.
That forcing function is valuable in a way that’s hard to replicate inside a private codebase. Every public package I shipped made me a slightly better API designer. Not because of the feedback I got (though that helped), but because of the discipline of trying to make something usable by people who can’t ask me questions.
The eav package in particular came out of years of working with Magento’s EAV system, understanding why it exists (flexible schema for product attributes), why it gets slow (joins explode), and what a cleaner implementation would look like in Laravel. Writing it publicly forced me to think through every design choice rather than just building what was expedient.
I’d tell a junior developer: publish things, even small things, even imperfect things. Not for the GitHub stars. For the clarity that comes from treating your code as something another person has to understand.
Build vs buy is a judgment call: not a principle
There are two failure modes here. Teams that build everything themselves and create maintenance debt for no real gain. Teams that outsource everything and end up with a collection of dependencies they don’t understand and can’t control.
I’ve been in both failure modes. What I’ve learned is that the question “should we build this or use something existing?” is not a philosophical question. It’s a strategic one with specific inputs.
Build when: the workflow is genuinely core to how you operate, the mismatch with existing tools is structural (not just cosmetic), and owning the code creates leverage, you can tune it, extend it, and understand it when it breaks.
Use existing tools when: the capability is common, the integration surface is small, and the main outcome of building your own version is that you own a maintenance burden.
The clearest example of the first case in my own career is Atom, the design system I built at PickYourTrail before we adopted a standard library. Building it taught the team about our design constraints, created a shared vocabulary, and made UI decisions faster. We didn’t build it to be different. We built it because the right abstraction for our product wasn’t off-the-shelf at the time.
Bloat, the macOS runtime manager I’ve been building, is another example. Docker Desktop is heavy for what we needed. Laravel Herd is PHP-focused. The mismatch was structural enough, and the workflow central enough to developer experience, that building our own made sense.
I’ve also made the opposite mistake: building a custom pipeline where a solid open-source library would have served 90% of the use case. You learn both failure modes by experiencing them.
Management doesn’t mean abandoning craft: but that’s a choice you have to make
When I moved from senior engineer to engineering manager to Associate Director, I expected to write less code. I did write less code. What I didn’t expect was that staying technical was something I’d have to actively protect.
There’s a drift that happens. The calendar fills. Your value becomes coordination, clarity, unblocking. Code review starts to feel like an obligation rather than a contribution. Personal projects fall off. Then, a year later, you find yourself in an architecture discussion and you’re reasoning from slightly stale intuitions.
The personal projects were how I kept that from happening entirely. The trading engine is running in production, 61 live strategies across NIFTY, BANKNIFTY, and SENSEX. Bloat is something I use every day. The fine-tuning pipeline, the AI team system, these aren’t portfolio pieces. They’re things I built because the problem was interesting and the building kept me sharp.
The thing I’d say to an ambitious developer considering the management path: it doesn’t have to mean abandoning the craft. But it won’t stay alive automatically. You have to make room for it deliberately. That means saying no to some meetings, protecting some morning time, keeping personal projects alive even when they’re not the most important thing on the list.
The technical depth you carry into leadership decisions, who to hire, what to build, whether an estimate is reasonable, whether a proposed architecture has a flaw, that depth is only there if you keep exercising it.
What I’d focus on if I were starting now
If I were 22 and starting fresh in 2026, two things would be different from 2012.
First, the AI layer. In 2012, AI wasn’t a practical tool for most product engineers. Now it is, and the engineers who will have the most impact in the next decade are the ones who understand it as an engineering problem, not just as a capability to call. That means understanding where LLMs are reliable and where they’re not. It means knowing how to wrap non-deterministic outputs in systems that stay trustworthy. It means building the evaluation loops and the fallback paths, not just the happy path prompt. I’d start learning that from year one.
Second, the fundamentals haven’t changed. Data structures, system design, how databases actually work, how distributed systems fail, none of that is less relevant. If anything it’s more relevant, because the AI layer sits on top of systems that are still fundamentally classical. The engineers who understand both layers will be the ones who can make good tradeoffs.
I’d be skeptical of the pace of framework churn. New tools every six months is real, but the underlying patterns are more stable than they appear. Learn the pattern first, then the tool. That ratio holds.
The habit I’d cultivate earlier: writing things down
This one took me too long.
Not writing publicly (though that’s useful). Writing for myself, architecture decision records, post-mortems, design notes before I started building. The discipline of writing your reasoning down before you commit to code is underrated.
What I’ve noticed is that a lot of what looks like technical depth from the outside is actually structured thinking made legible. When someone can explain clearly why they made a design choice, what they considered, what they rejected and why, that’s not just communication skill. It’s a symptom of having thought it through more completely.
Writing is how I think most clearly. The act of forming sentences forces precision that casual reasoning doesn’t. If the explanation is vague when I write it down, the thinking was vague. That’s useful information before you’ve committed to an implementation.
I’d tell a junior developer to start that habit immediately. Not blog posts necessarily, though those help too. Just the practice of writing your reasoning before and after significant decisions. It compounds in ways that are hard to see in the short term and very visible in the long term.
Thirteen years of building teaches you some things that can’t be shortcut. The pattern recognition takes time to accumulate. The judgment about when to build and when to buy takes experience. The awareness of what management actually costs takes going through it.
But some things can be front-loaded. Systems thinking is a choice you can make earlier. The open-source habit is available from year one. Writing things down costs nothing. Staying close to the craft when the calendar pressures you away, that’s a habit worth building before the pressure starts.
The specific things that compounded for me were mostly invisible in the short term. They looked like side projects, like package maintenance, like writing docs that nobody read. Ten years later, they’re what made the difference.