431–440 of 543 posts
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…
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…
i think your flaw is conflating scientific research with software engineering
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 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…
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.
Great professionals exist. They produce great work that is tough to reproduce. Your "helping" them does not mean they couldn't have done it without you.
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…
People that stopped running tests because they were configured to make 10,000 API calls in one minutes and it crippled the app until everything was restarted.
"Add some more memory to your database instance....poof"
Earlier quoted context omitted.
i think your flaw is conflating scientific research with software engineering
There are plenty of hard problems that are unrelated to scientific research where you need more than just "normal" engineers. Look at the number of failed projects at big companies such as Amazon and Microsoft, they failed because "normal" engineers couldn't pull it off.
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…
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…
This comment is spot on. I would add that it's not only 1 super smart person, or only 2 people per team, it's a power law. 1 person does the most, a few people do almost as much, then you start getting out into the tail of "normal" people. You can try to hard partition the tail and create an 80/20 rule, but it's fundamentally continuous, and the shape parameter will be different for each organization. Understanding t…
Indeed this is one of the hard problems for a manager.
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.
A great engineer isn't the one writing the most "brilliant" code; it's the one who understands the problem, picks the simplest solution that works, and makes life easier for the next person who touches it.
Which is why I have learned to stay away from people who use that metric.
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…
Your post is super offsensive. And true. The number of times I've reviewed someone's code that's been "in progress" for 3 weeks, to see it's 200 lines of simple python code... ugh " oh, but it was really actually complex and you just don't get it " --> Incorrect
Which is completely wrong.
When did IEEE become host to clickbait nonsense? This whole take feels like an editorial by a junior engineer going off vibes. It's all off-base, from the misunderstanding of how to measure productivity, to what output matters, to the idea that there is such a thing as a "normal" software engineer. It's kind of embarrassing.
Exactly.
I think i'll never click on an IEEE Spectrum article again.
IEEE has jumped the shark.