Hacker News Reader

Totally agree there, sometimes there is room for learning and mistakes but not everything must become a learning opportunity otherwise nothing will get done.

I'm currently raising a toddler and find great parallels there compared to coaching a junior. It's always good to explain why something is bad/wrong to my kids and allow them to learn. But if w're in the middle of crossing the road that's not the time and place.

There are so many events in life that shape us, looking back at myself at my earlier career I can't understand how I got where I am now with how stupid I was then and the opinions I held.

I think it has a great deal to do with being able to see things in a different way and having the experience to be open for certain ideas. But I currently still have a hard time at recognising this in myself or others. And allow to know when you can go for the next step.

> But if w're in the middle of crossing the road that's not the time and place.

I'm facing the same thing right now and I keep thinking back to what my mum did: It's always OK to ask why, and this question always deserves an answer, but you need to accept that sometimes the answer is "just trust me, I'll explain later."

As long as you do explain later ;-)

Not necessarily. Someone might be to young to understand no matter how you explain. Like I said above when looking back on my career, I see things now in a way I could explain to myself a few months/years back. And some people might never be open for some idea's at all.

> 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.

> 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.

> I think we need to do a better job at explaining why 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.

Not everyone learns the same. Some people may learn significantly faster and/or more effectively if they are allowed to make mistakes - to see/experience the difference. I think this a good approach for simple problems. However, if the problem is highly complex and time consuming, its not as practical as the time cost to redo, as the work is too high. Thats where you do the research and reading. It requires a balance.

I use a "touching a hot stove" analogy:

There's a hot stove in the room. Do you want every engineer to touch the hot stove to find out it's hot? Or do you want to take one engineer who's well equipped to find out how hot the stove it, find out it's hot, then notify everyone that it's hot?

I don't usually use the analogy for this particular argument, but it works here also.

However on the other end of the spectrum you have The monkey experiment, where you end up with 5 monkeys that don't climb the ladder for the banana reward, but none of them knows why not to.

I sometimes still find it a challenge to walk the line between sticking to a principle and letting it go. But it's my opinion you should always stay open to let any of your principles be challenged (by someone else or yourself). And it still surprises me how I can shatter some of my deep rooted principles because of a new/different look on things.

Document your decisions, explain assumptions, limitations, and reasoning. It helps immensely.

Indeed, I also started moving from documenting what code does to explain what I intend the code to accomplish (because code already explains clearly find what it does by itself). By communicating at this level the overarching idea does not get lost and allows for much better refactoring or debugging.

> But we can't just go around letting junior developers do whatever they feel is a good idea because "it's a learning opportunity".

I don't think anyone wants junior developers to do "whatever they want". That's not really what's being said, so refuting it doesn't mean much.

But these days, with deterministic deployments, virtualization, and containerization, there's a heck of a lot a junior developer can do in a harmless way. If they want to try applying a consensus algorithm instead of locking a database record, give them some VMs, express your concerns, and wish them luck. Most importantly, let them know what would make the project successful and what would make it a waste of their time.