After 15 years of writing code, leading teams, and shipping products across startups and enterprises, I’ve finally decided to start writing. Not because I think the world needs another tech blog — but because the lessons I wish someone had told me earlier deserve to live somewhere other than my head.

So here it is. The stuff I’d go back and tell junior-me if I could.

The code is never the hard part

Early in my career, I thought being a great engineer meant writing the cleverest code. I optimized prematurely. I over-engineered. I built things that were technically impressive and practically useless.

The real challenge has always been people. Understanding what users actually need (not what they say they need). Navigating disagreements in code reviews without turning them into ego battles. Convincing a team to pay down tech debt when there’s a feature deadline breathing down your neck.

Software is built by people. Learn to work with them, and the code follows.

Simplicity is a discipline, not a shortcut

It’s easy to make things complex. Any engineer can add layers of abstraction, introduce new tools, and build an architecture that looks impressive on a whiteboard. The hard part is resisting that urge.

Simplicity scales. Complexity breaks. And the best architecture is the one your team can actually maintain — not the one that wins style points.

Every time I’ve seen a team grind to a halt, the root cause wasn’t a lack of talent. It was accumulated complexity that nobody could reason about anymore.

Prototype early, argue less

I spent years in meetings debating approaches that could have been settled in an afternoon with a quick prototype. An early prototype isn’t just a proof of concept — it’s a conversation starter that cuts through theoretical disagreements.

Build the thing. Show it to people. Let reality do the arguing for you. Early prototypes save months of development and, more importantly, months of building the wrong thing.

AI changed how I work, not what I do

I’ve been integrating AI into my workflow, and here’s what I’ve learned: AI won’t replace engineers, but engineers using AI will outpace those who don’t. That said, AI features should solve real problems, not just showcase new tech.

The engineers who will thrive are the ones who can think critically about what to build and why — and then use every tool available, including AI, to build it well.

Why I’m writing

I’m not starting this blog to build a brand or sell a course. I’m writing because every hard-won lesson I’ve learned came from someone else being generous enough to share theirs. Consider this me paying it forward.

If you’re an engineer at any stage of your career, I hope something here saves you time, frustration, or both. And if you disagree with anything — good. The best conversations start with disagreement.

More to come.

Lucas Pinto is a Lead Staff Software Engineer with 15 years of experience across startups and enterprise. He’s led multi-team initiatives, earned an Engineering Emmy, and has the superpower of translating complex technical requirements into easy to understand concepts for easier multi-team collaboration.