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

Busting the 10x software engineer myth

swarmia.com

Post reply on HN
Print view View original

301–310 of 356 posts

Re: Busting the 10x software engineer myth

#301

Post by cies »

goto11 wrote: post #106
carnitine wrote: post #98

Earlier quoted context omitted.

They specifically said runtime errors. Elm is designed in such a way that runtime errors do not occur. Obviously logic errors etc. are still possible.

So what happens if you divide by 0 in Elm?

You claim something is "hipster" without having any clue whats it about. May I say the word hipster means nothing. It could mean popular: but Elm is not popular.

Maybe time to study some of that "hipster stuff".

I'd say Elm was very interesting to learn. I gained some programming wisdom from writing stuff in Elm (and in a previous experiment, Haskell).

Re: Busting the 10x software engineer myth

#302

Post by cies »

goto11 wrote: post #150
widdershins wrote: post #107

Earlier quoted context omitted.

To be fair, the grandparent said 'runtime errors', not 'bugs'. And it is a stated goal of the Elm language that runtime exceptions thrown from the compiled Javascript should be impossible. As far as I know, they have succeeded in that goal. How this relates to 10x or not I don't know - I'm not sure the discussion is a productive one without further context. It might be that for some tasks, Elm really does provide a h…

I'm sure Elm is a great language, but thinking it eliminates runtime errors is ridiculous. Of course it might eliminate exceptions , but exceptions are not errors, rather they are (sometimes) signals than an error have happened.

Yes, this only holds for some definition of errors. Run time program errors due to type mismatch, nulls and exceptions are non-existant.

Pretty cool!

Re: Busting the 10x software engineer myth

#303

Post by cies »

samsquire wrote: post #121
cies wrote: post #88

Earlier quoted context omitted.

If a brittle piece of JS (with high support cost due to runtime errors) is replaced with a piece of Elm, the runtime errors are gone. The one that made the decision to change it, and actually ported the code, easily wins the 10x badge when we consider the high support cost of that brittle piece of JS code in production. > institutional knowledge is lost. Exactly! Say a dev rewrote the brittle piece of JS to resilient…

This is wrong. Rewriting your code in Elm (or other niche language) doesn't make you a 10x developer. Same way rewriting your code in Rust doesn't make you a 10x developer for removing memory safety issues. A 10x more productive developer is more productive within an ecosystem against others who are also in that same ecosystem. It's not fair to compare a C developer to a Rust developer in terms of developer skill. Bu…

You did not get my comment. I wanted to say that in choosing lang+tooling is a great place to make the 10x difference.

Re: Busting the 10x software engineer myth

#304

Post by keskival »

It's weird to focus on time to solve a problem when the software field is full of examples of challenges where you need a great engineer to be able to create a working solution at all, and an average engineer could never in their lifetime produce a workable solution. What's the multiplier factor on these?

Re: Busting the 10x software engineer myth

#305

Post by adrianmonk »

> The company's CEO would walk into the space where the developers worked and loudly comment – even to outsiders – “sometimes it feels like X is the only developer who gets anything done.”

Their analysis: 10X developers are a myth.

Alternative explanation: 0.1X managers are a reality.

Re: Busting the 10x software engineer myth

#306

Post by jmchuster »

daniel-cussen wrote: post #299
bjourne wrote: post #97

This article is pure clickbait written to sell in this stupid Swarmia startup. :) 10x developers exist just like 10x musicians, 10x marathon runners, or 10x chess players exist. It may take a world-class musician a week to write a masterful symphony but it would take me way longer. Perhaps I'd never produce anything great so that musician would be infinitely better at it than me. Great chess players beat amateurs at…

