?

Log in

No account? Create an account
 
 
27 February 2017 @ 01:55 am
No mistakes - means "too slow"  
From "Committing code often" discussion:
It is ok to make mistakes, especially in the first "rapid-fire" version of the code.
There is no shame in it.

Even more: if you are not making any mistakes while coding - that means you are way too careful and are working much slower than you can.
(That does not mean, of course, that you should intentionally do mistakes. Just take greater risks in order to improve speed of programming/coding until you start getting occasional mistakes).

Originally posted at: http://dennisgorelik.dreamwidth.org/125623.html
 
 
 
стриш-ш-ш (ш-ш-ш!)lxe on February 27th, 2017 07:33 am (UTC)
How often is "occasional"?

"Error-proof" reputation is hard to earn and is more important the larger the team and the greater costs to deploy a fix are.
"Tinkering" is low-cost in a small team, in a unified environment, in a strongly fortified sandbox. That's not always the case.

Also, "error-proof" coding comes from the use of certain tools and practices - in a nutshell, from preventing side effects indiscriminately rather than spending more time thinking which side effects are desirable and which are not. Incentivization of slow coding won't help if these practices are already adopted, and won't help them to spread either.
Dennis Gorelikdennisgorelik on February 27th, 2017 07:45 am (UTC)
> How often is "occasional"?

It depends on the severity of the consequences of that mistake.
At the right balance, overall cost of mistakes should be comparable with the cost of the time saved during development due to riskier approaches.

> "Error-proof" reputation is hard to earn

Do you mean that programmer should specialize in either "quick prototyping" or in "slow, but reliable development"?

> Also, "error-proof" coding comes from the use of certain tools and practices

I agree that tools and practices should be chosen carefully:
1) Keep practices that deliver good quality results at a relatively low time cost.
2) Use these practices consistently to reduce the cost of applying these practices.

Incremental commits and frequent reviews should help.
Good autotest coverage should help.
стриш-ш-ш (ш-ш-ш!)lxe on February 27th, 2017 08:08 am (UTC)
"quick prototyping" or in "slow, but reliable development"?

I would, myself, eagerly engage in both provided I don't confuse the two. (I often see others do.)