Live data from Hacker News

In praise of “normal” engineers

charity.wtf

41–50 of 120 posts

Re: In praise of “normal” engineers

#41
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…

I used to share this mindset, and I still agree that individual ownership is possible for engineers. Unfortunately many, many engineers simply do not want it. I would reckon most if not all engineers are comfortable with ownership at the team boundary, but many simply do not care beyond that. It's just a day job.

Individual ownership at the individual engineer boundary can breed distrust within a team or org, but often alienates team members who like their job but aren't trying to lead, at least with respect to what ownership entails. In this blended environment someone almost always ends up without agency. Sometimes no one gets agency. Who wants that?

It's surprisingly simple and effective by comparison to give a team agency and ownership, usually in part because of the dynamic of having a manager or lead to begin with.

Simply put, there are too many modes of failure at the individual level for software ownership to settle there comfortably: staffing changes, job security, career growth are the obvious ones, but the dysfunction (even in otherwise healthy orgs, there's always some amount) will find the shortest path to complete the circuit here.

I like to think of it like a gearbox. If you only have one gear, and you break it, or wear out all the teeth, then you don't get to go. If you have many gears, well, the ride may be uncomfortable at times, but you'll keep moving.

Re: In praise of “normal” engineers

#42
> Are you using golang, python, COBOL, lisp, perl, React, or brainfuck?

For years now I had this feeling that people confuse React with the entire frontend ecosystem, but dismissed it thinking that surely they're aware that there's a whole world of non-React frontend out there?

Re: In praise of “normal” engineers

#44
post #34

Some good points, bad logic. The fact that you can't effectively measure something doesn't mean that something doesn't exist. Individual productivity exists. Maybe it's easier to measure groups' productivity? Probably. "Business impact"? I don't think so, that later concept seems much more arbitrary. But feel free to look for the keys under the lamplight. If you choose that metrics, you're not going to retain many ex…

A real genius can often explain their work without being an asshole, I think. So it’s fairly straightforward to tell the difference.

Re: In praise of “normal” engineers

#45
> someone who is a 10x engineer in a particular skill set is still going to have infinitely more areas where they are normal

Yep. I’ve been here for a career or so with moments of brilliance and marathons of mediocrity, but consistent kindness (I hope).

Re: In praise of “normal” engineers

#46
post #27

Earlier quoted context omitted.

> People simply don’t like each other this seems like an insane statement to me, you can just hire for ability to function in a team?

One of the most contentious disagreements between myself and my current manager is that I say we should trust our peers to do good work and enable them with that fundamental assumption in mind. IMHO if you assume the people around you are incompetent or malicious then that’s exactly what you’ll find. Further, if the people around you are actually incompetent or malicious then awareness of that fact won’t change the o…

IMHO if you assume the people around you are incompetent or malicious then that’s exactly what you’ll find.

What are you implying, that you are some kind of God? So if you see them as bad, often bad appears, and if you see them as good, then often good appears? That's some magical stuff there.

Further, if the people around you are actually incompetent or malicious then awareness of that fact won’t change the outcome anyway.

True. But we're here talking about managing serious operations, in which case being keenly aware of the above fact helps make decisions and they don't all have to be "evil" decisions and can often be quite beautiful solutions. You can reallocate people to optimize them without firing them, feeding one more person.

Re: In praise of “normal” engineers

#47
post #34

Some good points, bad logic. The fact that you can't effectively measure something doesn't mean that something doesn't exist. Individual productivity exists. Maybe it's easier to measure groups' productivity? Probably. "Business impact"? I don't think so, that later concept seems much more arbitrary. But feel free to look for the keys under the lamplight. If you choose that metrics, you're not going to retain many ex…

the real problem is not that we can't measure productivity, but that we can't even fully define an abstract productivity metric—what does "productivity" even mean?

we can come up with some notion that talks about the net effect of an individual (the "wins about replacement" of programmers), but that tells us absolutely nothing about how any given individual achieves that; hell, the net effect of any given individual is presumably a function of the entire context and the rest of the org, not just of the individual!

alternatively we can try to define more direct notions of "productivity" even if we can't measure them, but those notions end up varied, multidimensional and, again, painfully context-specific—it's absolutely a useful thing to think about, but it does not let us pin down what a "top 1%" engineer "really" is, or even if that's a meaningful notion

Re: In praise of “normal” engineers

#48
post #5

There are large parts of this I really like, but it's hard to overstate just how much I disagree with the idea that "The only meaningful measure of productivity is impact to the business". The natural result of this view is a focus on quantifiable changes and short term thinking. The greatest value of experienced engineers is in avoiding landmines that will destroy a project or even a company. It's difficult to quant…

“Impact on the business” isn’t inherently a short term viewpoint. Maximum impact is a long term proposition.

It's not inherently a short term viewpoint, that's just the typical and natural result of adopting this view. Measuring long term impacts is hard. Attributing them is even harder.

Here's a real scenario. I worked for a company that evaluated by impact. They had a cellular modem with known issues in the field. A replacement was designed to fix those issues, but couldn't be backwards compatible. The cost to immediately upgrade the field units was high, so deployment was delayed to a cheaper, later time. One way of looking at this is that the decision saved millions of dollars and that argument was made. After the evaluation and before the deployment, a set of older field units failed in such a way that it made headlines across the country, which would have been prevented by the new units.

So, was the impact of those decisions negative the whole time in an unknowable way? Did their impact become negative as soon as the incident occurred? If the incident was still possible but hadn't occurred, would the impact be different?

People aren't good at evaluating things that haven't happened yet, so they'll tend to focus on the things they can see immediately in front of them. That incentivizes engineers to build things that have immediate short term impacts and discount long tail risks which can't be reliably evaluated.

Re: In praise of “normal” engineers

#50
post #36

I saw a post like this some time earlier this year and my first reaction is the same… Normal? Seriously? The article attempts to address this in an incredibly clumsy way by saying, well, everyone is normal in some way! It totally misses the mark and basically pays lip service to the issue after it set the stage, switching over to bigger picture diversity. Benefit of the doubt, the intention is to say ‘average’. The p…

Once someone(s) pay a lot of money for something, they will always be critical of it. They literally bought the thing. You don't think I'd write articles about the pros/cons coulda/shoulda/woulda if I paid $180k for a car?

A lot of businesses are truly poor and cannot afford buying the things they buy (in this case, it's people). Then the people have to go through their horrible post-mortem analysis. Build your own company, write your own shit, and stop analyzing how to min/max a person that was out of your league to begin with (never even in your price range comfortably, now shut up with what could have been done better).

If for whatever reason the above paragraph addressed businesses that were rich, well then, I have nothing to really say about that, because in that case we're dealing with a monstrosity for which there are no words.

Post reply on HN