3 ms·
This is a pretty good take imo. His argument, summarized, is that ostensibly "bad" code is not as bad as it could be, because that implies you can readily tell
by nighthawk454 4y ago
This is a pretty good take imo.
His argument, summarized, is that ostensibly "bad" code is not as bad as it could be, because that implies you can readily tell what it does, immediately see issues with it, and know how to improve it. Possibly, this code might not fully deserve the label "bad". It's _far_ better than code that's completely impenetrable.
Reminds me of the Bjarne Stroustrup quote: "There are only two kinds of languages: the ones people complain about and the ones nobody uses".
- 000ooo000 4y agoI'm not so convinced that "bad code is better than awful code" is a very useful observation. Kind of strikes me like "well I have stage 3 cancer, but at least it's not stage 4"; you wouldn't be wrong, but you still have cancer..
- nighthawk454 4y agoI think maybe "treatable" vs "untreatable/terminal" could be a better metaphor. Both obviously still suck and are expensive and painful and time consuming, but the difference seems signficant
- 000ooo000 4y agoAgreed, I like that. Seems more useful/actionable than 'good' or 'bad'. So can we then say the difference between a rookie and a seasoned developer is just whether they say code is 'unsalvageable' or whether it's 'bad'? We solved it - coming soon to a interview process near you.