Developers are a fascinating bunch. Opinions, anecdotal evidence, and how we "feel" about how scientific one choice is versus another drive the bulk of so-called developer debates. Many developers offer various opinions on how to do one thing versus another. Many developers share thoughts that may impact other developer choices. This process is all part of a standard social construct. However, we all owe it to the young and aspiring developers to keep our opinions in check. I'm not saying we need to stay silent or stop sharing what we learn, but rather than pick technology A or B to rag on, outline why you choose A over B and how it addresses your problems more effectively. When we write opinion pieces about technologies we don't like it can easily fall into a slippery slope of misinformation.
Most developer complaints are driven by reasons such as:
- This is not how I would write this.
- This looks like an anti-pattern I just read about.
- I was really stressed out while working with technology X.
- I wish I understood this new technology pattern better.
- All this magic stuff is bad practices, according to a 30-year-old book.
- New developers have it so much easier than when I made everything from scratch.
The bulk of these issues stems from problems at the developers day job. Not their nighttime coding, not their "I'm having fun tinkering with this" space. Most developers only complain about the issues they face at their job, or worse yet, what they see the community moving forward with while they're unable to spend time on it. All too often because they dislike the choices of their team's System Architect or Lead Developer. More often than not, developer complaints can easily be resolved by one of the following:
- Better internal documentation for the project
- Better code reviews / processes
- Better standards for your code within your team
- Internal discussions with your team for best (for us) patterns and use cases
- Better training/ onboarding of new developers for a team
- Reduction of rockstar developer patterns
Furthermore, developers should be more empathetic to the various communities. Writing code is complex and has numerous challenges. Picking on persons or blaming them for what you feel is misguiding large groups of people is never kind, nor does it ever really solve the problems you're facing. If you are having issues with a technology or firmly feel it is not a good solution, then identify those issues and how to resolve them. Open-source developers and maintainers spend significant time ensuring that their systems work well and are generally open to constructive feedback. Demanding that they deliver things or harassing them for not providing the latest best practices is a complete waste of everyone's time.