The cyclical nature of programming

Anybody who has been in this business for a long time knows that there are a lot of cycles in technology. Boom/bust cycles. Cycles where we process a lot of stuff on servers, then distribute it to nodes on the network, then move back to processing a lot stuff on servers. I'm sure there are others, but these are the two big ones that come to mind.

One thing I've noticed lately is that this is happening over on hacker news. Over the past couple of weeks there appear to have been a lot of links to items that I read many years ago. Some of them weren't even new then. Lots of Peter Norvig stuff. Some links to old Dykstra papers. That sort of thing. Things that should be part of the collective programmer consciousness, I guess.

I think this sort of thing is why we spend a lot of time rebuilding the wheel, as it were. You don't have to look to hard to find a large group of software folks that are convinced the credentials and formal schooling are waaaay overrated. But then you run into these periods where a large group seems to stumble upon some piece of writing or some paper and has to share it with the world, as if they've discovered something new and exciting and awesome. While I respect and love the enthusiasm of these sorts of things, I'm wondering how much overlap there is in these two groups. I would guess a lot. Maybe that's just my natural pessimism and cynicism kicking in.

I know that several well known people have lists of required reading for programmers. It just seems that these aren't very well known in the programming community at large. I've passed some of these around to various people. Some of them really bug me, however, because they are ephemeral. I know a lot of people, for example, that used to recommend one or more Extreme Programming books. Very enthusiastically. Now, they wouldn't touch them with a ten foot pole. They've moved on to Scrum. And soon I imagine they will move to some yet unnamed flavor of the month. Mostly in an effort to collect more consulting revenue.

I think I'm going to start collecting some of these. I'd like to break this particular cycle. Here are a few that come to mind. They mostly contain basic fundamentals or things that have stood the test of time. They are the sorts of things that are, in some cases, part of the collective hacker unconsciousness. Eric Raymond has written about this hacker culture stuff and has done a much better job than I could hope to do.

Eric can be polarizing, but he has some great writings. No matter what side of the ESR fence you sit on, at least he makes you think.
How to become a hacker
Cathedral and the bazarr
The Art of Unix Programming

norvig.com - Just an all around smart guy with lots of good things to say.

Joel on Software - The forums on this site used to be GREAT. The business of software board is still pretty good. The older essays are definitely worth a read.

The Mythical Man-month. Fred Brooks. Classic book. Short, too, which is nice :-)

I'll add others as they come to mind.

Writing more code isn't always the answer

This is one of my very favorite stories of writing good code and how metrics can go horribly wrong.

http://www.folklore.org/StoryView.py?project=Macintosh&story=Negative_2000_Lines_Of_Code.txt

"Bill Atkinson, the author of Quickdraw and the main user interface designer, who was by far the most important Lisa implementor, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code. "

Generally speaking, I'm with Bill.