Very disappointing read.

Starts with an interesting claim "don't optimize for typing", but then it completely fails to prove it, and confuses itself in thinking that `auto` is an optimization for typing.

`auto` is:

- A way to express types that are impossible or truly difficult to express, such as iterators, lambdas, etc

- A way to optimize reading, by limiting the redundancy

- A way to optimize maintenance, by limiting the amount of change brought by a refactor

The insistence on notepad or "dumb editors" is also difficult to grasp. I expect people reviewing my code to be professionally equipped.

Lastly the example mostly fails to demonstrate the point.

- There's a point made on naming (distinct from `auto`): absent a wrapping type, `dataSizeInBytes` is better than `dataSize`. The best way though is to have `dataSize` be a `Bytes` type that supports conversion at its boundaries (can be initialized from bytes, MB, etc)

- What's the gain between:

    auto dataSet = pDatabase->readData(queryResult.getValue());

and

    DatabaseDataSet dataSet = pDatabase->readData(queryResult.getValue());

The `dataset` part can be inferred from the naming of the variable, it is useless to repeat it. The `Dabatase` is also clear from the fact that we read data from a db. Also, knowing the variable has this specific type brings me absolutely nothing.

- Their point about mutability of the db data confused me, as it is not clear to me if I can modify a "shadow copy" (I suppose not?). I suggest they use a programming language where mutating something you should not it a compile time error, it is much more failsafe than naming (which is hard)

I'm sad, because indeed one shouldn't blindly optimize for typing, and I frequently find myself wondering when people tell me C++ is faster to write than Rust, when I (and others) empirically measured that completing a task, which is the interesting measure IMO, is twice as fast in the latter than in the former.

So I would have loved a defence of why more typing does not equate higher productivity. But this ain't it.