Over the years, I've learned to focus on what actually matters in software engineering and let go of the noise.
When I first started writing code, I cared about everything. I obsessed over the tiniest syntax details, argued endlessly about which frontend framework was fundamentally superior, and spent days refactoring code simply because it didn't look "elegant" enough.
But as the years passed, my perspective drastically shifted. I realized that much of what developers spend their energy worrying about has absolutely zero impact on the actual product, the end user, or the business's bottom line.
Here are the things I've stopped caring about as an engineer, and how letting them go has skyrocketed my productivity (and saved my sanity).
React vs. Vue vs. Angular vs. Svelte. Next.js vs. Remix.
Early on, I would passionately advocate for my "team." I'd spend hours reading comparison articles and debating on forums about why my tool of choice was the objectively correct one.
Today? I really don't care.
Frameworks are just tools in a toolbox. At the end of the day, they all compile down to HTML, CSS, and JavaScript. The user doesn't know or care if your button is a highly-optimized React component or a raw DOM element. They just care if it works, if it's fast, and if it solves their problem. Now, I simply choose the tool that fits the team's skillset and the project's requirements, and I don't look back.
There was a time when seeing a code coverage metric drop below 90% would give me anxiety. I would write tests for basic getters, setters, and trivial UI components just to bump up that sweet percentage.
I've since learned that code coverage is a deeply flawed metric for software quality. Chasing 100% coverage almost always leads to writing brittle tests that verify implementation details rather than actual behavior. Now, I focus purely on testing critical business logic and complex edge cases. If a trivial visual component breaks, a quick manual check or an E2E test will catch it. I would much rather have 60% coverage of tests that actually matter than 100% coverage of tests that break every time I rename a variable.
I used to spend days architecting the perfect folder structure, abstracting every possible service, and applying every design pattern I could remember from Clean Code. I was building complex microservices for apps that barely had 100 active users.
Now, I embrace simplicity and YAGNI (You Aren't Gonna Need It). I start with a monolith. I put everything in a few logical folders. I don't abstract things until I actively feel the pain of duplication.
Premature abstraction is the root of much evil in codebases. It makes code harder to read, harder to navigate, and significantly harder to onboard new developers. Simple code that works is always better than complex code that anticipates a hypothetical future that may never arrive.
I used to feel like an imposter if I had to Google how to use reduce in JavaScript or how to center a div in CSS. I thought "real" developers just knew everything by heart.
With the rise of AI tools and advanced IDEs, memorizing syntax is completely obsolete. The true value of a software engineer lies in problem-solving, system design, and deeply understanding business requirements—not in acting as a human dictionary for programming languages.
Letting go of these things wasn't easy. It required a fundamental shift from ego-driven development to product-driven development. But once I stopped caring about the noise, I found I had so much more time and energy to care about the things that actually matter: building great products, shipping fast, and solving real user problems.