[jdmichal]

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.

[aequitas]

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.

[cema]

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

[aequitas]

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.