My perspective changes as a software developer with 10 years of experience
Published on September 15, 2021 • 3 minutes to read
Inspired by a conversation I had with a teammate about my career and how I became a staff engineer, I decided to post a quick read on the things I feel shaped my career and the opinions I have maintained, changed, and kept during the past 10 years.
Topics I’ve changed my mind on
- Clever code is the enemy, understandable code no matter how many lines you do to provide clarity is always better.
- Duplication of code is better than abstracting when you are moving fast and trying to prove a point.
- Bad abstractions can occur on any programming paradigm.
- Abstracting from the beginning always result in complex and hard-to-maintain code, is better to abstract once the business case rises.
- Common practices are just someone’s opinion, don’t follow others’ opinions blindly.
- Designing over-the-top and super scalable solutions when you don’t need them makes you a bad engineer.
- Typed languages are great, especially in a fast-growing company.
- It’s easier to write code than to express your thoughts through code, meaning I spent more time thinking about the solution to the problem than writing the solution.
- Document databases or NoSQL DBs aren’t that bad.
- Languages and frameworks are just a way of expressing your problems and solutions, any allegiances to a language or framework are just hindering your ability to be creative.
Opinions I picked during my career
- You can develop your own and company best practices.
- Stand-ups are the best tool to keep an eye on new members of the team and offer a hand to help others.
- Fight for simplicity, adding more technology or features isn’t always the best solution to the problem.
- We are software engineers but we rarely take engineering-like decisions, meaning most decisions are rarely backed up with analysis, numbers, and/or data.
- Product managers should focus on the product and leave the day-to-day organization of the board to the engineering team.
- Most developers struggle with the concept of TDD and that’s fine.
- Pair-programming is a great communication tool but it’s also an exercise for the mind of both individuals, overdoing it creates risks of burnout.
- Developers grow through pull request reviews more than people think, senior developers’ feedback is invaluable to others, especially in their first months on a new company.
- Making your code scalable the first time you write it is rarely needed and with good metrics you can foresee when you will need it. The word “scalable” is misused and thrown way too often.
- YAGNI comes first, then DRY
- Functional Programming has been easier to write with TDD practices than Object-Oriented Programming. Mocking third-party libraries is also easier with the current tools within the JS tool belt.
- Most people in the team will never appreciate what a product owner does and they will think that most of them aren’t necessary or are redundant, but once you work without one you will wish you never thought that.
- Good Senior developers are hard to find, they need good soft and software skills, and we spend all the junior and development years just improving the software side. People that truly become good at soft skills during this period are outgoing by nature.
- DRY is about avoiding repetition, not the solution to all the problems.
- Leadership is about creating opportunities for everyone to grow to ensure mid to long-term happiness and not about keeping everyone happy in the short term.
- People hate monoliths, but they are the best approach for most scenarios.
- Developer guilds discussions focus too much on linting, coding style, and other small issues that can be easily automated, focusing on sharing breakthroughs, new ideas for future products, and optimizations would be more helpful but it is hard to convey the value of them.
- Code coverage is a vanity metric, especially when your suite has many flakey specs and you start introducing retries on your CI suite.
- Most interviews do not reflect what you will do on your job, and they follow the same patterns, by learning cracking the coding interview you will land almost all developer jobs.