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

451–460 of 543 posts

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

#451

Post by jhanschoo »

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…

Software is different.

Software is ultimately limited to building things in a space that is only countably infinite. There is only so much junk you can hide in a space that is only countably infinite.

All other engineering disciplines by comparison deal in a space that is uncountably infinite 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 measurable "collection" of intervals having such weird holes all over the real number line and the near impossibility of shifting it up or down that makes sense for it without having to rethink our whole notion of measure and still end up with something like the counting measure that definitely doesn't make sense.

People, including myself, have a seriously bad intuition just how much volume there is in an uncountably infinite space.

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

#452

Post by dilyevsky »

paxys wrote: post #436
breadwinner wrote: post #406

The flaw in this article is the assumption that 10x engineers are just more productive, and several "normal engineers" can do the work of a 10x engineer. This may be true if you're building "normal software". But for certain kinds of software development, a team of "normal engineers" can't do what a single 10x engineer can do. For example, how many "normal engineers" would you need to replace an Ilya Sutskever? The a…

How many companies out there genuinely need an Ilya Sutskever to achieve their goals? Everything in this article is accurate for the 99.9% of companies and teams that aren't working at the bleeding edge of the industry. The mythical "10x engineer" is always a net negative on teams building a boring CRUD app. You always want a handful of "normal" engineers instead.

Author spent a lot of time mulling over “world class” this or that. World class engineers working on crud sounds like an oxymoron

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

#453

Post by dilyevsky »

beastman82 wrote: post #14

Every 10x engineer I've known has carried entire teams of normal engineers. ymmv but I've seen probably 5 instances of this and 0 instances of teams of normal engineers being super productive.

Oh they are super productive alright when you measure by story points just not in any revenue/profit impacting sense

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

#454

Post by dilyevsky »

earthnail wrote: post #392

