3 ms·

No thank you. Because how good is the expert? They just built a bunch of stuff to enforce one approach; they're invested in it even if they're wrong, or even i

No thank you. Because how good is the expert? They just built a bunch of stuff to enforce one approach; they're invested in it even if they're wrong, or even if the project changes. The ideal is an expert who will be involved with the project, offering suggestions, providing a sounding board to non-experts working through issues, etc. Mentor and guidance, yes, but without first trying to lock people into a specific trajectory. And if ever the non-experts decide to do something different, -that's their prerogative-. Because it's they who will be dealing with the fallout if they're wrong. And unfair to make them deal with the fallout if they were right, and the expert was wrong. It's incumbent on the expert to convince them, not dictate.

AmpsterMan 6y ago
I'm in line with your comment more than the parent. This happened to me too. Turns out this expert was very knowledgeable, but spread very thin so he could never help out as much as was needed. Furthermore, there were just issues that one couldn't have predicted because it would require months of working in the code base to see the problems clearly manifest. Now the guy is gone and we are too invested to be able to fix any fundamental issues without incurring pain, so it's not done.
tacitusarc 6y ago
This hasn't been my experience. When the non-experts decide to break patterns and remove guardrails because they don't understand their purpose, and then they break the project, the experts are once again pulled back in to try and scavenge the remains and get something workable. It's fine if people want to do something different: just first become an expert.
- karmakaze 6y ago
  This thread shows the problems with both approaches. Being handed a design that isn't appreciated but expected to follow tends to go off in a direction that's unproductive, especially if there isn't someone who understands the value and maintains the key parts so as not to lose it. The other problem is that there aren't enough experts and how can they become experts without strengthening expert muscles. They have to practice and learn. Depending on the distribution of abilities, what I've found to be give the most leverage is to convey a few specific design ideas significant for a particular project to someone on the project who can understand or at least commit to using them. You can check in from time to time and provide some input and clarity. Regardless of good intent on all sides, results still vary. But if done smoothly, everyone gets better at working together on high-level tech things and there's no resentment that doesn't fade away quickly.
- lostcolony 6y ago
  'decide to break patterns and remove guardrails because they don't understand their purpose' Ensuring the non-experts understand their purpose is the role of the experts. NOT making the decision as to when to deviate. That's my point. An org that leverages an expert to make others experts is an org that ends up with a team full of experts. An org that leverages an expert to make decisions for the non-experts is an org that is going to have a lot of issues in production, and likely high turnover.
  - tacitusarc 6y ago
    Absolutely, but it's a three-way street. The experts must be willing to teach, the non-experts must be willing to learn, and the organization must be willing to allow them the time to do so. If any one of those things is missing, it doesn't work. And in my experience, the most likely ingredient to be present is it willingness of the experts to teach. If you're good at something, it's fun to explain it to others.

AmpsterMan 6y ago

I'm in line with your comment more than the parent. This happened to me too. Turns out this expert was very knowledgeable, but spread very thin so he could never help out as much as was needed. Furthermore, there were just issues that one couldn't have predicted because it would require months of working in the code base to see the problems clearly manifest. Now the guy is gone and we are too invested to be able to fix any fundamental issues without incurring pain, so it's not done.

tacitusarc 6y ago

This hasn't been my experience. When the non-experts decide to break patterns and remove guardrails because they don't understand their purpose, and then they break the project, the experts are once again pulled back in to try and scavenge the remains and get something workable. It's fine if people want to do something different: just first become an expert.

karmakaze 6y ago
This thread shows the problems with both approaches. Being handed a design that isn't appreciated but expected to follow tends to go off in a direction that's unproductive, especially if there isn't someone who understands the value and maintains the key parts so as not to lose it. The other problem is that there aren't enough experts and how can they become experts without strengthening expert muscles. They have to practice and learn. Depending on the distribution of abilities, what I've found to be give the most leverage is to convey a few specific design ideas significant for a particular project to someone on the project who can understand or at least commit to using them. You can check in from time to time and provide some input and clarity. Regardless of good intent on all sides, results still vary. But if done smoothly, everyone gets better at working together on high-level tech things and there's no resentment that doesn't fade away quickly.
lostcolony 6y ago
'decide to break patterns and remove guardrails because they don't understand their purpose' Ensuring the non-experts understand their purpose is the role of the experts. NOT making the decision as to when to deviate. That's my point. An org that leverages an expert to make others experts is an org that ends up with a team full of experts. An org that leverages an expert to make decisions for the non-experts is an org that is going to have a lot of issues in production, and likely high turnover.
- tacitusarc 6y ago
  Absolutely, but it's a three-way street. The experts must be willing to teach, the non-experts must be willing to learn, and the organization must be willing to allow them the time to do so. If any one of those things is missing, it doesn't work. And in my experience, the most likely ingredient to be present is it willingness of the experts to teach. If you're good at something, it's fun to explain it to others.