3 ms·
Have you ever encountered code that's easy to change but needs to be changed very often, is that strictly better than code that is hard to change but very unlik
by aszen 6y ago
Have you ever encountered code that's easy to change but needs to be changed very often, is that strictly better than code that is hard to change but very unlikely to ever change?
A more concrete example, fixing null pointer exceptions is often easy but code that avoids them using abstractions like maybes and sum types is harder to change but requires less maintenance overall.
Lessening cognitive load while increasing easy manual work is not always better
- mrmonkeyman 6y agoIt is _always_ better. Easy manual work is cheap and easy to outsource and will eventually automated. Clever stuff has no endgame, it is a bottleneck. It is there just to be clever, there is no value.
- t-writescode 6y agoLet's imagine that the person that wrote that code has left the company, and all of their coworkers are 4 years out from touching that area of code. What is the answer to your question, now?
- aszen 6y agoWell that code has already provided its value over 4 long years without bothering anyone, it doesn't hurt if someone has to struggle a bit understanding how it works now.