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

71–80 of 120 posts

Re: In praise of “normal” engineers

#71

Post by commandersaki »

paxys wrote: post #12

There are plenty of good "normal" engineers whose abilities top out at following direction from management, implementing a spec (albeit really well), adding to an existing architecture etc. I'd wager the vast majority of the industry falls into this category. Yes, it's very important for an org to ensure that these kinds of engineers are successful, because they are the workhorses of your company and without them not…

10x engineer in the original sense to me is simply someone that 10x-es your company in some way. Maybe Avie Tevanian who brought Apple OSX/etc. or Andy Rubin who brought Google Android.

Re: In praise of “normal” engineers

#72

Post by Jensson »

spimmy wrote: post #53
tikhonj wrote: post #33

Earlier quoted context omitted.

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.

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

Resilience against what? It isn't like teams make decisions quickly, an individual will get decisions done faster in almost every case, and if they are on leave right now its just slightly slower than a team.

For example, if you ask a team "can you get this feature in", likely they will come back at you a few weeks later. That isn't faster than an individual on leave, so I don't see what "resilience" even is here.

Re: In praise of “normal” engineers

#73

Post by [deleted] »

narag wrote: 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…

[deleted]

Re: In praise of “normal” engineers

#74

Post by athoscouto »

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 members, to give you redundancy.

The engineering parallel here is the tradeoff between resilience and efficiency. You can make a system more reliable by adding redundancy. You make a system more efficient by removing redundancy.

Re: In praise of “normal” engineers

#75

Post by karmakaze »

spimmy wrote: post #53
tikhonj wrote: post #33

Earlier quoted context omitted.

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.

For most teams that I've worked in, I've chosen certain parts to guard and nurture into a better state. I'll recognize certain shortcomings that have a real-world negative impact and incrementally nudge the design and future decisions in that direction. At some point it will have arrived. Eventually people that are in non-adjacent teams gets to know that I'm the XyzService person. I do socialize the design and implementation changes and even distribute the work and write up thought/decision processes for the team to see. I'll eventually run out of challenging work and move on to another sore area with the team well capable of managing what they've got. If the process were to be interrupted at any time, it's generally not in any worse shape than it started, only failing to reach the desired end improvements.

Edit: My current pet project is eliminating a bad DSL which has led to so many bad implementations and near-identical but different copies because factoring aspects isn't well supported. I started with a PoC, then a Hackdays project, and now with that looking good, the team is willing to convert all of the codebase we maintain so that we can use normal programming language features like static typing and source navigation with easy to follow data flows.

Re: In praise of “normal” engineers

#76

Post by eikenberry »

xyzzy_plugh wrote: post #41
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…

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

In my experience this is mostly big-company vs. small company cultural differences due almost strictly to size and scaling. Small companies work best when individuals have ownership and large companies with team based ownership. They attract culturally like-minded people.

Re: In praise of “normal” engineers

#77

Post by JohnMakin »

> Any asshole can build an org where the most experienced, brilliant engineers in the world can build product and make progress. That is not hard. And putting all the spotlight on individual ability has a way of letting your leaders off the hook for doing their jobs. It is a HUGE competitive advantage if you can build sociotechnical systems where less experienced engineers can convert their effort and energy into product and business momentum.

This hits close to home for me recently. I don't profess to be a 10x engineer, but I found myself on a team with a few people with much less experience and competence than I am normally accustomed to. I started getting every single ticket with any kind of complexity, because I could get it done, and some people on my team couldn't. I could have continued this way, contributing a massive percentage of the output and claimed to be superior to everyone - but the reality is, for me anyway, this is exhausting (and feels really unfair). Plus I am a little lazy (as I believe all good sysadmins/sre's/ops guys are). I want my team to help me. So what I did was work extra for a few weeks and wrote a ton of abstractions over the most complex stuff we do (I dont write software, I write IAC, I'm aware this is a common pattern in software engineering) so that the less knowledgeable engineers could do the work I'd been doing much of. It freed my time up to work on more interesting problems. This was the first time in my career I had to do this without anyone already ordering me to.

I've been on teams where there was someone like me and everyone else was running around behind them frantically trying to keep up or cleaning up the inevitable tech debt that accumulates. It's miserable and really inefficient.

Re: In praise of “normal” engineers

#78

Post by MontyCarloHall »

tikhonj wrote: post #7

I definitely agree that the best teams have cultures that make even normal engineers incredibly effective compared to the status quo. Managers definitely put too much stock in hiring and "engineering quality" compared to culture, trust, systems and processes. > Any asshole can build an org where the most experienced, brilliant engineers in the world can build product and make progress. But I have to wonder: if "any a…

> But I have to wonder: if "any asshole" can build orgs like that, why don't they?

Other posters have said money, but it’s also a function of time—how long can a company afford to wait to find the perfect “unicorn” engineer who excels in every aspect of the product but may take a long time to hire, versus hiring someone whose expertise only covers some of the product’s needs but can be found immediately?

Certain companies benefit disproportionately from unicorns, especially those in interdisciplinary fields. For instance, in quantitative finance, a single individual who’s an excellent 1. systems programmer, 2. mathematician, and 3. financial market expert will contribute a lot more than a team of three specialists in each of those domains. But it’s a lot faster to hire that team of three versus finding the rare individual who can supplant a whole team. This is also true in less exotic fields—it’s rare to find someone who’s truly a “full stack” web developer, with a deep understanding of networking protocols and Linux system administration and (cloud based) distributed systems and databases and caching services and frontend development & cetera. But the company that can afford the money and time to find these people will make a much better product than the company that cannot.

(Whether the product actually needs the quality commensurate with all that engineering firepower is an entirely other question.)

Re: In praise of “normal” engineers

#79

Post by closeparen »

spimmy wrote: post #53
tikhonj wrote: post #33

Earlier quoted context omitted.

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.

We have a pretty strong culture of individual ownership, but each owner has at least one other person reviewing their PRs, usually several junior engineers contributing, design review at the team level, and oncall at the team level.

When the owner is away, the other people involved keep things moving. If they're away long-term or leave the company, we'll designate someone else to take ownership.

Re: In praise of “normal” engineers

#80

Post by alexandre_m »

> When your teams are used to operating with a mix of genders, racial backgrounds, identities, age ranges, family statuses, geographical locations, skill sets, etc — when this is just table stakes, standard operating procedure — you’re better equipped to roll with it when life happens.

Resilience doesn’t come from having a “diverse” team on its own. What a shallow take.

True resilience comes from mature teams with strong processes, clarity of roles, and the ability to adapt and recover effectively.

Post reply on HN