This reminds me of a coworker that I've had bad experiences with. He fancies himself an architect, but he consistently refuses to accept any feedback on his designs. If we give feedback early in the process, he complains that we're nitpicking an incomplete design. If we give feedback when he deigns it completely ready for our review, he complains that he'll have to throw away so much work. All throughout, his refrain is that we "just don't understand his design".
I agree that it's harder when there's an absence of peers at the same experience level, and for problems that can be completed by one person, it's probably not necessary to seek validation. But if it's a problem that requires a team effort, building shared understanding of the design is at least as important as creating the design in the first place. Yes, it's more work if it doesn't click immediately for everyone else, but it's essential.
And sometimes in the process of explaining it so that even a "not great" engineer can get it, we can better understand it ourselves. And sometimes even a layperson can bring valuable insights once they get the gist of it.
It only sounds good in theory. Reality is that in most cases this discussion is pointless and you are much better just explaining.
Example. You discuss different ways of data replication and have to decide which suits the project the best.
Issue is only you have experience with multi-region data replication and people you discuss the issue with dont even understand how replication works.
From manager point of view -> you were hired to guide those ppl.
Thats what happens in consulting like 99% of the time. You are the part of the team but you are often expected to provide the solution.
You can “explain” how it will work, but 9/10 times you wont get any feedback because ppl that you are supposed to deliver that project with simply dont have the knowledge required to have a good level of discussion.
Its like saying “PHD Doctors should have even field discussion with anti-vaccers, because both of them have something to say”..
Everyone has something to say, whether its something valuable, its a different matter.
I agree that it's harder when there's an absence of peers at the same experience level, and for problems that can be completed by one person, it's probably not necessary to seek validation. But if it's a problem that requires a team effort, building shared understanding of the design is at least as important as creating the design in the first place. Yes, it's more work if it doesn't click immediately for everyone else, but it's essential.
And sometimes in the process of explaining it so that even a "not great" engineer can get it, we can better understand it ourselves. And sometimes even a layperson can bring valuable insights once they get the gist of it.