←back to thread

94 points azhenley | 1 comments | | HN request time: 0.203s | source
Show context
austin-cheney ◴[] No.43109664[source]
We certainly know what makes bad developers:

* 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.

replies(7): >>43109887 #>>43110046 #>>43110572 #>>43112473 #>>43112475 #>>43113818 #>>43114134 #
aen1 ◴[] No.43109887[source]
* decision anxiety - agree

* 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

replies(3): >>43110681 #>>43112174 #>>43112414 #
1. johnnyanmac ◴[] No.43112414[source]
>who said this is something that is necessary at all stages?

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.