Selfish Programmers: less flame-baity

Last post too flame-baity for you?

@kberridge I'd recommend rewriting to be less inflammatory and more level-headed. Reasonable thoughts, unreasonable delivery.
— Corey Haines (@coreyhaines) May 8, 2012

 Fair enough!

It's far too easy to confuse "easy" with "simple."  Rich Hickey touches on this a bit in this presentation, which is very similar to another talk he gave that I blogged about earlier.  Almost every thing he said in these talks was very thought provoking for me.  But the one that really hit home the hardest was this concept of easy vs. simple.

The difference between easy and simple is rather hard to firmly pin down.  One way to think of it might be that easy means less effort.  Fewer keystrokes, fewer concepts.  The less I have to type, the easier it is to do something.  The less I have to know, the easier it is.  The fewer structures between me and what I'm trying to accomplish, the easier.

But easier doesn't necessarily mean simpler.  Hickey associates simpler with un-twisted.  So code that is DRY, and SOLID would be simple.  Even if it requires more keystrokes, classes, and curly braces to write.

I find myself falling for this a lot.  Sometimes it might be simpler to do more work, but that's hard to see.  On the other hand, it's incredibly easy for me to judge how fun something will be for me to do, or how much tedious effort something with require.

The problem is that EASY is about me, where SIMPLE is about my code.  So the deck is stacked against us as software developers.  It's going to be difficult to separate whats easy for us from what's simple for our code and make the right design decision.

Being aware of this distinction is useful.  And I certainly wasn't as aware of it before watching Hickey's talk.  But it does raise an interesting question of how can we keep ourselves honest?  How can we notice when we're doing the easy thing instead of the simple thing?  While at the same time avoiding doing too much and over complicating?