News for hackers. Stuff that matters.
Re:Why programmers are not paid in proportion to their produ... by kayodelycaon on Wednesday June 29, 2022 @09:04AM (#31919554)
There are a lot of explanations possible.

I’ve deal with with the aftermath of with “80% developers” my entire career. In two weeks, they’d write a good enough program with no handling of edge cases or errors.

Replacing one of these with a proper application can take a year.

I’ve also dealt with a team of programmers who couldn’t come close to my productivity solo. It was due to constraints and communication overhead, not incompetence.

When you go from a solo dev to a team of 19, that sounds more like a change in strategy by management than anything else.

Re:Why programmers are not paid in proportion to their produ... by bmitc on Wednesday June 29, 2022 @11:29AM (#31921556)
I’m not sure what you mean by 80% developers, but I am generally cautious on developers who are seen as uber productive. I worked with one in the past, and they would blow through so much code. It amazed everyone else, but they left a literal wake in the code. It was just a gigantic mess when you dove into it that wasted so much time down the road in onboarding others, refactoring it, maintaining it, etc.
Re:Why programmers are not paid in proportion to their produ... by kayodelycaon on Wednesday June 29, 2022 @12:14PM (#31922196)
Sorry, I should have clarified, they are developers that quickly do 80% of the work and move to the next thing.

They are often quite intelligent and very productive, but aren't inclined to think a problem through to completion.

Re:Why programmers are not paid in proportion to their produ... by bmitc on Thursday June 30, 2022 @10:27AM (#31932742)
Gotcha, and no worries! That makes perfect sense. I was just calling it out that I wasn't for sure to ward off inadvertently supporting or commenting on something I wasn't sure about.
Re:Why programmers are not paid in proportion to their produ... by lamontcg on Wednesday June 29, 2022 @02:44PM (#31924140)
Yeah, I've inherited a mess of software written by one of those before.

I used to have some imposter syndrome because I wasn't that hyper productive, but not after having to clean that code up.

For example, I found a supposedly queue-less parallel map / threadpool with 2 or 3 queues inside of it, which had weird deadlock bugs that would result in strange occasional timeouts. I replaced it with a parallel map with no queues built on top of a thin and standardized threading library. The deadlocks went away. The resulting code was pretty boring in readable. I never bothered to dig into why the old code deadlocked, but throwing it all away fixed all the problems.

It is a lot easier to greenfield where you can put off the edge conditions till later and focus entirely on the first 80%, it is also really easy to greenfield when you focus on just typing as fast as you can and spray sloppy code everywhere (actually sloppy code like that crazy parallel map implementation I threw away). I suspect the latter is what a lot of "10x developers" actually are.