191–200 of 248 posts
Like so many discussions that bring out the same old discussions year after year, this one is marred by 1) Oversimplification 2) Arguing over semantics The term 10x engineer is particularly bad because it implies something: that some engineers are just generally 10 times more productive than others. I'm pretty sure most engineers would be vehemently opposed to their performance or value being quantified , so why do w…
Here's a question: Is Picasso a 10x artist? The thing about the 10x claim is that it takes something complex and creative and applies a scalar multiplier to it. Talking about 10x programmers is _semantically_ problematic.
Earlier quoted context omitted.
I've always understood it as an approximate order of magnitude.
An order of magnitude of what?
My problem with the concept of a "10x" programmer is that its baseline is not well-defined. Who's the 1x programmer? Figure that out and then we can have a fun discussion about the existence of 10x (and maybe -10x) programmers.
The natural follow-on questions are: What are the decision-making habits that make someone significantly more productive on a software engineering team? What are ways to imbue a team with these habits?
Someday we'll have "problem-solving" classes in elementary schools to help teach those basics; and better unambiguous communication, etc. One habit that's been well-documented for a long while is that the best problem-solvers take more time being sure they've understood the problem correctly and settling on an optimal approach before charging in doing the work.
The best habits that often spring from good character - I agree with Bourne on that - those with neurotic motivations or insecurities may choose "solutions" that show off their ability with some extra arabesques, rather than taking a more straightforward path that's best for the company, for example. Not to mention being willing to possibly embarrass yourself by asking what may or may not be "dumb questions." That's huge.
The area that I see this really come into play is with problems that the developer initially doesn't know how to solve. Some developers learn and adapt 10x faster than the average developer, and it seems like they're never blocked.
IME a more common case is overengineering. Not only does this slow someone down initially, but the extra complexity often continues to slow them (and anybody else in the same codebase) into the future.
If the problems we solve are NP hard problems, it stands to reason that 10x quicker solutions are actually not that impressive and certainly would be very likely to exist. Suggesting that certain people aren't able to arrive at solutions that are an order of magnitude better or develop workable solutions an order of magnitude more quickly is clearly ignoring reality.
I take it you mean something like this: In the real world, NP hard problems are "solved" by approximations; and the range in the accuracy (and speed) of various possible approximation algorithms is immense in many or most cases. Which means you want your best woman doing the job, 'cause she's easily ten times better than the next man up, in fact her final algorithm might be thousands of times better and faster than her previous try last week and yet still leave a crazy amount of room for improvement, one day.
I wonder what you should do if you are one of these 0x programmers. Throw away your degree and change career? Or try to close the gap? But what if you really aren't able to become one of the 10x? I wonder because I feel that this is my situation. The people I started working with are so much above my skill level, it's ridiculous.
If you really are 0x then yes you're in the wrong job. But first read up on https://en.wikipedia.org/wiki/Dunning–Kruger_effect and https://en.wikipedia.org/wiki/Impostor_syndrome because those are much more likely than a 0x realising they are a 0x.
I'd suggest there is no quantifiable way to measure what "a good programmer" is. Nor is there a way to quantify "good code" in any scientific manner. It IS possible to identify obviously bad code, BUT "good code" comes in a variety of forms and looks different depending on the experience level of the developer. In the end, many of the measures that people apply to assess programmers are simply a matter of personal op…