"Logan's Run" Syndrome In Programming

Ian Lamont writes "InfoWorld has an interesting analysis of the reasons behind the relative dearth of programmers over the age of 40. While some people may assume that the recession has provided a handy cover for age discrimination, a closer look suggests that it's the nature of IT itself to push its elderly workers out, in what the article describes as a 'Logan's Run'-like marketplace. A bunch of factors are listed as reasons, including management's misunderstanding of the ways in which developers work: 'Any developer can tell you that not all C or PHP or Java programmers are created equal; some are vastly more productive or creative. However, unless or until there is a way to explicitly demonstrate the productivity differential between a good programmer and a mediocre one, inexperienced or nontechnical hiring managers tend to look at resumes with an eye for youth, under the "more bang for the buck" theory. Cheaper young 'uns will work longer hours and produce more code. The very concept of viewing experience as an asset for raising productivity is a non-factor — much to the detriment of the developer workplace.'"

Comments

Obivous Answer

[cabjf]

Eventually people do tend to get promoted beyond programming positions.

Re:Obivous Answer

[starfishsystems]

"Beyond" programming?

When I look around, the most limiting factor I see in any enterprise computing environment is the quality of software in use. Multiple teams of people and multiple layers of management are required just to keep it working. Any upgrade plan sends ripples of alarm racing back and forth. And why is there such a status quo of vast inefficiency? Because software is as complex and flawed a contraption as inexperienced programmers can make it.

It takes an extraordinary person, one having both breadth and depth of experience as well as innate clarity of thought, to design even a moderately large system that's simple and sufficient, modular and extensible. Such people aren't to be found in anyone's junior staff. They don't have the experience. And their talents are lost if they should move into management or some other career.

It's not a question of "beyond" where programming is concerned. Unlike any other field, the medium in which we work imposes no ceiling on what we can do with it, Gödel incompleteness notwithstanding. There is no "beyond".

This is such an elementary insight. Since the field itself is not a constraint, what we can achieve is constrained by two factors: our own competence in the field, and time. Given two people of the same natural ability, the one with more experience will be more competent than the one with less experience. That's because, in effect, the experienced one has already put in the time.

Of course, inexperienced people might not know this.

Re:Obivous Answer

[Angst Badger]

Eventually people do tend to get promoted beyond programming positions.

Sometimes, though it's obviously a minority, or managers would soon outnumber their subordinates. I've turned down lots of management positions. The narcissism of non-technical managers is such that they think everyone wants to be like them, so they are quite sincere in their attempts to reward good programmers with management positions. The problem is that there is next to no overlap in the skillsets, and most often, what you get is a crappy manager in exchange for a good programmer. There are exceptions, but they are definitely the exceptions, not the rule. Some will accept the promotion with the idea that they'll run things better, but then they discover that the cluelessness of the non-technical manager they are replacing wasn't all or even most of the problem: there's the cluelessness of the next level of management behind it.

As it happens, I actually can do a decent job of managing people. The problem is that I'd rather flip burgers. Consequently, I've stuck to programming and kept my skills updated, but at 39, I'm looking at the reality of a career change in the mid-term future. I'm not terribly worried about it -- I'll have the kid through college in four more years, and after that, I can afford to live on a much, much smaller paycheck.

Should it be that way? No, of course not. But absent some kind of organized labor movement -- which programmers are notoriously, irrationally averse to -- it's not going to change, as the people making the hiring and firing decisions are getting by just fine with the current system. There is then little choice but to adapt, or at least emigrate.

Re:Obivous Answer

[Late Adopter]

It takes an extraordinary person, one having both breadth and depth of experience as well as innate clarity of thought, to design even a moderately large system that's simple and sufficient, modular and extensible. Such people aren't to be found in anyone's junior staff. They don't have the experience.

Agreed in entirety! But design and architecture are one of the options I think of when I hear "beyond programming". I don't want the smart people languishing as code monkeys forever, their insights are lost there to all but themselves.

Re:Obivous Answer

[JWW]

You know, regarding your carousel comment. Its kind of ironic that the referencing of Logan's Run as a corollary explanation for why there are so few older programmers, is a reference that younger programmers wouldn't know.

Re:Obivous Answer

[starfishsystems]

Thank you! I think we're in general agreement, but let's explore the implications a bit further.

Is there any substantive dividing line between design and implementation? If there were one, then people could indeed be left languishing on the wrong side of it. But I don't see one. I think that to impose one is entirely artificial.

If you're designing and writing specifications without thinking about implementation, you're not giving your best. If you're implementing a spec without regard for principles of design, well, that's just stupid.

But more than that, it's often the case that the exercise of building something sheds significant light on its design. There's a lot of natural interplay between these two perspectives, in other words. When we discount that interplay we end up with development processes that don't work well at all, because they're not fully informed.

