5 ms·

The ideal is an expert who sets up the project, builds the guard rails, creates the patterns and basically sets up a framework for everyone to use. Then they te

by Swizec 6y ago

The ideal is an expert who sets up the project, builds the guard rails, creates the patterns and basically sets up a framework for everyone to use. Then they teach everyone how to use it and why And from then it’s a mentoring role. The expert spends more time PR-ing and adding to the framework than building end product features. They build stuff that touches every feature. Force multiplier is the game.

cat199 6y ago
agree - in my view, if you're not designing for the 'hit by a bus scenario', you're not an expert, irrespective of technical knowledge
hinkley 6y ago
I’ve seen this crash and burn too often. If you have someone build something, and then explain it, you don’t find out until after if they are capable of explaining it. Just like a product MVP, you have to explain it as you go along. Without it, you start out with a multiplier but end with a divisor.
- sgtnoodle 6y ago
  I think that's why it's very important to get buy-in and solicit feedback from coworkers even if you're the domain expert. Also, regression test coverage from the beginning is very important if you ever expect anyone else or even your future self to have a shot at safely modifying mission critical pieces of code.
  - hinkley 6y ago
    You have to get people invested in the solution. Some people call that buy-in, others use that term a little more tepidly.
- NotPavlovsDog 6y ago
  It could be described as about the bus factor, couldn't it? If an organization has a product, and that product is not retired, it should be sustainable by a team. Lone points of breakage such as a single visionary or the mythic 10x-er are not optimal for the product if the unit taking care of the product is a team or several teams.
lostcolony 6y ago
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.
fakedang 6y ago
I have been the "expert" in many situations, and no way would I let this happen. 1.) Mentoring is such a difficult aspect as an expert. I likely would have built up my expertise from a combination of my studies, my past work experience and my previous, extremely skilled mentors. I can't expect people to get up to speed simply through my mentoring alone - especially if I'm not a capable enough communicator. 2.) Experts like to retain their expertise, stay unique. Regardless of what idealistic scenario you have in mind, everywhere I've seen, experts are always very cautious to giving away ground. I've been guilty of it, especially when I knew that my unique expertise was responsible for my sizeable bonus check in an IB. 3.) Experts will not do all the grunt work you mentioned. They come with the expectation that they've been hired for their expertise and not to be another cog in the wheel, but the engine itself (for a particular project). Ideally now, what you would want would be a team of generalists, and a small crack team of experts (or a lone wolf expert). The generalists set up the project, plan how to build the guard rails, etc, then explain it to the experts, then when both are up to speed, generalists build it out and give the heavy lifting work to the experts to take over from. Converting a generalist to an expert is a time intensive process that has to be structured and well-thought out. It should not be for just one project, but should continue for multiple projects.
- hinkley 6y ago
  > Experts like to retain their expertise, stay unique. In sports they call that a Ball Hog. Is software a collaborative effort or an ego trip for three people? As someone else mentioned, their expert was spread too thin. I’ve had this happen to me, too, and the only solution I know is to give away (delegate) almost everything you can. If some part really makes you happy, hold onto that even if you could give it away. Not for ego, but for burnout. You need some reasons to show up in the morning, just like everybody else.
edanm 6y ago
A lot of people seem against this approach, but I'm all for it. In some sense, that's exactly how top level frameworks like react and Django get made- experts build them to make it easier for the rest of us to write the business-specific logic.
- EvilEy3 6y ago
  Wrong comparison. Django and React are products, if you were to say experts make it easier for us to write Django and React themselves that would better.
  - edanm 6y ago
    That doesn't make sense to me. Where do you draw the line between a framework and a product? Google et all probably have lots of internal tooling and frameworks. Hell, react started as internal to FB didn't it? Does that count as a framework or as a product? Lots of other companies have similar internal frameworks, probably with less resources devoted to them, but in the other hand with less use cases. Do those not similarly count as frameworks written by experts?
- tonyarkles 6y ago
  I'm half with you, and I see both sides. When it's done well, I think it's a fantastic approach. I'm in a situation right now where I'm kind of that "expert". Not because it was planned that way, but because I was the only person on the project at the start. Now I've got a couple of young EEs working under me, and they do most of the development work while I sit in meetings for a good chunk of the day. I come in and help with the hard problems, but most of the day-to-day work is on them. It's working out great because it seems I got the structure relatively right (they've changed things a little bit as they've added new things I didn't think of, and I've reviewed and supported those changes) The flip side is ${JOB-2} for me. It was a similar situation; an "expert" laid the foundations and then got pulled off to do other projects. There were two main differences between my current situation and that one: - The infrastructure he put together was not great and full of footguns (e.g. accidentally implicitly double-encoding HTTP requests, bizarre cookie handling, etc) - The code was hard to change because of how it was integrated, and the team didn't feel particularly empowered to fix it - He was barely around (being assigned to something in a different building). - He pushed back hard when people suggested that there might be problems with it and fixes required. Instead of facilitating and reviewing, he'd pop by occasionally, look at things that changed in his absence, and shit on them. As I'm writing this, I'm reflecting on whether or not I'm contributing enough to the long-term development of this codebase, and I'm feeling relatively ok with the answer. Ultimately, this product is still my baby and whether or not it's successful is on me. Maybe that's the difference? I'm quite invested in the foundations I laid, and more than happy to help my team work through issues they find in it?

