5 ms·

> They don't have the competency to know what to reward. I'd even take this a bit further, and say this is basically an argument that the engineering manager,

> They don't have the competency to know what to reward. I'd even take this a bit further, and say this is basically an argument that the engineering manager, engineering/dept VP, and CTO all need to be engineers or past-engineers themselves, so they actually do have enough competency to know what to reward.

spimmy 1y ago
just made this exact same point myself, lower in this thread. (author here)
tikhonj 1y ago
the best manager I ever had was a VP who came from a banking background—the key thing was not that he had written a lot of production software himself, but that he had seen what great software looks like (apparently he worked closely with the core Slang/SecDB guys), and was willing to trust engineers who could build similar styles of tools on the other hand, the recent skip-level I had that got me to quit in six months was an engineer himself, but had no real opinion on code quality or anything more than a superficial, process-oriented understanding of the dynamics on the team :( moral of the story: taste is necessary; direct technical experience is mostly necessary, but nowhere near sufficient
- marcosdumay 1y ago
  What you are describing is direct technical experience. That the banker did have, but the one titled as engineer didn't.
EPWN3D 1y ago
Honestly, I don't even think that does the trick anymore. Once you're on the management track, you get infected with the same MBA bullshit as the rest of management, and your brain rewires itself around that culture and those incentives. I've worked for VPs who were former engineers, and they eventually lost their appreciation for the artistic side of the discipline and got obsessed with features, demoes, burn down charts, etc. If you want to solve this problem, you need to keep the professional manager class out of your org. Because once they get a foothold, they fuck everything.
- FirmwareBurner 1y ago
  > they eventually lost their appreciation for the artistic side of the discipline It's easy to obsess with the artistic side of the discipline when you're doing it on someone else's money and assume it's coming from an infinite bag. Once you are a manager and given limited resources to get a job done by a certain date, art goes out the window and it's all about efficiency, you get paid to get the job done, not have pretty code. I think people focusing on SW engineering being art have been spoiled by only working at companies with infinite money, like Google, who treat work as play in hopes that 1 in a million toys will be the next billion dollar idea. But open your own shop, get customers, hire people and let's see how much you'll care about their work being art VS efficient, when it's your dime on the line, then you'll embrace and understand the managerial mindset you've despised.
  - tikhonj 1y ago
    Writing high-quality code lets you get more done faster, with less people. It's not just art for art's sake! That's what drives me crazy about this: you can just be better, it isn't even a tradeoff, but most managers choose to be worse instead. It's been a frustrating thing to talk about. The people who've seen high quality work in action just say "well, obviously it will be faster and more effective", and the people who haven't simply refuse to believe it. It's like there are two incommensurable paradigms around software, and we're just talking past each other :( The best places get a ton done with very few people. Like, XTX has, what, ≈100 engineers? And they're operating a system trading across 35 countries using hundreds of petabytes of data. That's more logical complexity with higher robustness and performance requirements than tech companies with thousands of engineers. And they're not doing this by slinging crap code at the wall as fast as they can!
    - FirmwareBurner 1y ago
      >Writing high-quality code Who defines what "high quality code" is and who enforces it in a team? Because what's high quality to you might not scan to other members of the team, and if you want to your standards across the team then you have to spend time and effort educating the people and enforcing the standards. And now you're wasting time obsessing over standards and guidelines while your efficiency doesn't increase. > you can just be better Better how? >The best places get a ton done with very few people. Is it because the quality of their code, or because those people are better at what they do and better at working as a team? >And they're not doing this by slinging crap code at the wall as fast as they can! Because they're a highly specialized company making a highly niche product who's features must include high tolerance and availability ahead of new features. You can't in good faith compare trading firms to your average web dev shop. different projects, different customers, different budgets and profit margins. That's like comparing an F1 car to a road car and telling the engineers working on the road cars to "just be better", that the reason their work is not matching the F1 car is the quality of their drafting and not the 100x difference in budget and requirements. Edit to reply here to your child comment below: >If you have a strong team, you don't have to "enforce" quality. Obviously you can do a lot with fewer people when you have crazy money and therefore can afford very high hiring bar. That's not most companies and not most SW projects though. Hence my original comment: "I think people focusing on SW engineering being art have been spoiled by only working at companies with infinite money, like Google" Your point only works if you cherry-pick well funded big-tech like XTX, but once you step out of that bubble to non-tech companies who need SW products on smaller budgets things are way different. Those places don't have the hiring bar of XTS, so the quality will be different.
scarface_74 1y ago
The purpose of the engineer is to add business value by either reducing costs or increasing revenue. You reward employees for results.

spimmy 1y ago

just made this exact same point myself, lower in this thread. (author here)

tikhonj 1y ago

the best manager I ever had was a VP who came from a banking background—the key thing was not that he had written a lot of production software himself, but that he had seen what great software looks like (apparently he worked closely with the core Slang/SecDB guys), and was willing to trust engineers who could build similar styles of tools on the other hand, the recent skip-level I had that got me to quit in six months was an engineer himself, but had no real opinion on code quality or anything more than a superficial, process-oriented understanding of the dynamics on the team :( moral of the story: taste is necessary; direct technical experience is mostly necessary, but nowhere near sufficient

marcosdumay 1y ago
What you are describing is direct technical experience. That the banker did have, but the one titled as engineer didn't.

EPWN3D 1y ago

Honestly, I don't even think that does the trick anymore. Once you're on the management track, you get infected with the same MBA bullshit as the rest of management, and your brain rewires itself around that culture and those incentives. I've worked for VPs who were former engineers, and they eventually lost their appreciation for the artistic side of the discipline and got obsessed with features, demoes, burn down charts, etc. If you want to solve this problem, you need to keep the professional manager class out of your org. Because once they get a foothold, they fuck everything.

FirmwareBurner 1y ago
> they eventually lost their appreciation for the artistic side of the discipline It's easy to obsess with the artistic side of the discipline when you're doing it on someone else's money and assume it's coming from an infinite bag. Once you are a manager and given limited resources to get a job done by a certain date, art goes out the window and it's all about efficiency, you get paid to get the job done, not have pretty code. I think people focusing on SW engineering being art have been spoiled by only working at companies with infinite money, like Google, who treat work as play in hopes that 1 in a million toys will be the next billion dollar idea. But open your own shop, get customers, hire people and let's see how much you'll care about their work being art VS efficient, when it's your dime on the line, then you'll embrace and understand the managerial mindset you've despised.
- tikhonj 1y ago
  Writing high-quality code lets you get more done faster, with less people. It's not just art for art's sake! That's what drives me crazy about this: you can just be better, it isn't even a tradeoff, but most managers choose to be worse instead. It's been a frustrating thing to talk about. The people who've seen high quality work in action just say "well, obviously it will be faster and more effective", and the people who haven't simply refuse to believe it. It's like there are two incommensurable paradigms around software, and we're just talking past each other :( The best places get a ton done with very few people. Like, XTX has, what, ≈100 engineers? And they're operating a system trading across 35 countries using hundreds of petabytes of data. That's more logical complexity with higher robustness and performance requirements than tech companies with thousands of engineers. And they're not doing this by slinging crap code at the wall as fast as they can!
  - FirmwareBurner 1y ago
    >Writing high-quality code Who defines what "high quality code" is and who enforces it in a team? Because what's high quality to you might not scan to other members of the team, and if you want to your standards across the team then you have to spend time and effort educating the people and enforcing the standards. And now you're wasting time obsessing over standards and guidelines while your efficiency doesn't increase. > you can just be better Better how? >The best places get a ton done with very few people. Is it because the quality of their code, or because those people are better at what they do and better at working as a team? >And they're not doing this by slinging crap code at the wall as fast as they can! Because they're a highly specialized company making a highly niche product who's features must include high tolerance and availability ahead of new features. You can't in good faith compare trading firms to your average web dev shop. different projects, different customers, different budgets and profit margins. That's like comparing an F1 car to a road car and telling the engineers working on the road cars to "just be better", that the reason their work is not matching the F1 car is the quality of their drafting and not the 100x difference in budget and requirements. Edit to reply here to your child comment below: >If you have a strong team, you don't have to "enforce" quality. Obviously you can do a lot with fewer people when you have crazy money and therefore can afford very high hiring bar. That's not most companies and not most SW projects though. Hence my original comment: "I think people focusing on SW engineering being art have been spoiled by only working at companies with infinite money, like Google" Your point only works if you cherry-pick well funded big-tech like XTX, but once you step out of that bubble to non-tech companies who need SW products on smaller budgets things are way different. Those places don't have the hiring bar of XTS, so the quality will be different.

scarface_74 1y ago

The purpose of the engineer is to add business value by either reducing costs or increasing revenue. You reward employees for results.