[CyberDildonics]

> Amdahl's Law is very relevant here.

This is a gross misunderstanding of both software and amdahl's law.

Amdahl's law just states that the serial parts of a program stays the same as more cores are used for the parallel parts of a program. This also means that the percentage of time the serial part takes becomes larger as it stays the same and the overall running time goes down. It is not an incredibly mind blowing or insightful observation.

It is also assumes certain aspects can't be split up.

Multiple programmers means more communication (synchronization). If anything amdahl's law is an argument that having less but better programmers is much more effective than having more average programmers.

[BeetleB]

By Amdahl's law I was referring to things like:

- Communicating with customers

- Writing documentation

- Testing (be it automated or manual)

- Other stuff that may seem bureaucratic but nevertheless are essential (paperwork, tending to CI, tending to HW, etc).

This stuff (or at least some of it) is harder to scale. You can scale up the coding part quite a bit, but the overall process of SW development is held back by the above. You're not going to find someone who is 10x when it comes to talking to customers. Often managers will find the so-called 10x programmer and assign him to duties to maximize output, and have someone else do the work above. But he's still not a 10x overall, as he is simply not doing the work of other developers. That's why I said "within a very narrow domain".

Now if you can get a 10x developer who can scale all aspects of the job, then sure - pay him/her 10x.

[CyberDildonics]

This shows another huge misunderstanding of "amdahl's law". Again it is a very simple ratio.

Programmers who are much more effective are that way due to a lot of reasons you are missing. Amdahl's law is about programs that have parts that must be done and must be serial.

Great programmers are doing a lot less. They aren't wasting time with all the things you wrote here because what they make works, doesn't break, scales, and doesn't need to be changed while being much simpler. If you look at the source for doom, it doesn't have huge amounts of class hierarchies and ridiculous plumbing from bloated frameworks. John Carmack didn't go down a bunch of rabbit holes to procrastinate getting things to work. He isn't wasting time communicating with customers (why can't someone else do this?). He doesn't need to waste as much time with documentation because what he does is simple and works without needing to be changed. Not only that, but someone else can do most of this too. Tests are the same way.

The mistakes here are thinking that you have to waste a good programmer's time with nonsense and that they are trying to do what the average programmer is doing faster. The average programmer is terrible and is perpetually pushing their boulder up hill because they don't understand what is happening with what they write. They don't understand what will be slow, what is already simple, what has already been done etc. They create nonsense that is always being redone like someone trying to build a new house out of cardboard every time it rain because other materials are 'too heavy' or 'too expensive'.