The whys and whats of code.averse

What's the blog all about?

• Code averse: less code is better, all other things being equal.
• Code a verse: poetry is visceral, direct communication, like code should be.
• Codeaverse: we create worlds with our code, and live within them.

I want to discuss elegant code, refactoring (with examples), development and design principles, etc. It'll swing between pretty basic stuff and mid- to higher-level ideas

Code Averse

Minimizing the amount of code we have has several benefits.

• Easier to understand
• Easier to maintain
• Easier to extend
• Easier to document

Code a Verse

I don't (necessarily) mean that code should be emotionally evocative like most poetry is designed to be. Making our code direct, communicative, and visceral increases its value, though.

Code that draws people in on an emotional level drives people to invest in its upkeep and extension in fundamental, caring ways. Sloppy code begets sloppy code, ugly code grows without direction. uncommunicative code is extended in destructive, un-maintainable ways.

Code that speaks to us--that we intuitively "get"--evokes a sense of care, a sense of responsibility beyond "I just want it to work" (although it might start off that way). Beautiful code fosters a sense of ownership and pride. We want it to remain as pure, as delightful, as resonant as what came before.

Coding verses often runs counter to being code-averse: we might add code to make other code better. Refactoring may increase LOC (lamest metric ever). Understanding doesn't come just from being concise, it comes from being coherent.

Codeaverse

Code is fractal. The "whole" can be beautiful or ugly, as can a library, a class, a method, or a single line. Every app is a little world, containing other little worlds, or part of a larger, encompassing world.

All apps apps have their ghettos, their ugly bits, their wtfs, their "we needed to actually deploy" areas: that's okay. Sometimes we're writing with delivery as the main focus, not art.

The nature of the app dictates how much of that is acceptable, and whether or not the cost of doing so really costs. One-off conversion app? A crappy world is fine. Building a company on it? Not so much: beauty pays dividends, in wide-ranging ways, in both the short and long term.

So...

A blog with multiple aims, multiple targets. Micro-refactorings, large-scale issues. How do we name a variable, what does "do one thing" mean, can I clean this up, is there a missing abstraction.

Some of the examples will be incomplete, some will be wrong, some don't go as far as they could, I'm okay with that--lots will come from questions I actually get and be aimed pretty directly, some will come from my own questions, some will see fairly random.