When I read really great code, I often think "This is all there is?". It seems like there is too little code to do all the things that it does. Or what is there seems trivial, so simple that it couldn't have required any thought or effort to produce.
Bad code is full of stuff, it twiddles bits here and there, does complicated things in nested loops and works very hard to accomplish very little.
This might make bad code seem more interesting, at first glance it seems like it does more, when in fact it generally does less, just with much more complexity.
"When I read really great code, I often think "This is all there is?". It seems like there is too little code to do all the things that it does. Or what is there seems trivial, so simple that it couldn't have required any thought or effort to produce."
Similarly, in my experience great code solves a problem that would seem very difficult in a way that seems very obvious but usually only in retrospect, or as we're reading the code. A corollary would be code that reveals some truth about the system being coded that isn't obvious except in retrospect.
This comment reminded me of the epiphany I had my sophomore year in college: that code is a literal (and physical in a sense) representation of an idea or system.
I know it seems trite.
But I had been programming for years, and I had grokked recursion and pointers, but up to that point I was always sort of thinking of programming as a means to an end, and somehow distinct from the task it was accomplishing. At this point I take it for granted that I can translate my thoughts into this or that programming language, but when I first realized the direct correlation it was like a bolt of lighting.
This is the key to effective programming. I like to measure what the code ENABLES both the end user, and the programmer in the future (design leverage) - not just what it DOESFOR the user in a literal way.
The code becomes more abstract, more of a model, and the software may become a 'tool'. (You'll find that as you program you will naturally refactor to a more abstract model and things will "click-in" and work the way you want it the first time)
Bad code is full of stuff, it twiddles bits here and there, does complicated things in nested loops and works very hard to accomplish very little.
This might make bad code seem more interesting, at first glance it seems like it does more, when in fact it generally does less, just with much more complexity.