4 ms·

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".

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?

tacitusarc 6y ago
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.
- tonyarkles 6y ago
  > 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.

tacitusarc 6y ago

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.

tonyarkles 6y ago
> 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.