The Senior Engineer’s Guide to Helping Others Make Decisions
I agree with the core premise of this post; you shouldn't put down ideas by junior developers by just flatly saying no.  But we can't just go around letting junior developers do whatever they feel is a good idea because "it's a learning opportunity".<p>I get that the most direct way of learning is to make mistakes and learn from those. But there's an easier way too. Read books, talk to people, get the benefit of others experience without needing to make those same mistakes again.<p>We don't go about individually discovering why modular design is a good thing, or why at certain scales microservices are a better option. We do the research, talk to others, and figure out that the general consensus is a reasonable one that we can use.<p>There are many learning opportunities even once you implement the currently best known solution. You'll eventually grow beyond what the best solution can achieve, and I feel it's a better use of our times to try to push the boundaries of knowledge at the edge, rather than making junior developers learn the same things over again. As they say, learn the rules before trying to break them.<p>--<p>I do agree that senior developers need to do a better job at communicating with junior developers. I think that in the transition between junior and senior developer, there comes a time when you just start assuming that everyone has the same context and knowledge that you do.<p>When you say "it won't scale" to a junior developer, you might believe that they understand all the subtle connotations that phrase holds. But from the perspective of the junior developer, it feels like an arrogant know it all trying to run from an argument.<p>I think we need to do a better job at explaining <i>why</i> something is a bad idea to junior developers. Learn to see things from their perspective, and communicate in a way that relates to their experience rather than ours.<p>But that's just good advice for life, not just development.