I was recently described as being "old." By software development standards, this is very true. And furthermore, although there are some very sensible reasons why being old makes some things more challenging, it's a huge advantage in others.
For starters, there is the obvious thing that when you are old, you have a certain amount of experience. Most people think it works like this: Since I was already doing OO programming in Smalltalk in the Eighties and C++ in the Nineties, this means I will have an advantage doing OO programming in Java and Ruby in the Nought-ies (2000-2009).
The argument is that since you have seen something that works, you don't have to re-invent the wheel, you re-apply what worked in the old context (Smalltalk, C++) in a new context (Ruby). This happens to be true, and as long as you do not get into the habit of pooh-poohing new things (Ruby? Nothing new there, it's just Perl with a side of Smalltalk and the least important features of Lisp, all served on a bed of poor VM implementation), you can go far.
The real argument here is that you do not waste time re-inventing and rediscovering the wheel. But I think that there's an even more important advantage to being old: You have experience with what doesn't work. Now, when I read the phrase "Experience with what doesn't work," I immediately think "You know what doesn't work so you can avoid making the same mistakes again." This is not true. Avoiding something because it didn't work in the past is a liability, not an asset.
The voice that says "Putting several programmers in an open room where they can interrupt each other doesn't work, we tried that at Bell Labs in 1973" is the voice of someone who cannot appreciate that circumstances have changed, and that if you change a bunch of other things at the same time, putting an entire team in a single room can be more productive than putting them in offices with doors that close.
I was trading a few ideas with Pete Forde of unspace this morning, and I trotted out a metaphor. I apologise for this, I am not trying to turn this little note into one of those blog posts that tries so hard to explain that software is like a soap bubble or whatever. I despise the idea of saying that "Building software is just like X" for any value of X. But the metaphor was that of Mammals during the Great Extinction that wiped out the Dinosaurs.
Prior to the extinction, the story goes, Mammals were insignificant players. Dinosaurs were superior in every way until something happened--possibly the creation of the Gulf of Mexico--and the Dinosaurs were wiped out. This created a huge, world-wide opportunity for something, anything to replace them, and mammals happened to be better than everything else at taking over a vacant ecological space.
Great story. And? Old makes me great at telling stories? No. The idea here is that things that don't work very well can sometimes start working very well because of external developments that are difficult to predict. If we looked at Mammals before the Great Extinction, who would predict that they would dominate the Earth one day? There's a whole worse is better line of thinking to pursue, but here's the relevance for being old and having experience: Locked in your head are a whole bunch of ideas that weren't all that great and didn't thrive in their day.
But you have them in your head, and sometimes you can look at a new situation and say, "You know, this idea was a loser in 1989, but it just might work today." Experience with stuff that didn't work can be way more valuable than experience with ideas that worked at the time.
This would be how Ruby got its
yield keyword. Matz knew about a language called CLU, invented in 1974-5 by Barbara Liskov and her students (Yes, she is the Liskov of the Liskov Substitution Principle). Matz borrowed yield from CLU. Was CLU a success in 1975? Perhaps not in the popularity contest. But knowing about this "old failure" allowed Matz to use its ideas in a new way to help make Ruby a "new success."
This is a key benefit of being "older" and "experienced:" You know about old stuff that was ahead of its time, good ideas that didn't pan out for one reason or another. Recycling those is often worth far more than recycling things that everyone knew were successful back then.
A Call to Action
Today I said some uncharitable things on reddit. I had posted a link to some old research with what I thought were interesting implications, and someone rightly pointed out that the idea was (a) old, and (b) unfinished. I'm afraid I ranted a little, and that is too bad, I was wrong. You catch more flies with honey than vinegar, an old saying that seems to be even more relevant in the age of the Internet.
But I stand by my interest in old, unfinished ideas. These could be mammals! Why did they die? Who knows! But should we dismiss an idea because its originator did not turn it into millions of downloads and/or dollars? Who invented the first aeroplane? The first automobile? The first personal computer? If you said Wright, Ford, or Gates, you were wrong each time. The people who profited mightily from these inventions were the ones who recognized an unfinished, unsuccessful idea with potential and made it work.
Never mind whether I'm old or not, or whether I'm any good at turning yesterday's failures into today's successes. We all have this same opportunity to see something that has the germ of a good idea but it didn't turn into a success, it didn't become popular. We all have the same opportunity to say, "Things have changed since that failed, if we take the idea and do this and this and this, it may work this time around."
Unfinished ideas are opportunities. Old ideas are opportunities. Embrace them.
My recent work:
- jQuery Combinators, what else? A jQuery plugin for writing your own fluent, jQuery-like code.
(Spot a bug or a spelling mistake? This is a Github repo, fork it and send me a pull request!)