The thing that bugs me with this article is that a lot of regular software engineering is plagued by a lack of ambition. 10x engineers bring that ambition (I hate the term 10x, but let's just stick with it). Because of the scaling effects in software, if you work on the right project, that ambition can significantly increase your impact on the market/world/field you're working in. The costs associated to managing tea…

A small team of skilled engs hurts managers’ careers - they want large teams

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

#455

Post by godelski »

Swizec wrote: post #417
Aeolun wrote: post #298

Earlier quoted context omitted.

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

I don’t know dude, this one time I wrote a LOLCODE compiler into a Babel macro. https://swizec.com/blog/lolcodetojavascript-compiler-babel-m... It was pretty fun. Also this other time I wrote a nodejs script to keep my computer at a specific temperature because our office fridge kept freezing my carrots. https://swizec.com/blog/i-built-a-node-app-to-thaw-my-favori...

  > because our office fridge kept freezing my carrots.
That sounds like a goal to me

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

#456

Post by bdangubic »

earthnail wrote: post #392

The thing that bugs me with this article is that a lot of regular software engineering is plagued by a lack of ambition. 10x engineers bring that ambition (I hate the term 10x, but let's just stick with it). Because of the scaling effects in software, if you work on the right project, that ambition can significantly increase your impact on the market/world/field you're working in. The costs associated to managing tea…

you are making a whole lot of assumptions here that might be true in your experience but might be far from truth as a whole. over the almost 3 decades hacking I have had the pleasure of working with many 10x-ers and all but one were the least ambitious people you will ever meet. not sure how you can in general relate someone being awesome at what they do with being ambitious?

the winner-takes-all dynamics also would be such a terrible place to work, “the winner” is seldom-to-never a person actually doing the work but VCs and owners and… what is my ambition here? maybe minority in USA but people do not define their lives by their job, it is means to an end. go to work, do your job and then head home for important parts of life. I have always looked for meaningful work that matters and have largely succeeded later in my career but none of that success had anything to do with ambition.

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

#457

Post by alienthrowaway »

handwarmers wrote: post #433
gilbetron wrote: post #192

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…

The big question is, can we find counterexamples to your model of reality in actual reality. And if we can easily do that, what does your apparent over-confidence about your statement say about you? E.g. https://bellard.org/ To add to the insult, I'd challenge you to think of how many "great teams" of "normal" engineers, whatever any of these terms means, could pull off most of these projects in any amount of time. G…

Fabrice Bellard is not a counterexample you think he is. He is brilliant, but he doesn't stick around the projects he starts off. Someone has to triage bugs, setup CI, tag releases, keep the website running and all the other boring stuff.

I have contributed to one of the projects he originally authored, and my mundane contributions along with other volunteers not as brilliant as him have ensured the continued success of the project. I'm with gp: teams ship software, not individuals. Individuals may ship bug-fixes or largish features, but for software in the large, that is the realm of teams.

I've been there & done that: I've been the person that crunches and turns around impossible situations, and I have also spent months cleaning up after a 10x engineer who shipped a feature in "record time" that made the company lots of money but caused countless support calls and bugfixes for months on end until it stabilized. Many so-called 10x aren't, and rely a lot on a supporting cast of regulars to enable their "outstanding" work

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

#458

Post by alienthrowaway »

0xB31B1B wrote: post #307
noisy_boy wrote: post #197

Earlier quoted context omitted.

Every team doesn't need to have "great" engineers; I don't want "clever" solutions to my bog standard business application, just people to write sane, clean and maintainable code.

This might be a definitions issue, but my assertion is not that a "great engineer" is someone who can complete leetcode hards in 15 minutes for 8 hours in a row without stopping. My assertion is that about 1 in 5 people have 5-10x the business impact of the median software developer, and if you are recruiting or managing a team you should have the goal of having your team be entirely composed of these top quintile fo…

Some years ago, Google published a paper whose conclusion was that high-trust teams were the most productive - not the ones with the 10x developers. This obsession with the "great man" theory as applies to software is harmful to software engineering.

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

#459

Post by magicalist »

noosphr wrote: post #79
tkahnoski wrote: post #72

Earlier quoted context omitted.

I think maybe this misses the mark. Yes software can lead to unbounded complexity unlikely many physics based engineering disciplines. However, at the end of the day, there is an input and output and compute and memory needed to run the thing and if we look at that we realize, we never actually left the bounded physical realm and we can still engineer software systems against real world constraints. We can judge its…

>However, at the end of the day, there is an input and output and compute and memory needed to run the thing and if we look at that we realize, we never actually left the bounded physical realm and we can still engineer software systems against real world constraints. We can judge its efficiency and breaking points. This is a common sense view of computation that's unfortunately wrong. The simplest counter example is…

And then you quickly find out that the turing machine on your lap doesn't actually have infinite tape. Do you honestly believe that there's no other human endeavor where you can DoS yourself?

If on the other hand you're speaking of the theoretical computational needs of the program you just wrote, then your earlier dismissal of mathematics and its "even worse track record" is all the sillier.

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

#460

Post by godelski »

sumtechguy wrote: post #395
lovich wrote: post #266

Earlier quoted context omitted.

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

You both are right. But ignore memory at your peril. I have one proj that has a 256GB instance. For a fairly boring CRUD app. I am asking a lot of questions as apparently we are having the yearly 'we need more memory' questions. Things that are leading to speedups. Just by using less memory. At the bottom of that stack is a L1 cache with less than a hundred KB. It doesnt matter right up until it does. I have seen hug…

I definitely agree with the greybeards and I think we see the results of not listening to them. We have these processors, buses, networks, and all sorts that are magnitudes faster and more powerful than what they began on but many things are quite slow today. Worse, it seems to but getting slower. There is a lot of value in learning about things like caching and memory management. A lot of monetary value. It's amazing to me that these days your average undergraduate isn't coming out of a computer science degree being well versed and comfortable writing parallelized code, given that is how the hardware has moved. It is amazing to me we don't normalize caching considering a big change that was driven from the mobile computing side and adopted into our desktop and laptop environments is to fill ram because you might as well. It is crazy to me that we have these games that cost hundreds of millions of dollars to develop that are buggy as shit, hog all the resources of your machine, and can barely run at 4k60. Where you can hit a bug and go "yep, I know what's causing that memory error"

Honestly, I think so much of this comes from the belief of needing to move fast because. Because why? That would require direction. I think the money motivation is motivating speed but we've lost a lot of vision. Moving fast is great for learning but when you break things you got to clean it up. The problem is that once these tech giants formed they continued to act like a scrappy developer. To not go back and fix all the mess because we gotta go fast, we gotta go forward. But with no real vision forward. And you can't have that vision unless you understand the failures. We have so many low hanging fruits that I can't figure out why they aren't being solved. From deduplicating calendar entries, automatically turning off captioning on videos when a video has embedded captioning so you don't just overlay text on top of text, searching email, or even setting defaults to entry fields based on the browser data (e.g. if you ask for user's country, put the one the browser is telling you at the top of the fucking list!). These are all things I think you would think about if you were working in a space where you needed to consider optimization, if you were resource constrained. But we don't and so we let it slide. But the issue is a death by a thousand cuts. It isn't so bad in a few cases but these things add up. And the great irony of it all is that scale is what has made tech so powerful and wealthy in the first place. But no one stops to ask if we're also scaling up shit. If you printing gold but 1% of your gold is shit, you're still making a ton of shit. The little things matter because the little things add up. You're forced to deal with that when you think about memory management but now we just don't

Post reply on HN