12.1. Reuse = Laziness
I'm not really sure whether it is a character flaw or a skill, but I have a tendency to code some routines twice. The first time is to solve the particular problem at hand; the second time is so that I have a generic solution if the problem crops up somewhere else. Sometimes it does and sometimes it doesn't, but it is nice to be able to accept an assignment and have at least part of the solution coded. It is also a great way to make sure that there is always time to read User Friendly.
Unfortunately, when I started my career, this wasn't the case, mostly because I encountered managers who believed in the puritan work ethic: Work constantly until you die, or quit before the age of 33, a burnt-out husk. Basically, the more lines of code, the better, although they sometimes cloaked their philosophy behind the words "I need it so that everyone can understand it" or avoid "mad scientist stuff." However, during the years, this type of manager has largely either died off or retired. I suppose that, on some level, I will miss them, in much the same way as a headache that has gone away. Yes, I will sorely miss the threats of nonpayment for reusing code to create new applications.
"Hello, my name is Ed. I reuse code to death and I am not lazy!"
12.1.1. Paid by the Line
There were classic ASP pages that were in excess of 30,000 lines of mixed script and HTML. I was a stranger in a strange land where developers were paid by the line. It was a new application, not yet in production, so it couldn't have been maintained into incomprehensibility. What else could explain the way that things were?
12.1.2. Paid by the Page
Fortunately, I was paid by the pagealright, actually, it was by the hour, but I had a limited number of hours to produce each page. Couple this with the fact that I'm a hunt-and-peck typist, and you'll quickly understand why I'm a big believer in code reuse. The odd thing was that, with one exception, nobody ever noticed that code was being reused left and right.
On one of my last consulting assignments I met an intern who was fresh out of school yet was one of the sharpest developers I ever met. After working together for about six months, he asked me why it seemed that whenever possible I wrote reusable code that often used reusable code that I had written previously. There was only one way to answer: "I like writing tools to make tools."
A simple enough phrase, "tools to make tools," but what does it mean?
Ask me what I mean, and I'll say that it means that there is an underlying architecture that can be built upon. But to me personally, it goes much deeper than that. Take a moment and look around you; what do you see? You're surrounded by toolstools that shelter us, tools that entertain us, tools that preserve our images and thoughts beyond our individual lifespan.
Where did these tools that have become so important come from? Somebody created them, another person used them, and yet another person improved them. In essence, the Internet is merely an improvement of a cave painting taken to the nth degree. There's a long history of our species creating "tools to make tools." Therefore, it is only natural to create tools, share those tools, every once in a while wonder who will improve them, and lament the fact that you can't get a good mastodon sandwich anymore.