TL;DR - The mistakes that cost me most early on weren't bugs. They were misplaced priorities. Every one of them was the same shape - I optimized the visible, technical thing and neglected the invisible, high-leverage thing. Here they are, honestly.
1. I under-communicated
This is the biggest one. I treated communication as secondary to the code - heads-down, figure it out alone, surface it later. But communication is the highest-leverage skill on any team. Code no one knows about, or code that solves the wrong problem because you never asked, is worthless no matter how good it is.
What I'd do now - over-communicate.
- Ask early.
- Surface blockers fast.
- Make my thinking visible before I've built the wrong thing.
A concrete example - I once spent an entire day building a feature I thought was nice, and never ran it by anyone. It wasn't what was needed. A full day, gone, on the company's clock, because I didn't communicate. Then I paid it back working weekends cleaning up the fallout, time I should have spent getting better. A day of silent building can cost more than a day of not building at all.
2. I chased technology, not concepts
I obsessed over React and specific tools, and skipped the fundamentals underneath - complexity and Big-O, data structures, the concepts that don't change. Frameworks churn; concepts compound. React will eventually be replaced; understanding why something is O(n²), or how to model data properly, never will be. What I'd do now - learn the concept, not just the "what" of the tool of the month. Understand the thing under the thing.
3. I over-indexed on AI and tooling, not on the product
I focused too much on AI and not enough on software engineering itself. And, more importantly, on the product. The real leverage was never the tool. It's understanding what the product actually is.
- The most important user flows
- What needs optimizing
- What to prioritize
- What has the biggest business leverage
I'd polish code nobody cared about while the thing that actually mattered sat untouched. The honest truth - nobody gives a damn whether the code is clean. They care whether it delivers value. What I'd do now - understand the product and the business first, and let that decide where the effort goes.
4. I didn't self-reflect
I put in the hours but never reviewed my own process - what I did, what worked, what I'd change. Massive input without reflection is just repetition; you get more reps of your mistakes. What I'd do now - make reflection a practice. Regularly, honestly ask what I did wrong and adjust. The input only compounds if you learn from it.
5. I rushed the process and built happy-path-first
I skipped the thinking phase and jumped straight to building. I'd chase the functionality that worked on the happy path first (get it running, feel done, move on) while the edge cases, the bigger picture, and the real design waited. But every phase of software development you skip, you pay back later as technical debt, with interest. This was one of my largest mistakes, and I can point to the codebases where it cost me. What I'd do now - don't rush the phases. Think the bigger picture and the edge cases through before the happy path. That's exactly why I now run spec → tests → code, in that order.
The throughline
All five are the same mistake wearing different clothes.
Growing as an engineer was learning to see that invisible layer and prioritize it over the shiny visible one. That shift is the whole lesson. Being able to name these mistakes by heart is the proof I actually made it.