* decision anxiety
* fear of writing original ideas, both natural language and code
* the inability to measure things
* preference towards bias
* cognitive conservatism
* inability to form assertion criteria
Real engineers proceed on the basis of evidence and in the absence of evidence make arbitrary original decisions as necessary to gather evidence.
* fear of writing original ideas, both natural language and code - agree
* the inability to measure things - who said this is something that is necessary at all stages? sometimes you just need it done. when you have 1000 people teams selling to enterprises, sure. If it is you and your buddies, no need to measure, necessarily.
* preference towards bias - Why? If it works, a good engineer won't go to the newest tech/framework. They will stay with their biased favorite.
* cognitive conservatism - Disagree. See previous comment
* inability to form assertion criteria - Not exactly sure what you mean, but if you mean to reason about code and state at various points, then I agree
The inability to measure things results in a lot of really bad output often in preference for emotional comfort. This and cognitive conservatism are the most clearly identifiable criteria of poor cognitive performance by people who are in over their heads. I saw this at every employer when I wrote JavaScript for a living.
The inability to form assertion criteria means a person has absolutely no idea how to qualify a decision logically.
In most of these people tend to do Y at much greater cost because they cannot do X. The most common answer to this is anxiety and then people twist themselves into knots to somehow qualify that anxiety in a way that makes sense to themselves.
understanding when you don't need to measure is important too. If you are just making a small 2d app as a hobby with no more than maybe 100 draw calls on hardware that exceeds that of a potato: I probably won't waste much time with optimization schemes and just crank something out.
But that same app may want to be kept as small as it feels so I would focus more on any assets being compressed.
> inability to form assertion criteria - Not exactly sure what you mean
I took it as testing. Unable to understand what you're trying to solve, frequency of usage for such functions/modules, the amount of reach your code will have (only used once in a small module? Code code that he core multiple layers up will rely on?) and not considering potential edge cases. More or less similar to what you said.