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

341–350 of 356 posts

Re: Busting the 10x software engineer myth

#341

Post by cutemonster »

foobiekr wrote: post #269
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…

10x (or more) engineers in both hardware and SW exist. I've personally known more than a few, they are humbling, and I was pretty good myself at the time. SW is too time consuming, I think, for it to really show, and tools help even things out, but I think math shows that even 100x people exist - the von Neumanns of the world. Maybe they don't exist any more, but we had a bunch of them in the 1900s and it's inarguabl…

What do the two guys produce that's hard to analyze?

Re: Busting the 10x software engineer myth

#342

Post by strken »

karmakaze wrote: post #315
strken wrote: post #100

Earlier quoted context omitted.

I don't think anyone really doubts that some engineers will work an order of magnitude or more faster than others on a given task. They just think it's a misleading way to think about performance, which likely falls on a unimodal curve within your organisation, and likely differs by task. How do you know you're looking at a 10x developer instead of a 2x, a 9x, an 11x, a 500x, a 0.2x, or a 0.5x? The premise gives the…

You're looking at a very different kind of Nx engineer. The kind I'm talking about is where they approach a brand new problem that no one has an idea how to decompose using any tech that they have a clue how to operate, then a concise solution somehow appears using mostly what is already in service with careful splitting of tasks that appear clear and obvious only in retrospect. It's not about volume of output, preci…

The original studies that gave us the concept of a 10x engineer tracked defect rate and speed on programming tasks. You're using your own definition of an Nx engineer that:

- does not relate to speed or defect rate

- does not provide any way to quantify what N is

- does not explain how an Nx engineer differs from a normal competent engineer

There's no problem with saying "engineers who can solve novel open-ended problems exist", the problem is that there's no reason to call those engineers 10x, no reason to suggest ability to solve those problems is a yes/no question, and no link to the original studies that we got the concept of a 10x engineer from. I remain unconvinced that the concept of 10x engineers is very useful.

Re: Busting the 10x software engineer myth

#343

Post by WalterBright »

handrous wrote: post #267
WalterBright wrote: post #2

I can cite many examples of a 10x engineer having an insight that greatly shortened the development time. It's not that they write code faster. It's that they select a path to the solution that is a lot shorter.

I'm mid-career, I guess, and these days I kinda feel like I've fucked up if I'm writing any serious amount of code, under most circumstances. The best solution is often a small script in the right place, leveraging existing software (when the best solution isn't "FFS, just pay a SaaS to take care of this, it's not even worth the time we've spent talking about it"). When I'm writing an actual project , I've got this n…

The smaller a Pull Request I submit, the prouder I am of it.

Re: Busting the 10x software engineer myth

#344

Post by goto11 »

carnitine wrote: post #340
goto11 wrote: post #336

Earlier quoted context omitted.

I'm not knocking Elm at all, I think it is a very interesting language. I'm saying it is not very productive to rewrite a buggy and brittle JavaScript app in another language because you think that will make the errors go away. A productive developer would figure out why the code is buggy and brittle and fix the root cause. If you don't understand the root cause, the same or similar bugs will surely show up in a rewr…

It’s just an objective fact that an Elm rewrite eliminates all runtime errors. Turing complete languages aren’t required to have ways of panicking at runtime, it’s a choice language designers make.

No. Exceptions and errors are different things. An error is when something goes wrong due to a bug or unexpected condition. An exception is a signal in the runtime when an error condition have been detected. If an error does not generate a signal (like an exception or panic) then we call it an logical error. Logical errors are generally worse than errors which cause exceptions, since they may go undiscovered longer and are harder to debug.

Take divide by zero. Dividing by zero is an error so there must be a bug or insufficient validation in the code if it happens. Some languages throw an exception if you divide by zero. You immediately know where something went wrong, and the program does not continue with invalid data.

JavaScript does not throw an error but returns Infinity. So you don't discover the bug immediately, but at least the final output will be clearly invalid since arithmetic operations on Infinity will yield Infinity or NaN.

Apparently in Elm, dividing an integer by zero results in zero. So not only will the program continue with invalid data, it will not even be clear that the result is invalid. The error is still there, but instead of a runtime exception you have an extremely insidious logical error which you might never know is there.

Lets say you have a banking app and the user can take out a loan. The user select the size of loan and the number of months for paying back, and the app calculate the monthly installments by division. But you forgot to validate the input to disallow 0! So the user selects 0 months. A Python app would throw an exception here. Unfortunate, but no harm done. The JavaScript app will state installments of Infinity size. Unfortunate, but most likely the error will be discovered soon. It is unlikely to pass through the backed without causing a crash or validation error somewhere before the database (for example JSON will not allow Infinity).

But Elm will happily give the user 0 installments of $0, in other words a free loan. Nobody notices anything is wrong until you realize you are bankrupt.

Bottom line: Converting runtime exceptions to logical errors is a very bad trade.

I'm a great fan of static typing by the way. But it is important to understand that it does not prevent logical errors, only pretty trivial typos and type-mismatch errors which you will discover in unit testing anyway.

