8,000 characters in five hours is 1,600 characters per hour, or 27 characters per minute.
This is irrelevant. Typing when coding is not evenly spaced out over those 5 hours. It is sporadic with most of the time thinking or reading documentation or reading source code and trying to figure out what you want to type. No good conclusions can be drawn from this logic and makes that whole part of the argument irrelevant.
If I were typing that slowly I would quickly forget what the hell I was even trying to do in the first place. Which is the bigger part - when you do need to type you want to quickly get the ideas you have down as fast as you can think them. Going too slow can cause your mind to wander and that can really hamper your productivity.
There is also the cost of context switching. And it is a context switch to go from writing ideas down to making sure I have all the boiler plate and syntax correct. The less of the need for doing that the better IMO.
And TBH I don't really understand the rest of their arguments. They introduce two bits of code, one very short simple class then one with lots of helper methods to set various things while creating a new object. And then concludes with a short paragraph on some real benefits without really explaining why. With the whole paragraph being more of an argument about immutable code being better rather than longer vs shorter code. Then follows up with an entire section on why his code increases maintenance as refactoring requires more points to update with his immutable code and thus prefers languages like F# where the immutable version is a one liner... Which defeats the whole argument that typing is not the bottleneck? I really don't follow his logic here.
Apparently, it has to be explicitly stated: Programmer productivity has nothing to do with typing speed.
I feel they have completely failed to convince me of this fact. Despite me already thinking it is not one of the more important factors of productivity and there are better things to optimise around.
My opinion is that code length is not that important a factor, but you should not go hog while and write the longest things you can either. Every extra bit of code should add some value somewhere. Like taking his examples, spending a bit of time writing the immutable version here lets you reduce the amount you need to write when using that code. Which is a trade-off that can be worthwhile - increasing typing now for reducing typing later. But also the reduced typing makes the where the code is used easier to read and clearer as to what is happening, get a copy of the object with one field updated. That is a nice concept to have and read. Without the need to refer to all the fields every time you want a copy.
This is irrelevant. Typing when coding is not evenly spaced out over those 5 hours. It is sporadic with most of the time thinking or reading documentation or reading source code and trying to figure out what you want to type. No good conclusions can be drawn from this logic and makes that whole part of the argument irrelevant.
If I were typing that slowly I would quickly forget what the hell I was even trying to do in the first place. Which is the bigger part - when you do need to type you want to quickly get the ideas you have down as fast as you can think them. Going too slow can cause your mind to wander and that can really hamper your productivity.
There is also the cost of context switching. And it is a context switch to go from writing ideas down to making sure I have all the boiler plate and syntax correct. The less of the need for doing that the better IMO.
And TBH I don't really understand the rest of their arguments. They introduce two bits of code, one very short simple class then one with lots of helper methods to set various things while creating a new object. And then concludes with a short paragraph on some real benefits without really explaining why. With the whole paragraph being more of an argument about immutable code being better rather than longer vs shorter code. Then follows up with an entire section on why his code increases maintenance as refactoring requires more points to update with his immutable code and thus prefers languages like F# where the immutable version is a one liner... Which defeats the whole argument that typing is not the bottleneck? I really don't follow his logic here.
I feel they have completely failed to convince me of this fact. Despite me already thinking it is not one of the more important factors of productivity and there are better things to optimise around.
My opinion is that code length is not that important a factor, but you should not go hog while and write the longest things you can either. Every extra bit of code should add some value somewhere. Like taking his examples, spending a bit of time writing the immutable version here lets you reduce the amount you need to write when using that code. Which is a trade-off that can be worthwhile - increasing typing now for reducing typing later. But also the reduced typing makes the where the code is used easier to read and clearer as to what is happening, get a copy of the object with one field updated. That is a nice concept to have and read. Without the need to refer to all the fields every time you want a copy.
I type slowly so i just write my ideas down on paper first