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

“Normal” engineers are the key to great teams

spectrum.ieee.org

Post reply on HN
Print view View original

281–290 of 543 posts

Re: “Normal” engineers are the key to great teams

#281

Post by chamomeal »

superconduct123 wrote: post #24

I think 10x is an exaggeration but I've found its really common to have 1-2 people who do a big bulk of the work The thing I don't understand personally with these people is why they care so much about work when the rewards are not proportionate to doing so much extra work. I get it if you're a founder of a startup but not if you're at a big company Yet every big company I've worked at there are always 1-2 people on…

This dynamic is hard to avoid. If you have 1 or 2 people who have more institutional knowledge than the rest of the team, they can burn through more tickets and gain more knowledge through exposure to other people’s problems, which they help with. Then everybody ends up relying on the “hero”, and nobody is really happy about it.

That’s my experience, at least. Cleaner code, separation of responsibilities, and good documentation seem to help though. But I do think a lot of the time people are mistaking “more productive developers” with “devs who got stuck with knowing all the random shit that our horrible codebase relies on” lol

Re: “Normal” engineers are the key to great teams

#283

Post by al_borland »

0xB31B1B wrote: post #117

I could not disagree more with nearly everything in this article. Individuals ship software not teams, unless you are pair programming. Nearly all complex technical projects are owned by one super smart person (Ex: linux). You don't need to have a scientific measurement of productivity to know that in your median team of 12 there really are 2 people carrying the water for everyone else. A players hire A players, B pl…

In a lot of cases, some of those who carry all the water are doing it to themselves, and it hurts the team (and themselves).

In the organization I work in we have an operations team to take care of day to day failure. Write a run book, set up ticketing, hand it off, good to go. I treat this work and hand off as a high priority, as it frees up my time to work on other things. The ones who are chronically busy and appear to be “carrying the water” don’t do it. Their time is dominated my support, they are constantly busy, and it looks like they are doing a lot… but they’re doing work that can and should be handed off.

I’ve been the water carrier as well, but always tried to skill up people any time I had the opportunity. Or I’d build tools to make it easier for people to help, or find a niche where they could be useful doing something that would really improve things that I either didn’t have the time or interest for.

Re: “Normal” engineers are the key to great teams

#285

Post by nodoll »

So I think the title of this post is a bit off. The article is not saying "Normal" engineers are better than 10x. But your organization should not be depending on the 10x to operate, and it should work well with "normal" engineers.

And the key to great teams and organization is the "process", and not the presence of specific, 10x people.

But that means in such an org, you are just a replaceable cog. So from the point of a 10x engineer, you absolutely want your org to be dependent on you.

Re: “Normal” engineers are the key to great teams

#286

Post by TylerE »

lovich wrote: post #277
TylerE wrote: post #233

Earlier quoted context omitted.

Were they actually supporting abbreviating or just doing something like only storing the first 3 characters of the name? That feels more like something a compiler trying to fit in 8k of RAM or whatever would do.

Is there a difference between doing something and supporting something? This joke is like a decade old at this point https://xkcd.com/1172/

Well, yes.

Namely, what does the following code do?

    patients = 400
    patents = 20
    x = patients / 10
If the compiler truncates, x will be 2 (assuming it allows variable reassignment), and you've probably introduced at least two bugs. It's doing some sort of lookup against the source, well, all bets are really off.

Re: “Normal” engineers are the key to great teams

#287

Post by sibeliuss »

This is such a terribly dumb and worn out trope.

Good leaders are the key to great teams. Good leaders know how to deal with excessively productive people, and underperforming people, and to harmonize them. A 10x engineer under good management will actually distribute their weight to others, and meet the definition. Without that they're just one highly skilled engineer, engineering.

Re: “Normal” engineers are the key to great teams

#288

Post by TylerE »

throwaway2037 wrote: post #272
TylerE wrote: post #234

Earlier quoted context omitted.

Just to be clear, do you mean full-dogma Rails tutorial write a bunch of trivial tests before writing code TDD?

Yes, exactly this. I never bought into TDD, but I can understand that it brings comfort for many normie enterprise CRUD developers... of which I am one myself!

I despise it because I've seen some absolutely HORRIBLE designs that excessively separate concerns (that are actually linked and shouldn't be) in the name of "testability". I would rather maintain 50 lines of clear idiomatic code than 1000 lines of TDD code salad full of 3 line functions that each take a bunch of fragile mocks.

It's also my experience that a few well written integration tests are more useful and catch more actual bugs than a million unit tests. This is especially true of web apps which are inherently highly stateful.

The most powerful design paradigm I have ever found is to spend the first, say, 10-20% of my time making a rough prototype. Not with an eye of actually using a single line of it (although it happens) but just to do the quickest and dirtiest possible exploration of what the actual problem is.

Re: “Normal” engineers are the key to great teams

#289

Post by hot_gril »

alexathrowawa9 wrote: post #98
namuol wrote: post #93

Earlier quoted context omitted.

Once you’re paid some minimum threshold you stop caring about money and start caring about your legacy.

Ah yes, my legacy: UserOAuthLoginProfileAPIService

// TODO: migrate to UserOAuthLoginProfileAPIService2 by Wednesday

Re: “Normal” engineers are the key to great teams

#290

Post by AxEy »

noosphr wrote: post #51
jaggederest wrote: post #5

I like this article particularly because I think the trope that there's something unique and different about software engineering is pretty toxic, both to we people in the field and people looking to employ people in the field. These days it feels a bit like another well known toxic field, finance, in that people conflate an outsized leverage for personal valor. It's laudable to do your work well and go home to the r…

Software is different. All other engineering disciplines are ultimately limited to building things in (at most) 3 euclidean dimensions. There is only so much junk you can hide in a finite volume of space. Code by comparison lives in hyperbolic space [0] and you can hide _anything_ in such a space without it being obvious. This is exemplified by the unpleasant discovery all of us have had of a supposedly peripheral fo…

>There's the folklore about half of all math papers giving the wrong proof for the right conclusion.

Sorry, what? This is an extraordinary claim.

Post reply on HN