I need to backtrack a bit here. The problem comes from applying processing concepts to software development that were evolved from the manufacturing industry. In manufacturing, you know what needs to be made; you just have to figure out how to scale up the volume of production. We don't have that situation in software. Far and away the hardest part is expressing what needs to be made, because it's unique each time. The fabrication is trivial.

Of course there are huge varieties of class libraries and operating system features on hand to provide the nuts and bolts when developing software, but that resource doesn't touch what makes software design a cognitive challenge, and it merely shifts where the cognitive effort of implementation has to be applied. We're still fundamentally conditioned by the two factors I cited before: competence and time.

To get back to your point, I believe we agree that value is minimized when anyone is asked to function merely as a code monkey. I'm arguing to do away with the distinction. This partitioning of the problem space is pure artifice, a residue of thinking carried over from the Industrial Revolution. I've found that the way to get the most out of people is to let them participate across the broadest range in which they're presently capable. As their capabilities grow, reward them with more involvement and more responsibility. And don't forget to pay them accordingly.

That's how to address the problem of "languishing" that you rightly identified. But senior developers must not be taken out of the coding process. That's a huge mistake. Yes, they have to divide their attention across many areas, but that's what qualifies them as senior. If you don't expose the junior people to mature ways of thinking, you're throwing away huge opportunities for motivation, mentoring, and just plain knowledge transfer. Worst of all, you end up with a pool of junior people who are disconnected from the rest of the development organization. I see it all the time, and it's toxic.

jaded

[convolvatron]

the problem with having older programmers like myself is that they are fully tired of being jerked around
by incompetent management. if you've worked in 20 shops, and run a few yourself, you're alot less
likely to happily pull an all nighter to try to get the release out the door. you understand
that this all could have been taken care of months ago, and you went to some pains to point that
out then.

the other kind of older programmer has just given up. they know better, but they understand
that bitching isn't going to solve anything and they need the health insurance. they look alot
less capable then they are because they just agree with everything and try to get out the door
by 5.

younger programmers dont know any better, they will believe whatever you say

Experience

[copponex]

Across every industry I've been involved in, a good piece of advice from an old business mentor has held true:

When you pay an expert $100 an hour, you're not paying them for the hour. You're paying them for the years of experience they have plus an hour of their time.

This also dovetailed well with what a mechanic told me when I was trying to lowball him: "When you pay peanuts, all you get is monkey business."

Re:Yes and No

[2short]

True, but if it's for a job doing .NET programming (for example) a lot of people doing hiring will take the guy with 1 year of .NET experience and nothing else over the guy with 30 years experience in 5 different languages and no .NET. All else being equal, the latter guy will probably be more valuable.

Youthful arrogance....

[realsilly]

Is the younger generation of programmers really that arrogant to think that older programmers don't know and learn new languages and coding trends? it is my experience that the best coders out there are those over 40. Not only are they on top of technologies that are current, but they understand why those technologies came to be and what they helped to improve. Many of them learned on the job, in a budding industry.

Just a few days ago there was a post right here on Slashdot asking how easy it was to cheat in CS. Based on the forum discussions, a significant number of students today get programming degrees and can't produce a lick of decent code.

This is NOT to say that there is not an abundance of exceptional young talent, there is, and they deserve good work and decent pay, but this is in defense of those who helped pave the way.

Re:Yes and No

[LWATCDR]

"The fact that you have 30 years of COBOL experience doesn't help you if you don't learn new technologies."
learning a new language is easy. Learning to program is hard.
c, java, c#, php, perl, are all very much alike. Once you know one learning the rest are easy.
In your typical application program so much code is now offloaded to the libraries that once you leave school you are unlikly to have to write a HASH or a sort every again.
What experence teachs you is when you need to use a hash vs a btree.

Re:It is age discrimination - Yes, It is

[tsm_sf]

I was once young enough to work 16 hour days. Now I know better. That is the entirety of the "problem".

Re:Yes and No

[Opportunist]

Just wait 'til Y3K rolls over and we old COBOL proggers will be sought after again!

Ok, aside of lame jokes, it's a misconception that "you have to know $language_FOTM to be useful". You have to know how to program to be useful in the long run. Of course, all those fast breeder COBOL programmers that were cranked out 30+ years ago when COBOL was the be-all, end-all language of the trade will not have any future. Neither will the same kind of fast breeder .net codemonkeys have any. They will be used now 'til nobody cares about .net anymore, then they will be tossed and retrained to ... car salesmen or whatever needs more people then.

What's left is programmers who do not learn a programming language but to program. It does not matter if you write C, C++, Java or C# code. It's basically the same concept. I could see that there is a genuine difference between an imperative and a descriptive language, but ALL the languages mentioned above ARE imperative. If it does matter to you that you're supposed to use a different one, you have no right to call yourself a programmer in my eyes. Because the algorithm does not change. The words you write, the symbols you use and maybe a few tidbits to take care of do. But the foundation stays the same.

