Live data from Hacker News

“Normal” engineers are the key to great teams

spectrum.ieee.org

291–300 of 543 posts

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

#291
post #244

Earlier quoted context omitted.

I say this as someone who loves software: software is not special. Every discipline has infinite depth. Railways in 2D may seem simple but there the simplicity may be intentional. Just like when you write software that runs things like planes, trains, or medical devices, all of a sudden you’re writing in C, without recursion, without function pointers, without using the heap, etc. Look at the concord airplane. A mess…

Not op, but I'm clearly reading their message differently than you. Any type of physical engineering is based on hard facts, data, and well established historical research, mathematics, and more. I've seen many an electrical engineer say, "fuck it, this is too hard and pays too little" and so they pivoted into software engineering quite easily. On the other hand I've never seen the opposite. Real engineering is hard…

How are you reading noosphr’s comments?

I read it as: “software is special because its design space is high dimensional, compared to all other engineering disciplines which are limited to 3 spatial dimensions. Large design space leads to ability to mess things up.”

I wholeheartedly agree with you: “real” engineering (where lives are on the line) is hard. Most software that is made is not to control pace makers, air plane autopilot, space shuttles, etc. When we do need to program in these life and death situations, we should look carefully at the real engineers that do this all the time (looking at you self-driving car software).

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

#292
post #266

Earlier quoted context omitted.

> No, the field grew tremendously and you can see a clear generational bias -- by years of experience, not age -- where the cohort from the last 10-15 years has a completely different understanding of what the craft is I bet a lot of people 10-15 years older than you would say the same thing - except they'd say it about you and your generation. I'm not that old, but I've been around long enough to hear people of ever…

> I bet a lot of people 10-15 years older than you would say the same thing - except they'd say it about you and your generation. And they’d probably be right! I remember the grognards giving me shit about memory management and me giving it right back by explaining that what they considered a large chunk of memory would be worth pennys next year because of Moore’s law and I wasn’t going to waste time considering some…

As a fun anecdote I think this same rationale - ”next years hardware is so much better” - is why so many desktop softwares 90’s->00’s became slow - ”meh you don’t have to care about performance, next year’s cpu is going to be so much faster anyway”.

Then suddenly single threaded speedups didn’t happen anymore (and people realized even though cpu speeds had grown, it was not directly related to Moore’s law).

Ofc your rationale used Moore’s law correctly while the ”cpu infinite speed growth rah rah rah” peoples didn’t.

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

#293

Earlier quoted context omitted.

In my 40 years of professional software development, rarely have I seen such an uninformed post. And ignorant. Did I mention ignorant? I've been the "10x" developer, multiple times. And there certainly are poor performers and exceptional performers, but great teams makes great software, not great individuals. The analogies are numerous. You can look at a great (american) football team and see the Quarterback as the 1…

that's a bad analogy because a single football player cannot ever deliver a match entirely on his own. A single developer can absolutely deliver a full product on his own, it's not inherently a team sport whatsoever. You could make this claim about many things, "blacksmithing is a team sport!" Nonsense.

I think it is more like an NBA situation where a single superstar player can pull up the whole team just look Nuggets but still most likely thing is that the Cavs, Boston, or OCK wins the championship because those teams have a superstar player + a great team.

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

#294
post #286
post #277

Earlier quoted context omitted.

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.

You have ignored my question

“Doing something” is the beginning of how to describe the actual truth of what some actions causes in relation to its affect on reality.

“Supporting something” has literally nothing to do with reality beyond what’s necessary to support a brain that can _intend_ a result or action regardless of what actually happens.

I linked the xkcd comic because the behavior described by the developer in the comic met the criteria for “doing something” but it didn’t meet the criteria for “supporting something” because the behavior of the software was not what the developer intended.

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

#295

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…

Thank you. Every software is essentially being built by a few greats fighting against a dozen morons. 10x doesn't even get close to reality. We're currently in deep shit because a long term dev was under the assumption that you can only instantiate objects once. He built an insanely complex system around the belief, which shipped. Our users used that system to write configuration files that now drive a machine that c…

The skill gradient is steep. Broadly speaking a top quintile dev will have 5-10x the productivity of the median dev, but only 110-150% of their salary. A bottom quintile dev will have zero impact, negative impact, or .1x impact relative to a median. The goal is to have the top quintile for your project, whether that is product engineers working on b2b saas, or graphics devs working on improvements to game rendering.

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

#296

Earlier quoted context omitted.

>Easy to prove, can you think of an engineer that adds negative value? That deletes tests, or breaks stuff? No. Have you really worked with someone that did this and they weren't fired?

Yes. He was the CEO of the company and I have stories that would keep you up at night.

Please share. I can only imagine based on TZubiri’s comments.

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

#297
post #216

Earlier quoted context omitted.

>Once tech [...] started being a source of wealth and power this happened "in the early 2010s"? I don't think so. Software engineers have no power, and in comparison to finance, quite limited wealth.

Out of 10 richest people of the world, 8 have background in software engineering. Musk, Zuck, Bezos, Ellison, Gates, Page, Brin, Ballmer. Only Buffet and Arnault are exceptions.

They are not richest people though, they are biggest public shareholders. Real wealth is always well-hidden.

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

#298
post #151

Earlier quoted context omitted.

No, the field grew tremendously and you can see a clear generational bias -- by years of experience, not age -- where the cohort from the last 10-15 years has a completely different understanding of what the craft is [software engineering vs business development] and how to approach it [optimal solution vs soonest deliverable]. You can also trace personal backgrounds and you'll see a much higher representation in the…

Speaking as an old school basement nerd (coding since middle school, 90’s): If I can do cool things with code _and_ get paid, I’m gonna go do that. Business constraints make it feel much more interesting than writing code in a vacuum. Also money is nice.

> Business constraints make it feel much more interesting than writing code in a vacuum.

You never write code in a vacuum do you? You always have some kind of goal.

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

#299
post #291

Earlier quoted context omitted.

Not op, but I'm clearly reading their message differently than you. Any type of physical engineering is based on hard facts, data, and well established historical research, mathematics, and more. I've seen many an electrical engineer say, "fuck it, this is too hard and pays too little" and so they pivoted into software engineering quite easily. On the other hand I've never seen the opposite. Real engineering is hard…

How are you reading noosphr’s comments? I read it as: “software is special because its design space is high dimensional, compared to all other engineering disciplines which are limited to 3 spatial dimensions. Large design space leads to ability to mess things up.” I wholeheartedly agree with you: “real” engineering (where lives are on the line) is hard . Most software that is made is not to control pace makers, air…

Software "design space is high dimensional" is true in that storage, latencies, processors, memory we just keep growing and growing. Given that, software should be faster and better than ever because the dimension where software lives has gotten exponentially larger and more performant. Rather than use that like responsible engineers we all started writing bloatware because it was easy and we could get away with it.

Engineering with constraints builds discipline. Maybe we are lacking as engineers in software because the constraint bar just continues to raise.

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

#300
post #237

I feel like this article completely misunderstands the point. Their two big arguments are that 1) people aren't 10X at everything, they are at most 10X at specific things and 2) what good is a 10X engineer if they are on a team that can't perform at that level? There isn't something magical about 10X engineers, but the fact is there are engineers who have developed the skills to greatly exceed their peers and work in…

[deleted]
Post reply on HN