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.
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?
There's also the fundamental question of whether or not the expert is actually an expert. It sounds like in the unpleasant case you mention, maybe there wasn't so much expertise there.
I think you're right that having skin in the game is critical. It's important to have real accountability, so if there's painful design flaws, the expert feels it.
But it's easy to think it should have been done differently and better when you don't have the perspective of the designer. I still vividly recall being a junior engineer and thinking the design decisions made by the "expert" were ridiculous, and talking with the expert, and finding out I didn't know everything and I was wrong. Thank goodness he was patient.
> thinking the design decisions made by the "expert" were ridiculous, and talking with the expert, and finding out I didn't know everything and I was wrong
I'm laughing pretty hard at this. The codebase in this current project is definitely a bit... quirkly. It's semi-embedded (Linux on an 8-core ARM unit) and doing high-performance image processing (C++ on Linux). The new guy last month has a fair bit more programming experience than "fresh grad" would lead one to expect, and the first week he had a lot of questions like that.
Him: "Why is it like this? Couldn't we just..."
Me: "Would that keep all 8 cores busy processing things as fast as possible?"
Him: "Oh. Yeah. I guess not!"
Him: "Wait... couldn't we just...hmmm...no... that would serialize everything..."
I suppose one other angle to it is that I don't have a lot of ego in it; if someone figures out a way to squeeze more juice out of the system we've got, they're going to get high-fives.
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.
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?
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.