Old programmers
A correspondent writes:
How does one continue to build a career in software development, when there are younger, hungrier people (i.e.people who can, and will work 16-hour days and can learn things at a ridiculous pace) joining the field?
I’m at the ripe, old age of 33 and am already feeling like it’s a challenge to keep up with the 23-, 24-, 25-year-olds. :/
Also — and I know this is partly a function of the field’s explosive growth over the years — but I just don’t see that many software devs in their 40’s and up, so I don’t have much in the way of precedent to observe, in terms of a career path, other than going into management
Since I’ve pretty much decided to devote this next decade to programming, part of it for hire, this is an important topic to me. (I’m 50.) I don’t know that I have much useful to say, though. Nevertheless…
-
In a team, some people serve as catalysts for other people’s abilities. For example, ever since my 20’s, I’ve been hung up on friction-free work. So I was more likely than other people to make the build work better, write and share emacs functions to automate semi-frequent tasks, or to work on testing. Those are not glory tasks—”I’m a rock star build-fixer!”—but they help the team. As the team’s codger, I might emphasize that bent even more, freeing the team’s whippersnappers to concentrate on the most prodigious feats of coding.
A typical way in which an older programmer can catalyze is by paying attention to human relationships. If you can avoid the damnable tendency old people have to pontificate at people or tell only marginally relevant stories about how they did it 20 years ago, you can be a person who “jiggles” teams into a better configuration. (Term is due to Weinberg’s Secrets of Consulting, I think.) The ideal role is that of player coach (but one gradually recognized by the team, rather than appointed for it.)
-
Another reason for the patriarch to work in a tight-knit team is that a young programmer’s advantages are not uniform. For example, what makes me feel most like a doddering oldster is the sheer amount of stuff kids these days know about: tool upon tool upon tool, gem upon gem upon gem, the 83 new things in the newest point release of Rails, etc. But if you have one of those people on the team, the advantage accrues to everyone, and the centenarian’s loss of a pack-rat mind is not such a disadvantage.
When what matters is the team’s capability, balance is more important than each individual’s uniform excellence. So when fogy-dom looms, focus on being complementary rather than unique.
-
A traditional way for the older programmer to cope is by being one of the dwindling number of experts in a has-been technology (Cobol being an example, Smalltalk being another). That technology doesn’t necessarily have to be boring. Sometimes, as has sort of happened with Smalltalk, Lisp, and maybe the purer functional languages, the has-been becomes hot again.
A perhaps-related route is to become an expert in a very specialized and difficult technology like, say, virtual machines or security–something that’s difficult to pick up quickly and requires continuous learning.
-
Now that we’ve learned that legacy code doesn’t have to suck, perhaps the graybeard should angle to attach himself to a particular large and long-lived code base. There could be a lot of pleasure in watching your well-tended garden improve year after year.
-
It’s also useful not to act old. For example, I have to fight the urge to be sort of smug about not knowing CSS. In my case, of course, I don’t because, well,… CSS. But it’s easily interpreted as my saying “Oh, another passing fad, *Yawn*, give me RPG any day”. Similarly, I should be careful of saying things to Clojure programmers like, “Well the way we did that in my Lisp days was…” As a final example: this website looks like I’ve learned nothing about web technologies since 1994.
People are sensitive to old people acting old. The flip side is that it’s easy to subvert expectations. I think it’s a good strategy to be able to talk in modest depth about two or three technologies that are sort of new or even faddish. So, for example, I’m pleased that I can talk about Clojure, Cappuccino, and, oh, Sinatra. You want to both present the appearance of being able to–and actually be able to–synthesize the past and the present.
-
Finally: if programming is indeed one of those fields where you do your best work young, older people should be paid less. Older programmers can compete by somehow (credibly) asking for less money.
That “credibly” is an issue though, since programming is something of a macho, boastful field. In such, a declining salary is easily taken as a big red flag rather than a realistic acknowledgement that–say–short-term memory and concentration are important to programming and both get worse with age.
Other thoughts that might be of help to my fellow coffin-dodgers?
May 10th, 2010 at 3:45 pm
One more way that oldsters can compete:
Youngsters are all action and heat, but not so much light. Oldsters may move a bit more slowly and more deliberately; but don’t mistake that for the inflexibility of age. Rather it is the wisdom of experience that informs the oldster’s actions. One very wise man once said: “When it comes to software, it never pays to rush.”
I remember several years ago, James Grenning and I, (both in our early 50s at the time) were in an airport with a group of hotshot Thoughtworkers. Our flight was late, and the youngster’s decided to race each other in writing Langton’s ant in Java. James and I had already had a gin & tonic, but decided to sit quietly in the bar and see if we could write the program too. Twenty minutes later, while the boys were still banging their keys and swearing at their screens, we ordered another gin & tonic while watching the ant crawl hypnotically across our screen. Of course we said nothing at the time.
May 10th, 2010 at 3:52 pm
I would like to add stay flexible. I worked with a developer in her 60’s that retired because she didn’t want to learn HTML and GUI. I work with a developer about 65 who feels the same way but is not ready to retire yet but does not want to learn new things either. Hence no growth there; just a lot of negativity and rambling about health issues. I work with a developer about 75 yrs old who is absolutely wonderful to work with, brings a lot to the team and has a superb attitude. Attitude is everything no matter what the age.
May 10th, 2010 at 4:07 pm
This doesn’t apply only to programmers, though admittedly it can be more obvious when a programmer is not learning new things, especially for people who don’t know much about testing. I’m starting to think learning’s at the center of everything successful. Teams succeed when they have a learning culture, time to experiment, a management that tolerates mistakes. People succeed when they continually learn and improve.
I’m not very good at learning new programming languages and tools such as Rails, but I’m always trying to learn my company’s domain, better ways of testing, new test tools, how to collaborate better, all kinds of skills. I try to keep improving my attitude, too!
May 10th, 2010 at 4:17 pm
I’m 51 next week and happily cranking out code every day. I don’t think I write faster than I used to, but I tend to write, er, righter. I’ve earned a good living with COBOL, PL/1, C, VB, Python and Ruby to date, but I’d say the really big advantage that I’ve been able to accrue has been domain knowledge that has made it possible to migrate away from corporate cost-conscious “enterprise IT” into a customer-facing business unit where I’m valued for the combination of business and technical knowledge that I bring to the party. It’s worked for me because I stumbled into a business that was interesting to me and that presented me with problems that I enjoyed - and still enjoy - solving.
I’ve worked with any number of people who “grew out” of programming. Some fell out of love with it, others were never passionate about it and actively sought an exit. Some are still there, hating it in the shadows because they don’t, can’t or won’t see an alternative. And a few are still there because they can’t imagine how they could have more fun doing anything else. I think part of the trick is the enjoyment to be derived from learning something new, and in finding an opportunity to learn something new in even repetitive tasks.
May 10th, 2010 at 8:31 pm
My Dad was a practicing pathologist into his mid-seventies. Throughout his professional career, he had to keep abreast of advances in the science as well as put in 8 or 9 hours a day in work that required intensive concentration. He and I have sometimes compared the kind of regular effort it takes to be an informed physician and what it takes to be an equivalently competent software developer. His longevity in the practice gives me hope that I’ll get to do this kind of thing for still quite a while longer.
May 11th, 2010 at 5:14 am
Two months ago I joined a team of (much) younger developers writing telecoms software. This is a new field for me, and at first I thought I was just too old and dumb to work there. Then I realized that most of the people working there were just as inexperienced with erlang as I, and my experience in embedded systems gave me a much better feel for massively parallel systems than most. Now I’m finding that I’m able to suggest techniques that we old fogeys had to use when working with systems with substantially less performance; these algorithms are new and intriguing to the younger developers, and allowing us to optimize our product. We may not all be able to run at the same speed, but everyone gets to contribute given a little adaptability.
May 11th, 2010 at 6:39 am
As a 34 year-old developer specializing in security and virtualization, this article definitely hits home with me. It’s weird being “the old guy” while, well, not being that old. I think this article is right on, especially the bit about the “grumpy old man stories.” Anyway, a few things I do to help mitigate the problem:
1. Don’t live an old guy lifestyle out of work. Talk about your hobbies. A lot of young coders don’t get out too much, so this wins some respect.
2. I offer to do some “blocking” with management for them. That is, sit in with/for them in a boring meeting, help with forms, route to the corporate folks when they have a problem. In return, you can usually pick their mind about that new gem they just submitted a patch for on github.
May 11th, 2010 at 11:13 am
At a client a couple of years ago, a manager asked me to have a look at a resume he had received. It was from an old colleague of mine who was being proposed for a contract development position. At that time he would have been around 50 but I knew him about 8-10 years earlier when he was a designer and developer. He knew his shit and was great to work with.
The manager was concerned about his age. “Why is he still doing development at his age? He should at least be an architect by now.” My old colleague wasn’t hired.
IIRC, that old colleague’s wife made vast fortunes as a Peoplesoft consultant, or on some other ridiculously expensive and complex steaming pile of software. So, my old colleague didn’t need to be interested in moving up the ladder to higher income levels. He loved to write code and solve problems. In this particular case, the bias against age bit him in the backside. Too bad, too… he would have made a great addition to that team.
May 11th, 2010 at 7:12 pm
“Talk about your hobbies. A lot of young coders don’t get out too much, so this wins some respect.”
Back in my tester days, one strategy I used was to demonstrate unexpected semi-expertise about obscure fields. At one point, I knew a surprising amount about Greek oared ships.
In the days when I hobnobbed with PhDs, I was at a disadvantage because I had only an MS in computer science. So I never talked about that. Instead I talked about my BA in English Literature. In a context where you both have that and can talk sensibly about call-with-current-continuation, you become hard to categorize.
However: I think the problem is less winning respect once you’re on the team, more getting on the team in the first place.
May 11th, 2010 at 11:30 pm
“Finally: if programming is indeed one of those fields where you do your best work young, older people should be paid less. Older programmers can compete by somehow (credibly) asking for less money.”
Though age discrimination does happen, I’m sure, I think in a field such as software engineering, especially wrt Ruby on Rails, its not how young you are but in what concepts you understand, experiences you’ve had, etc. Though I’m not a fan of titles, the reason why someone is hired as a senior developer or architect is because they know a.) the right tool for the job, b.) when to pursue a particular solution further and when to give up, c.) how to evaluate quality of code, d.) the underlying principles and how to apply them (algorithms/grammars/design patterns). e.) how to lead the team to success (whatever that is). All of those things come from direct experience as a culmination of the time spent as an underling software developer earlier in a career and as time spent as someone further up the hierarchy (regardless of the language/methodologies/successes/failures because things can be learned from mistakes/failures as well). Advantage goes to older developers on this one. The days of blending in, accepting a story and sitting through meetings quietly, however, are over for the the older developer. They should and will be expected to take a leadership role because that’s what the boss is paying for, their experience and recommendations.
Finally, if you are worried about keeping up with all of the gems/libraries/eggs/nextcoolthingeveryoneisusingbutyou, knowledge is just a google search away, focus on your strengths which are the fundamentals, not how much you can cram in your brain.
May 12th, 2010 at 8:38 am
Do most old programmers stop learning? At 54, I feel that every year I’m more effective than the previous year due to my expanding range of knowledge.
Besides, program design and debugging skills improve with experience. Knowing the APIs doesn’t give you the intuition to know which things could be encapsulated into functions, and where the boundaries of module functionality should lie. (Or am I an idiot for assuming that anyone other than writers of books care about such things?)
May 14th, 2010 at 8:02 am
It’s true that programming doesn’t retain people like other fields do so there aren’t very many old programmers around. Someone did a study (sorry I don’t have the link) comparing CS majors with other engineering majors and found that the other engineers are much more likely to stay in their original field 10, 20, and 30 years later.
Perhaps this is related to the attitude daverooneyca described. That programming manager thought only young people should be programmers, that it’s a low-level job only suitable for kids starting out. And didn’t hire the 50-ish guy.
I haven’t seen resistance to change to be related to age. Some people refuse to learn new skills as they get older but some young people refuse to leave their comfort zones, too. It’s surprising to me that many web designers and developers, often young ones, don’t want to believe that their potential customers may have small screens or slow connections or older browsers (even IE!) and refuse to code their sites to handle that.
May 22nd, 2010 at 7:05 pm
According to some creditable research, middle-aged brains are generally better at inductive reasoning and problem-solving than younger ones:
http://well.blogs.nytimes.com/2010/04/30/the-talents-of-a-middle-aged-brain
That’s from ages 40-65. Worth keeping in mind.
June 1st, 2010 at 1:32 am
[…] denne blogposten om hvordan det er å være en gammer programmerer refererte Uncle Bob Martin i kommentarfeltet til noe han kalte Langton’s Ant. Wikipedia kunne […]