I'm not knocking Elm in particular here, just pointing out that believing Elm (or any language really) can eliminate all runtime errors is very dangerous thinking.

Re: Busting the 10x software engineer myth

#346

Post by peoplefromibiza »

Jensson wrote: post #300
peoplefromibiza wrote: post #296

Earlier quoted context omitted.

Carmack literally talks about working WITH Jobs, but random HN user says he didn't. OK!

John Carmack ran a video game company. Steve Jobs ran a platform, the Apple. Therefore John Carmack sometimes talked to Steve Jobs about things he needed from the Apple platform. John Carmack had a very negative experience in those interactions, yes. But John Carmack never worked with Steve Jobs on any project. Steve Jobs was never the boss of John Carmack. If you disagree please link an article where it says that th…

> If you disagree please link an article where it says that they did work together

It would have sufficed to read the Carmack post.

Seriously, random internet guy, he literally *said it himself*

> When NeXT managed to sort of reverse-acquire Apple and Steve was back in charge, I was excited by the possibilities of a resurgent Apple with the virtues of NeXT in a mainstream platform. *I was brought in* to talk about the needs of games in general, but I made it my mission to get Apple to adopt OpenGL as their 3D graphics API. I had a lot of arguments with Steve.

> I wound up doing *several keynotes with Steve* (see the word WITH?), and it was always a crazy fire drill with not enough time to do things right, and generally requiring heroic effort from many people to make it happen at all. I tend to think this was also a calculated part of his method.

-- John Carmack

I've specifically said WITH not FOR.

Please random guy, read before speaking.

Re: Busting the 10x software engineer myth

#347

Post by mwcampbell »

khalilravanna wrote: post #195

As I get older, and maybe because I worked at a company whose product is “talent optimization”, I think a lot of the “10x” thing is just a function engagement and passion. That is to say it’s not entirely skill or “intelligence”. You could take the best programmer but if you point them at a project they don’t give a crap about they’ll phone it in. Point them at something they’re passionate about and they’ll have absu…

But there's so much work that just has to be done, whether anyone loves it or not. For that, I think reliable mediocrity is a fine objective.

Re: Busting the 10x software engineer myth

#348

Post by carnitine »

goto11 wrote: post #344
carnitine wrote: post #340

Earlier quoted context omitted.

It’s just an objective fact that an Elm rewrite eliminates all runtime errors. Turing complete languages aren’t required to have ways of panicking at runtime, it’s a choice language designers make.

No. Exceptions and errors are different things. An error is when something goes wrong due to a bug or unexpected condition. An exception is a signal in the runtime when an error condition have been detected. If an error does not generate a signal (like an exception or panic) then we call it an logical error. Logical errors are generally worse than errors which cause exceptions, since they may go undiscovered longer a…

Mistreating division by zero is a logical error as you say, not a runtime error. No one has made any claims in this thread about logical errors, other than my earlier statement that Elm does not preclude them. The things which have been referred to as runtime errors for decades are not present in Elm, that’s really the only point here. In order to make that guarantee, there’s a couple of potholes where logical errors may crop up, it’s a worthwhile trade to many people.

Re: Busting the 10x software engineer myth

#349

Post by samhw »

mmargerum wrote: post #207
samhw wrote: post #183

Earlier quoted context omitted.

This blog post has some really interesting thoughts on that point: https://applieddivinitystudies.com/2020/10/15/bus-factor/

Yup. this is my life. I have a dev title but im really directing people. I don't enjoy doing both. May as well get paid accordingly.

This is something our industry needs to fix. I've turned down promotions so many times because they amounted to moving from coding to pastoral care. Which is bizarre - it's like a surgeon being offered a promotion to work in HR.

Many companies do have an individual contributor track, and that's a big factor in where I choose to work, but way too many companies seem to think it's all kinda the same thing.

(To be clear: none of this is neglecting the importance of, or talent involved in, managing people. Bringing out people's potential requires tremendous skill, which I don't have, and that's why I won't do it.)

Re: Busting the 10x software engineer myth

#350

Post by goto11 »

carnitine wrote: post #348
goto11 wrote: post #344

Earlier quoted context omitted.

No. Exceptions and errors are different things. An error is when something goes wrong due to a bug or unexpected condition. An exception is a signal in the runtime when an error condition have been detected. If an error does not generate a signal (like an exception or panic) then we call it an logical error. Logical errors are generally worse than errors which cause exceptions, since they may go undiscovered longer a…

Mistreating division by zero is a logical error as you say, not a runtime error. No one has made any claims in this thread about logical errors, other than my earlier statement that Elm does not preclude them. The things which have been referred to as runtime errors for decades are not present in Elm, that’s really the only point here. In order to make that guarantee, there’s a couple of potholes where logical errors…

Runtime errors means errors which occurs at runtime as opposed to compile time. Logical errors are a subset of runtime errors. Se for example https://en.wikipedia.org/wiki/Runtime_(program_lifecycle_pha...

This is the common definition.

Defining runtime errors as just being exceptions is clearly absurd - that would mean languages like C or assembler cannot have runtime errors!

Post reply on HN