I’m coming up on 15 years of professional software engineering. I’ve worked at companies from unknown startups to large FAANG-like silicon valley companies and everywhere in between. In no particular order, sharing some things I’ve learned that others may find helpful.

Pointer's platform is  dedicated to providing insights and resources for software developers and technology enthusiasts, focusing on programming languages, frameworks, and development tools. Through articles, tutorials, and coding challenges, Pointer offers insights into building software solutions and advancing programming skills. Developers can learn about new programming languages, coding techniques, and best practices in software development.

Pointer

The author shares insights and lessons learned from their 15 years in software engineering, including the importance of avoiding absolutes, considering debuggability, managing scope, and taking ownership of systems.

Random Thoughts 15 years into Software Engineering

“You won’t have time to go back and fix technical debt.”
This is definitely 100% true. So yeah, instead of going back at a later time to address tech debt. It is best to make time to address it as early as possible.

Agree to all, except for the staging environments part. Yes, they can’t match production 100%, but in many projects (e.g. banks) you can’t afford to make mistakes on production. “Move fast and break things” works only on Facebook-style apps, where nobody cares if there’s a glitch in the system, it’s just an annoyance but nobody will die and nobody’s life will be ruined. This cannot be said for all projects.

you definitely won’t have time to fix technical debt. I’ve been in the business 30+ years and still hear other developers or dev managers say “We can add that to our tech debt and fix it later”.
In fact, after 30 years I still see every team I’ve worked on make exactly the same mistakes as the previous ones, and then add something new to the list. No one listens to the old timers, usually because they think our experience is out of date and they know better. I’ve gone from actually caring about what they do to just cynically accepting that I get paid regardless.
Here’s my 2c for the list:
Architecture &amp; structure are important at all levels. Giving your code some structure makes it easier to understand, easier to debug, and more importantly makes it easier to do the right thing when you make changes. And by that, I mean that where and how to makes changes or add code becomes more obvious when your code is well structured.

I’ve really benefited from reading those, as my 7 years of experience (with 5 years in one company) made me wonder if it’s any different in other / bigger companies.