4 ms·

I managed a 250 person engineering team at FANG. The number of times I had to explain to a jr or mid level engineer what our fundamental business was, was asto

I managed a 250 person engineering team at FANG. The number of times I had to explain to a jr or mid level engineer what our fundamental business was, was astounding. They would constantly argue tickets on a premise that was entirely self contained inside their code -- and be entirely oblivious to what the product was accomplishing outside in the real world with real users. Now this wasn't always the case, and frankly I ran into it much less there than I had at smaller companies. But it still happened a lot. And these engineers would always boast the most about how they knew best about X or Y. Maybe that was my fault as a leader -- but I couldn't fix the incurious.

jayd16 3y ago
The disconnect is that both sides are valid. User value is important, but stability, opportunity cost, and ROI also provide user value. It's not valid to say that the realities of the current code base are irrelevant just as much as it's invalid to say clean code always trumps features.
- tsunamifury 3y ago
  That’s actually not true and this is the mistaken idea engineers have. It’s not a negotiation. User value that translates to business goals strictly always trumps internal code. Or you don’t have a business to fund that code. You find a way to do it if you need to fund the business. If not your are sunk.
  - rcbdev 3y ago
    I agree with you to some extent, but if you go with this line of thinking consequently then things of no apparent "User Value" (say, a code base not riddled with technical debt) never gets any budget or attention in favor of shoehorning in more shiny stuff of obvious value. What this then leads to is borderline unmaintainable code because the project managers, software architects, etc. rarely touch the IDE anymore and the more junior people can't or won't articulate the issues they are having. (i.e. a feature made tests 10x slower, a hastily added API times out often locally, etc.) This then leads to people jumping ship every 1-2 years, low productivity and bad implementations. All in the name of precious User Value!

jayd16 3y ago

The disconnect is that both sides are valid. User value is important, but stability, opportunity cost, and ROI also provide user value. It's not valid to say that the realities of the current code base are irrelevant just as much as it's invalid to say clean code always trumps features.

tsunamifury 3y ago
That’s actually not true and this is the mistaken idea engineers have. It’s not a negotiation. User value that translates to business goals strictly always trumps internal code. Or you don’t have a business to fund that code. You find a way to do it if you need to fund the business. If not your are sunk.
- rcbdev 3y ago
  I agree with you to some extent, but if you go with this line of thinking consequently then things of no apparent "User Value" (say, a code base not riddled with technical debt) never gets any budget or attention in favor of shoehorning in more shiny stuff of obvious value. What this then leads to is borderline unmaintainable code because the project managers, software architects, etc. rarely touch the IDE anymore and the more junior people can't or won't articulate the issues they are having. (i.e. a feature made tests 10x slower, a hastily added API times out often locally, etc.) This then leads to people jumping ship every 1-2 years, low productivity and bad implementations. All in the name of precious User Value!