Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In praise of “normal” engineers

charity.wtf

Post reply on HN
Print view View original

91–100 of 120 posts

Re: In praise of “normal” engineers

#91

Post by tikhonj »

FirmwareBurner wrote: post #89
EPWN3D wrote: post #69

Earlier quoted context omitted.

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 c…

> 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 p…

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!

Re: In praise of “normal” engineers

#92

Post by FirmwareBurner »

tikhonj wrote: post #91
FirmwareBurner wrote: post #89

Earlier quoted context omitted.

> 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 p…

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…

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

Re: In praise of “normal” engineers

#93

Post by bsoles »

FirmwareBurner wrote: post #89
EPWN3D wrote: post #69

Earlier quoted context omitted.

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 c…

> 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 p…

> ... you get paid to get the job done, not have pretty code.

Artistic side of the discipline doesn't mean pretty code. It means good design, no rushed spaghetti code, expandable architecture, etc.

"Getting the job done", in manager speak, often means shipping features with awful code behind them, just to give the manager enough time to move up the ladder without suffering the consequences of their awful decisions. With engineers left behind to fix the mess.

Re: In praise of “normal” engineers

#94

Post by bsoles »

athoscouto wrote: post #74
tikhonj wrote: post #14

> The smallest unit of software ownership and delivery is the engineering team. I see where this is coming from, but it's also pretty sad. In my experience, it tends to create environments where engineers are second-class citizens compared to managers or product: we're just responsible for "delivery", but can't independently make any real decisions beyond a tiny scope. Our timespan of discretion becomes measured in d…

Agreed that you can have real individual ownership. Not only that, I think that is the only way to be really "productive". But I think that is beside the point. Individuals are not fungible, but team members are - or at least can be, depending on how you structure your teams. And as your org grows, you want predictability on a team level. Skipping a bunch of reasoning steps, this means having somewhat fungible team m…

I blame Agile and the like for fucking up individual ownership by treating every engineer and every task interchangeable. You can't build expertise by working on a different type of task every sprint...

Re: In praise of “normal” engineers

#95

Post by tikhonj »

FirmwareBurner wrote: post #92
tikhonj wrote: post #91

Earlier quoted context omitted.

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…

>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 incre…

If you have a strong team, you don't have to "enforce" quality. And if you think that quality is "obsessing over standards and guidelines" we're definitely operating in categorically different paradigms.

Re: In praise of “normal” engineers

#96

Post by FirmwareBurner »

bsoles wrote: post #93
FirmwareBurner wrote: post #89

Earlier quoted context omitted.

> 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 p…

> ... you get paid to get the job done, not have pretty code. Artistic side of the discipline doesn't mean pretty code. It means good design, no rushed spaghetti code, expandable architecture, etc. "Getting the job done", in manager speak, often means shipping features with awful code behind them, just to give the manager enough time to move up the ladder without suffering the consequences of their awful decisions. W…

>With engineers left behind to fix the mess.

There would be much less demand for jobs if there were no messes to fix.

Re: In praise of “normal” engineers

#97

Post by bevr1337 »

tikhonj wrote: post #33
spimmy wrote: post #30

Earlier quoted context omitted.

i'm struggling to see how what you are saying you value is any different from what i am saying i value (author here).

possibly we're saying the same things in different ways, or maybe it's just hard to pin the difference down in a words what do you mean by "the smallest unit of software ownership and delivery is the engineering team" in practice? what's the largest scope of work some engineer can do entirely on their own recognizance?

> what's the largest scope of work some engineer can do entirely on their own recognizance?

None. Everything we develop was built on someone else's work. Even when our collaborator is not physically in the room with us, the work is still a collective endeavor.

Re: In praise of “normal” engineers

#98

Post by scarface_74 »

maxsilver wrote: post #55
dkarl wrote: post #26

Earlier quoted context omitted.

People outside of engineering can't give engineers immediate credit for long-term decisions. They don't have the competency to know what to reward. I'd go further and say that even within engineering, people outside of a team can't give immediate rewards for work whose long-term value is internal to the team, for the same reason: they don't know if the work you're doing is actually valuable or is just superficially s…

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

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

Re: In praise of “normal” engineers

#99

Post by [deleted] »

hnthrow90348765 wrote: post #66
tikhonj wrote: post #14

> The smallest unit of software ownership and delivery is the engineering team. I see where this is coming from, but it's also pretty sad. In my experience, it tends to create environments where engineers are second-class citizens compared to managers or product: we're just responsible for "delivery", but can't independently make any real decisions beyond a tiny scope. Our timespan of discretion becomes measured in d…

>we're just responsible for "delivery" Ownership has never gotten me anything but more headache. I'm just here to put the things on the pages. We've got to charge for additional responsibility. Manager/executive pay scales with how many people they're responsible for, no sense in not giving developers that too.

[deleted]

Re: In praise of “normal” engineers

#100

Post by throwanem »

FirmwareBurner wrote: post #96
bsoles wrote: post #93

Earlier quoted context omitted.

> ... you get paid to get the job done, not have pretty code. Artistic side of the discipline doesn't mean pretty code. It means good design, no rushed spaghetti code, expandable architecture, etc. "Getting the job done", in manager speak, often means shipping features with awful code behind them, just to give the manager enough time to move up the ladder without suffering the consequences of their awful decisions. W…

>With engineers left behind to fix the mess. There would be much less demand for jobs if there were no messes to fix.

Oh, certainly. In a world with far fewer failed software projects, it trivially follows that people would want far less software.
Post reply on HN