Live data from Hacker News

In praise of “normal” engineers

charity.wtf

51–60 of 120 posts

Re: In praise of “normal” engineers

#51
post #46
post #27

Earlier quoted context omitted.

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…

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

Pretty much, yeah. Another way of saying this is “perception is reality.”

Everyone has their own perception of reality. As a result some people like you and others don’t. You can choose to perceive those around you as favorably as possible. You control your perception of reality.

It’s similar to this HN guideline:

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

I think this is the defining characteristic of HN that makes it a valuable place to be. It’s a deliberate choice I wish was more widespread.

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

Totally. And you should assume the best about those you manage so you can move them into a position where they can succeed rather than dismissing them for their flaws.

Re: In praise of “normal” engineers

#52
post #37

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…

idk, avoiding landmines seems like pretty significant business impact

it's real impact, but it requires folks to be able to confidently talk about counterfactuals—"we would have wasted X days if not for..."—which I've found to be really hard at most places

the exception was places where leadership already thought in the same terms about software quality/etc, which meant I didn't have to do much convincing :P

how would you build teams or structures to support that sort of holistic thinking about software?

Re: In praise of “normal” engineers

#53
post #33
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?

well obviously there's a ton of variance here. but in the type of engineering i'm most familiar with, any sizable amount of production services or surface layer being owned by a single person is a bad thing.

individuals can get sick, go on vacation, etc. having it be owned by a team creates resiliency from a people perspective.

Re: In praise of “normal” engineers

#54
post #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 c…

[deleted]

Re: In praise of “normal” engineers

#55
post #26
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…

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.

Re: In praise of “normal” engineers

#56
post #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 c…

Why does this read so much like a copypasta.

Re: In praise of “normal” engineers

#57
post #52
post #37

Earlier quoted context omitted.

idk, avoiding landmines seems like pretty significant business impact

it's real impact, but it requires folks to be able to confidently talk about counterfactuals—"we would have wasted X days if not for..."—which I've found to be really hard at most places the exception was places where leadership already thought in the same terms about software quality/etc, which meant I didn't have to do much convincing :P how would you build teams or structures to support that sort of holistic think…

i think it has to start with having engineering managers and directors who are deeply technical themselves. the idea that you can split up this work into "managers do the people stuff" and "engineers do the technical stuff" is bananas. it's all sociotechnical work.

this is why i advocate the engineer/manager pendulum so strongly. we get better results when management has strong tech skills (and staff+ engineers have organizational skills as well).

Re: In praise of “normal” engineers

#58
post #56
post #50

Earlier quoted context omitted.

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

Why does this read so much like a copypasta.

I guess I'm figuring out my voice.

Re: In praise of “normal” engineers

#59
post #25

I tend to think that much of the difference between great and mediocre engineers comes down to mindset. The great engineers I've encountered have a commitment to making everything they touch better. They are adaptable and persevere. They believe they will either succeed at the task at hand or conclusively determine that it isn't possible given the current constraints. They recognize that failure will happen and do no…

Well written, I agree based on my experience that you'll end up being penalized in most places as the one who spends a smidge more time incubating quality work. I really feel this now at my job where not only is the work shoddy as promoted by management, the motivations and ideas behind everything are even worse. I'm talking extreme levels of NIH syndrome. It's upsetting to see something like GraphQL, which could just be a gosh darn HTTP request using off-the-shelf libraries, be turned into this absurd Rube Goldberg machine of custom libraries and bizarre workflows.

Re: In praise of “normal” engineers

#60
post #3

> The best engineering orgs are the ones where normal engineers can do great work I quite like this. It is absolutely true as well, not all teams can be 100% rockstars. How well do you enable the average dev to be good, maybe not GREAT but good and reliable.

Most great engineers were once good engineers. A healthy engineering organization helps its engineers on this path.

yes! love this. and many great engineers will go back to being "good engineers" as they pick up new skills. rinse and repeat++
Post reply on HN