"Now, when coding, I try to think: 'how can I write this such that if people saw my code, they’d be amazed at how little there is and how little it does'."
golden. i've been trying to pound this concept into my head lately, and this is a very well-stated version of it.
This is in fact a very powerful idea. It's been my rule for a couple decades now. I think I learned it partly from Rtm, who has always been a kind of code miser.
Curiously enough, there is one weird edge case where this approach can bite you: when you're launching something new that you're going to publish the source of, and which a lot of people are already predisposed to hate...
OT: Seven hours of Feynman lectures online: "The Character of Physical Law" (in case you missed the announcement several months ago, Silverlight required)
This has definitely given me a better way to phrase my current coding style than "on-demand" or even "lazy" coding. Basically, the way I work is: I build what's being asked for, and no more. I try and anticipate where future demands might come in, and build things such that there is "room" for those features, but I don't build them before somebody asks for them, even if they just take 5 minutes. 5 minutes of dev is also 10 minutes of debugging and 15 minutes of testing, and that adds up quickly.
One gotcha is that to truly making the code concise also can be over-engineering. It takes a phenomenal amount of work to really understand something, well enough to make it as simple as possible.
And then you release it and discover that the problem is a little different from what you thought, or you solved the wrong problem. It wasn't that you were stupid, just that you didn't have the data that can only come from outside yourself.