Programming is not knowing an API by heart. That's something help files are here for. Programming is not knowing what library contains what functions. Check your manual for reference. Programming is knowing how to translate a problem into code. What language is used to do that translation is not important.

Re:Yes and No

[mollog]

Experience is key. The issue is that new applicants coming out school have more experience with .NET, Java and they key technologies that many industries are looking for today.

Arrant crap. The best programmer I know is in his 60's and got his start on IBM mainframes. He's the go-to guy when you're writing a new OS for your next imbedded application. As others have already said, once you've been through a few languages, JCL, Cobol, Fortran, C, C++, Java, TCL, the next language doesn't even register as a 'new' language.

The reluctance of younger managers to hire older programmers has less to do with skill and ability, and more to do with psychological factors such as an older programmer's ability to instantly see the folly of what a younger manager wants to try. Been there, tried that, fuggetaboutit.

Re:Yes and No

[Minwee]

On the other hand, the guy with thirty years experience probably expects to leave the office at the end of the day and not work overnight and on weekends. The guy with one year of .NET experience may even believe tales like "We're going to have to put in a few extra hours to finish this project, but we'll make it up to you after we ship", "That's the way everybody in the industry does this" and "I'd hate to see you have to leave the company because you didn't want to be a team player".

While the more experienced developer is obviously a valuable addition to a well run team, Junior is much easier for a dysfunctional team to exploit, throw away and then replace next year.

Re:Young programmers keep me employed!

[Mongoose Disciple]

Eh... I don't think the GP's post was quite as unfair as you think.

Don't get me wrong, I've worked with some amazingly brilliant and hardworking Indian developers, but at the same time, it really isn't a rare thing to see an outsourcing firm sell an experienced dev team that really really isn't. Often they will have one legitimately solid guy come, meet the company, and sketch out the initial design, and then you'll never see that guy again. Some variant of that's happened with every outsourced project that I've been involved with across a decent handful of companies and industries.

It's a shame that unscrupulous outsourcing companies are giving a whole country full of developers (incidentally, I'd argue that's nationalist and not racist, but maybe that's splitting hairs) a bad name, but most managers making the decisions don't know enough to tell the difference between the two.

Re:I've seen that happen over and over

[russotto]

Seriously, why the hell do people stop doing good work and become bosses. Why isn't there a bachelors degree in management with entry level boss positions. Why are bosses paid more?

The bachelor's degree in management exists (the Bachelor of Business Administration, known from the expression "The limit as GPA approaches 0 of the Computer Science Student is the Business Student"). But to get an entry level boss job without experience you usually need the MBA. Knowing the owners/board members/executives doesn't hurt either.

Why are bosses paid more? Well, because they're bosses. They're making the decisions on salaries.

Fact is, positions where you _do_ something will always be at the bottom of the hierarchy. To be a "higher up", you have to be higher than someone -- those who report to you. So unless you want to be on the bottom forever, basically just doing what you're told and with no real input into any corporate decisions, you have to go into management. Or into business for yourself.

Militaries make this explicit: you can be the best infantryman, combat engineer, tank driver, or whatever, but it doesn't matter; you're still an enlisted person and you still have to grovel to the most junior officer (manager) in the service. It's the same way in the corporate world, they're just less obvious about it, and there's more mobility from grunt to manager in most cases.

Re:Yes and No

[Alinabi]

What experence teachs you is when you need to use a hash vs a btree.

Actually, school teaches you that. If it didn't, you were not paying attention in class.

Re:Yes and No

[khallow]

Actually, school teaches you that. If it didn't, you were not paying attention in class.

You make a common mistake. Teaching is not the same thing as learning. Learning is what sticks and it includes knowledge that didn't come from the "teaching" end.

Re:Yes and No

[bittmann]

I maintain C code written by a COBOL programmer. You can tell.

The code is written in a verbose, heavily-commented, yet easy-to-read style, and actually does what it appears that it should?

Re:It is age discrimination - Yes, It is

[mcgrew]

I was once young enough to work 16 hour days. Now I know better. That is the entirety of the "problem".

My friend Amy, whose dad would be a year younger than me had he lived, is amazed by my ability to come home from work, drink with her until the wee hours, and get up and go to work the next day. Perhaps that's because I was never stupid enough to work a 16 hour day -- I don't live to work, I work to live. I've been like that since I started working at age 16. I'm 57 now and look ten years younger than friends who are ten years younger than me.

Hell, I once passed up a promotion just to not have to work overtime. Money is just a tool, and one should never let his tools get in the way of what you obtained the tools for in the first place.