As an old timer, one of the things I’ve learned about the computer business is that the wheel gets reinvented again and again in an endless cycle. An older friend of mine spent his first two years at a high tech startup amazed that he didn’t need to innovate. He barely needed to think. All he needed to do was to remember what he had done in the past. Development, as far as he was concerned, was just “a memory exercise”.
My niece recently graduated in CS from Stanford, so I had a look at the a modern CS curriculum. The same solutions to the same problems seem to keep getting reinvented. It’s like evolutionary biology. If a plant is going to survive in a desert, it is going to have some things in common with a cactus. I think Paul Graham had some remark that every language slowly becomes LISP as it ages and gets more powerful. For example, anyone who read Fredkin et al’s LISP book back in the early 1960s gets LLVM.
Back in the 60s and 70s computer software was dominated by younger men. The original programmers were mainly women, but this was strongly discouraged in the 1950s. There were a number older men writing software, and they had often learned to program when their organization had obtained a computer and no one else was willing to learn how to use it. Still, most men over a certain age were hardware hackers. They often had fascinating stories, like running backup communications for the Yalta Conference or turning TIROS weather satellite image tubes like a champagne riddler to keep them from warping.
Why aren’t those then younger guys still working in software? To start with, there were fewer software people thirty years ago, so one would expect some age imbalance, but there are many reasons for leaving the field. A lot of software people work for “body shops”, so they were cost items in a field where management rarely had a clue about quality or cared about it. If they were any good, they got promoted and their salaries rose. Then they became too expensive. Think about this the next time someone grumbles about a major software failure. They likely fired someone who could have done the job in his sleep, probably worried he might start taking naps.
There is also the matter of advancement. There are only so many high level software job slots. Even companies who value their more experienced engineers can only afford so many “senior scientists” or the like. Also, these upper technical positions may lack any significant power. There is a strong temptation to move into management to get more control over one’s work, even if it means not being able to do what you do best. That’s more of a problem for the company than the individual, but this is a classic tradeoff for anyone in a technical field. Think about this the next time someone grumbles about his or her boss.
There is also flat out age discrimination. I remember my father dying his graying hair, and he was a successful civil service accountant. Still, he was worried about appearing too old for the job. It’s worse in engineering. There are tests you can give an accountant to tell if he or she is any good. It is much harder to assess programmers. To start with, very few people really understand what they do and what it takes to do it well. I always considered it a literary field, like poetry. It’s hard to test someone to see if they’d be a good poet too. It’s easy to see how old someone looks. It’s easy to tell if they are male or female or have a speech impediment or walk funny.
If you wanted to assess a poet, you might do the Google thing and ask them to compose a sonnet on the topic of high energy soft drinks. Alternatively, you might ask them to bring in a collection of their poetry. Even models have to lug around their “book” of photos, when you’d think people could just look at them to tell what they looked like. There are problems with looking at a programmer’s portfolio though. It is hard to tell how good software is by looking at it, and software is usually a collective enterprise.
One way to stop discriminating based on age would be to conduct the whole hiring process without getting a clue as to prospect’s age. This works for orchestras who rely on blind auditions. The other way would be to apply one’s intelligence and recognize one’s own biases. It is possible to fight these things. There is a tendency to confuse any collective enterprise with hanging around with one’s friends. Good engineering requires different sorts of people and is tempered by conflicts in world views.
There is a need for a prissy soul, intent on dotting the i’s and crossing the t’s, just as there is a need for a reckless one, leaping over chasms, fueled only by Red Bull. A good team needs someone who hates the work to encourage people to get things done once and for all. Didn’t David Mamet write a great speech about the importance of closing the deal? Throw in a pessimist or two, perhaps sobered by mid-life disappointments, to help modulate project scope. A clueless ditz or a wretched klutz could vastly improve the user interface. There is a place too for the young and optimistic, or the venture might never get underway.
Just about everyone in any large organization makes HR jokes, but human resources are really too important to consider merely as a source of entertainment. Building an effective team, a team with full coverage, is a serious matter. It isn’t about building a clone army or choosing a roommate. Gut feelings are not enough. Sometimes it pays to think seriously about the process.