by Swizec 6y ago

cat199 6y ago

agree - in my view, if you're not designing for the 'hit by a bus scenario', you're not an expert, irrespective of technical knowledge

hinkley 6y ago

I’ve seen this crash and burn too often. If you have someone build something, and then explain it, you don’t find out until after if they are capable of explaining it. Just like a product MVP, you have to explain it as you go along. Without it, you start out with a multiplier but end with a divisor.

sgtnoodle 6y ago
I think that's why it's very important to get buy-in and solicit feedback from coworkers even if you're the domain expert. Also, regression test coverage from the beginning is very important if you ever expect anyone else or even your future self to have a shot at safely modifying mission critical pieces of code.
- hinkley 6y ago
  You have to get people invested in the solution. Some people call that buy-in, others use that term a little more tepidly.
NotPavlovsDog 6y ago
It could be described as about the bus factor, couldn't it? If an organization has a product, and that product is not retired, it should be sustainable by a team. Lone points of breakage such as a single visionary or the mythic 10x-er are not optimal for the product if the unit taking care of the product is a team or several teams.

lostcolony 6y ago

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.

fakedang 6y ago

I have been the "expert" in many situations, and no way would I let this happen. 1.) Mentoring is such a difficult aspect as an expert. I likely would have built up my expertise from a combination of my studies, my past work experience and my previous, extremely skilled mentors. I can't expect people to get up to speed simply through my mentoring alone - especially if I'm not a capable enough communicator. 2.) Experts like to retain their expertise, stay unique. Regardless of what idealistic scenario you have in mind, everywhere I've seen, experts are always very cautious to giving away ground. I've been guilty of it, especially when I knew that my unique expertise was responsible for my sizeable bonus check in an IB. 3.) Experts will not do all the grunt work you mentioned. They come with the expectation that they've been hired for their expertise and not to be another cog in the wheel, but the engine itself (for a particular project). Ideally now, what you would want would be a team of generalists, and a small crack team of experts (or a lone wolf expert). The generalists set up the project, plan how to build the guard rails, etc, then explain it to the experts, then when both are up to speed, generalists build it out and give the heavy lifting work to the experts to take over from. Converting a generalist to an expert is a time intensive process that has to be structured and well-thought out. It should not be for just one project, but should continue for multiple projects.

hinkley 6y ago
> Experts like to retain their expertise, stay unique. In sports they call that a Ball Hog. Is software a collaborative effort or an ego trip for three people? As someone else mentioned, their expert was spread too thin. I’ve had this happen to me, too, and the only solution I know is to give away (delegate) almost everything you can. If some part really makes you happy, hold onto that even if you could give it away. Not for ego, but for burnout. You need some reasons to show up in the morning, just like everybody else.

edanm 6y ago

A lot of people seem against this approach, but I'm all for it. In some sense, that's exactly how top level frameworks like react and Django get made- experts build them to make it easier for the rest of us to write the business-specific logic.

EvilEy3 6y ago
Wrong comparison. Django and React are products, if you were to say experts make it easier for us to write Django and React themselves that would better.
- edanm 6y ago
  That doesn't make sense to me. Where do you draw the line between a framework and a product? Google et all probably have lots of internal tooling and frameworks. Hell, react started as internal to FB didn't it? Does that count as a framework or as a product? Lots of other companies have similar internal frameworks, probably with less resources devoted to them, but in the other hand with less use cases. Do those not similarly count as frameworks written by experts?
tonyarkles 6y ago
I'm half with you, and I see both sides. When it's done well, I think it's a fantastic approach. I'm in a situation right now where I'm kind of that "expert". Not because it was planned that way, but because I was the only person on the project at the start. Now I've got a couple of young EEs working under me, and they do most of the development work while I sit in meetings for a good chunk of the day. I come in and help with the hard problems, but most of the day-to-day work is on them. It's working out great because it seems I got the structure relatively right (they've changed things a little bit as they've added new things I didn't think of, and I've reviewed and supported those changes) The flip side is ${JOB-2} for me. It was a similar situation; an "expert" laid the foundations and then got pulled off to do other projects. There were two main differences between my current situation and that one: - The infrastructure he put together was not great and full of footguns (e.g. accidentally implicitly double-encoding HTTP requests, bizarre cookie handling, etc) - The code was hard to change because of how it was integrated, and the team didn't feel particularly empowered to fix it - He was barely around (being assigned to something in a different building). - He pushed back hard when people suggested that there might be problems with it and fixes required. Instead of facilitating and reviewing, he'd pop by occasionally, look at things that changed in his absence, and shit on them. As I'm writing this, I'm reflecting on whether or not I'm contributing enough to the long-term development of this codebase, and I'm feeling relatively ok with the answer. Ultimately, this product is still my baby and whether or not it's successful is on me. Maybe that's the difference? I'm quite invested in the foundations I laid, and more than happy to help my team work through issues they find in it?