> Great chess players beat amateurs at least 99 times out of 100 so must also be 10x in comparison. Absolutely. Chess is very hierarchical. I would say true amateurs will literally never beat a grandmaster, and high school champion-level (not prodigies though) can only beat a grandmaster if the grandmaster plays very weakly (vastly underestimating them, not truly playing their best, or having their guard really, real…

In Go, for example, for the professional ranks (1 dan through 9 dan) each rank should win 70% of their games against players from the next rank below.

Re: Busting the 10x software engineer myth

#307

Post by jjav »

anmxxx wrote: post #8

This is a silly framing of the 10x engineer issue. That label originally designated someone who had written an unusual amount of excellent software. Recently in the discussions here, people take it to mean someone who cobbles together broken apps at a rapid pace and gets credit from management for being a hero. This is not what 10x engineer means. Please find another label for that phenomenon, for example 10x faker .

> people take it to mean someone who cobbles together broken apps at a rapid pace and gets credit from management for being a hero

I agree, but as you say, this is more often than not the definition used (unconsciously) by management. Management considers this person the 10x and others consider them the -1x.

And yet.. these developers are also great though, in their niche. It's awesome to have someone on the team who can whip up the demoware in an evening for investors and customers! Even when I'd rather they never commit anything to the product source.

Which is why this discussion of finding who is the 10x is misguided. Turns out people excel at different things. Good management will identify what everyone is best at and have them focused on that. Bad management will shoehorn people into the wrong roles and set them up for failure.

Re: Busting the 10x software engineer myth

#308

Post by jmchuster »

cyberpunkdyst wrote: post #244
eurasiantiger wrote: post #213

Earlier quoted context omitted.

”The truly high-performing people, who are passionate about their craft are very likely to move to companies that are at the at the top of XYZ, where XYZ is the topic within software engineering that they're especially passionate about, pay well, etc.” Is there a source for this claim? How likely are they to move exactly, and what motivates the non-movers to stay?

This is based on my limited personal experience observing the careers of people I know, whom I could consider somehow exceptionally good at their craft. I co-led the CTO team of software consultancy with 350+ devs. In that role it was pretty clear that it was really hard to compete on salary and how interesting projects experts could be offered. Motivations differ based on what the person values. The top motivations…

I would probably consider consultancies very differently from product companies.

Since the company charges a per-person rate on hours worked, all it needs is to charge more than you pay them (plus utilization). So it's a very viable business model for the company to hire the cheapest (so either least skilled or least experienced) developers, as long as you have enough projects where you can charge for them. Maximizing engineering skill is not profitable, maximizing the diff in pay * the number of hours worked is what is most profitable.

I would argue that consultancies are probably the worst type of company for attracting talent. If we consider the idea that an engineer becomes skilled enough that they now have to power to choose which projects best interest them, then choosing the company is analogous to choosing that next project. If they join a consultancy, they specifically lose that power. Since, you're not signing up for a single company and single project, you're signing up for every single client in that company's portfolio.

Personally speaking, if I was to run a consultancy and cared about the quality of the developers, the only choice is to hire exclusively new grads out of college. That's when there is the greatest diff between the pay they can command and the potential skill level they have, since that skill level is unknown. You can then exploit that gap for a number of years, until they realize how good they are and can command a high enough salary from a different company (most likely a product company) that has the margins to be able to pay ridiculous salaries and not blink an eye.

Re: Busting the 10x software engineer myth

#309

Post by ygram »

magicalhippo wrote: post #136
dkersten wrote: post #87

Earlier quoted context omitted.

> the author is confusing what a 10x developer is. Its a subjective definition. You have a different one to the author. sneak has a different definition to you. That's a part of the problem: there's no clear definition and the label "10x developer" means different things to different things. Some of these definitions definitely are a myth. Some are not. But the conversations about it tend to not be that meaningful, b…

My coworker is a beast at churning out working code, but mine is often better abstracted and requires less refactoring to use in the future. There are features where I spent 5-10x the time he'd do, but my code could then be used to later implement several dozen feature requests in mere minutes rather than hours and days. Who's better? I'd say we've got different strengths, so depends on what you need to get done.

Your coworker is better, sounds like you spend a lot of time on premature generalisation.

Re: Busting the 10x software engineer myth

#310

Post by namdnay »

RHSman2 wrote: post #138
namdnay wrote: post #132

Earlier quoted context omitted.

You can't "measure" a session musician either. And yet some of them take hundreds of dollars an hour to be there for a recording, so clearly there is a way to know

If a session musician charges by the hour you know they aren’t good OR haven’t been recognized yet. Day rates.

When a wise man points at the moon, an idiot looks at his finger
Post reply on HN