[delinka]

"Compact code" is not orthogonal to "less code." It is said that you don't truly understand the problem you're trying to solve until you've implemented it a few (3?) times. Once you begin to understand the problem, you can often find places that required no code: either an existing API solved that problem and you weren't aware; or perhaps you found a more 'pure' solution and you can remove much of your code. This does not mean that you need to write compact, unintelligible code.

Also consider: "In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away, when a body has been stripped down to its nakedness."

Lately in my programming career, I find myself simplifying code, distilling it to solve the problem at hand, then clarifying the code (with good variable names, explicit comparisons to NULL/nil, fully demarcated if/else, small well-named functions, etc) so that future me can grasp it faster. This has the added benefit of pleasant peer review and getting new devs acquainted with the code.

[chrisweekly]

Nice post. Related note, I just recently found this gem of a Hickey talk about "Simple" vs "Easy": https://github.com/matthiasn/talk-transcripts/blob/master/Hi...