"Logan's Run" Syndrome In Programming 599
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.'"
Obivous Answer (Score:5, Insightful)
My own two cents' worth (Score:4, Insightful)
Not only are younger coders generally cheaper, they also generally are more into the "new technologies" -- as a programmer gets older, it becomes almost a second job to keep up with the new technology as it comes out, and at some point I suspect that many just decide it's easier to get off the carousel and go find something else to do.
As an example, if you've been coding in COBOL for 20 years, Java can be an awkward language to learn. However, many new grads in the last 10 years learned Java as their first language. As such, even though the senior coder probably would perform better in the long run (due to more experience with designing efficient algorithms and more knowledge of internal business processes), management would likely hire a couple of recent grads rather than pay to have our COBOL programmer trained in Java.
Career path (Score:4, Insightful)
As others have already noted, the career path of technical people often moves beyond "just programming" at some point. By the time folks have reached 40, they've (hopefully) got a good sense of how to make good decisions about what products and features to develop and how, not just how to write efficient code.
While some of the technical leaders in my area do write some code, the bulk of what they are needed for is making decisions about what we ought to be doing, and providing guidance for the younger programmers or ensuring quality communication with other lead developers.
It is age discrimination (Score:4, Insightful)
The summary says that it's not merely age discrimination, then goes on to say that they hire younger workers because they are cheaper, without bothering to account for experience.
That is age discrimination.
What a horrible, stupid summary.
KMA whipper snappers (Score:1, Insightful)
I'm in my mid-40s and my buddy at work is in his 50s. We run circles around little whipper snappers from R&D and standards to best practices, hands down programming, etc. To actually find someone young that has a real CompSci degree (MBA and MIS doesn't count), real experience or even a fundamental understanding of OOP, RDBMS design, security, static code analysis, etc. is far and few between. Keep on hiring cheap labour (Ranjit and Chad from Tech & Talk) and we'll keep on debugging and fixing their code!
jaded (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
True, but if it's for a job doing
Re:I've seen that happen over and over (Score:2, Insightful)
Bossing, and doing are two different things that don't have much overlap. It's good for a boss to be knowledge about what his worker bees do, but it's really not that crucial. And the skill overlap between a boss and a worker is hardly anything. Ok, sure, the skillset of a boss includes babysitting, settling disputes, wagging fingers, and sucking up to higher-ups. All sort of common sense skills that anyone could have, but not a specialty of workers. 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?
Inertia isn't reason enough.
Youthful arrogance.... (Score:5, Insightful)
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 (Score:5, Insightful)
"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.
The third way (Score:3, Insightful)
There is a third kind of older programmer: disillusioned with crappy management but still wanting to do development, they strike out on their own. They either go freelance as some sort of contractor/consultant, or found their own company and bring in other people to do the business side of things while they stay technical.
Re:It is age discrimination - Yes, It is (Score:5, Insightful)
Re:Programming has Changed (Score:2, Insightful)
Re:Yes and No (Score:3, Insightful)
learning a new language is easy. Learning to program is hard.
QFT
IANAP but have written code as a hobbyist. I'll spend hours writing and rewriting something only mildly complex because, while I understand the languages and syntax well enough, I use trial and error to find the right methods. Starting with only a vague idea of how I want something to work doesn't help, either. Good programmers know the right methods already, and learning how those methods are applied in any particular language is trivial.
Re:jaded (Score:3, Insightful)
Ah, but which way do you go?
If you move from job to job on a regular basis, you're seen as an opportunist who won't stick around for long.
If you stay in one place too long, you're seen as being stuck in a rut and not growing your skillset (nevermind what the truth might actually be).
I personally prefer to stick with a given company long enough to learn the ropes in some detail, and I would have actually preferred to stay with my previous two employers until retirement (the work was interesting enough), but corporate layoffs have a way of changing an individual's career path. :-)
Re:Yes and No (Score:5, Insightful)
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 (Score:5, Insightful)
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:Kids Today (Score:3, Insightful)
Re:Young programmers keep me employed! (Score:2, Insightful)
That was a bit racist, don't you think?
I am an "Indian" (actually Sri Lankan) Developer, who started programming when I was 7, on a Sinclair ZX Spectrum (not just Basic, but loads of yummy Z80 Assembly). I was brought up in the UK.
My Father-in-law is also a Sri Lankan Developer, who was brought up in Sri Lanka, yet has worked in USA, Singapore, and UK on lucrative contracts.
When we say that we are EXPERIENCED Developers, you can count on that. We earn craploads of money, fixing the bugs created by other so called "senior developers", who then get pushed into PHB/Management roles, still earning less than us.
So stop being a bigot, and prejudiced.
Re:Yes and No (Score:5, Insightful)
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.
24 months to burnout on average? (Score:3, Insightful)
Two years seems to be the developer half-life in most shops. By that point if you're worse than average they've canned you, and if you're better than average your responsibilities have grown to the point that you're spending as much or more time dealing with cross-team organizational bullshit as you are doing what you actually love (writing code) and hence wanting to quit. :) The thing is, I think every gig has problems, and often they're the same tedious set of problems, but people jump in the hopes that maybe, maybe the grass will actually be greener THIS time. (After a decade or two of corporate culture, further, it's all too likely that the truly idiosyncratic individuals will have accumulated enough capital and enough disgust with the system that they give it all the finger and go run a bar just to pick one prominent example.)
The other direct motivator that comes to mind is money. All too many shops hire you at a rate that approximates more-or-less-if-you're-lucky Market Rate for your skills and so forth, then want to give you sub-10% raises for ever and ever thereafter. Ergo it's easier to ramp your salary in tune with your experience by jumping periodically. This is perhaps most prevalent in the first ten years of a programming career as there are big deltas at roughly two and five and seven-ten years of experience as you start to [potentially] hop up the org chart some from junior to regular to senior dev.
So in short I think that getting fed up with a given situation and taking steps to change it for (hopefully, maybe not, probably not... but hopefully) the better is both normal and healthy. Or are you of the opinion that backing the same crappy horse for years is the best way to go through life?
Re:"Elderly"?!?!? (Score:3, Insightful)
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... 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.
I think I just read the definition of age discrimination.
Re:Yes and No (Score:3, Insightful)
Older programmers will typically not repeat the same naive mistakes again.
OTH
A large percentage of older programmers are unable to learn a new programming model. For example: Object Oriented coding. There are some who just do not get it and will write procedural code in object oriented languages.
by and large, programming as a field in general has such low status and poor conditions that I can't recommend it to anyone any more. Go into programming if you
a) want to likely suffer terrible age discrimination and a truncated career.
b) want to spend a lot of your time learning new ways of doing the same work*
c) want substandard pay for the effort put into the degree.
d) want to compete with people in third world countries who feel like kings on $15,000 a year.
e) want to be forced to work nights
f) want to be forced to get up at 5am
g) want to be forced to work holidays
h) want to be forced to not take a vacation over one week long
i) want to have no respect from the business at all (unless your business is selling software-- but then see EA so not even then)
j) want to be forced to implement stupid solutions that you know will fail because some lame brained executive won't accept your input.
* Don't get me wrong- some people like learning. But unlike plumbing, accounting, legal work, management, heck even engineering (which has a lot of training but minimal compared to IT), in IT, every 3-5 years, you pretty much have to toss out everything you know, learn the new "big thing" while ruthlessly ignoring good but dead end jobs.
Oh and
k) have a harder time finding a spouse given your lower status AND have a harder time keeping one given your unreasonable work hours and substandard pay and general societal low status.
Re:Obivous Answer (Score:4, Insightful)
Why are we even considering that "more lines of code" is a good thing? It's more bugs. I'd rather write half as much code, spend half as much time debugging it, and go home. I fear enthusiastic younglings who thrash out a thousand lines in a caffeine fuelled late night Code Rage, then spend the next two days thrashing out yet more code to fix their mistakes - or more usually, press on to screwing up the next new feature, and leave us old guys to clean up after them.
Re:jaded (Score:3, Insightful)
You know being jaded may be the case. As an IT Manager myself I have rejected a lot of older developers not because of skill sets but because of that jaded attitude
Firstly how do you know that a particular programmer has that jaded attitude beforee you've hired him? Secondly, have you thought that if you're having this problem that its because you're not effectively managing the guys (which is, after all, your job). Thirdly, have you considered that they might be right? (no, didn't think so)
I find that the older coders are the ones who go with the lighter development processes becuase they've seen the 'Architectures' that are created in the past and will warn you against them. Sub-optimal? Often not the case. Its usually the younger guys who want to rewrite everything, who want to create a massive abstraction base that'l be 'so much easier to maintain in the future' (lol, seen that a few times. No, I've never seen them work either. Hmm, perhaps that's why the young guys like to rewrite so often).
And so on, sure the older guys may complain (ie offer you the advice of their experience) and yo u can quite happily ignore them, tell them to shut up and get with the program for something that they know will not go right. Try taking their experience sometime and working with it - you'll end up with happy workers, and better product. ...where your experience is helpful for the process not an ego boost to yourself where you need to hinder the process so you can be right.
sounds like a lot of managers I've known :)
Downtime and Experience (Score:2, Insightful)
Re:Young programmers keep me employed! (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
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:Obivous Answer (Score:5, Insightful)
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:Young programmers keep me employed! (Score:3, Insightful)
Ahhh, so you mean a programmer from a "code factory" based in India? And you are talking about code coming FROM such a coding factory?
Fair enough, your post implied that you meant "Indian Origin" programmers, which is way too broad a statement, hence my call on racism.
I do agree that those "coding houses" can be problematic, I myself, when working for LogicaCMG, had to fix code from the Bangalore Office.
Most often the case usually was that the "Engineers" had a chip on their shoulders for getting employment in a "large company", etc, and thought they didn't have to *learn* anymore.
Re:Obivous Answer (Score:5, Insightful)
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:Yes and No (Score:5, Insightful)
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:Obivous Answer (Score:3, Insightful)
Eventually people do tend to get promoted beyond programming positions.
And the other 90% that don't get promoted because those spots were filled by the 10%?
Agreed. That's always been the case.
I think the real reason is simple. People older than me (almost 40) are likely to be mainframe programmers. Back then, there weren't a lot of computers. So there weren't a lot of programmers. The office where I work now is filled with people around 40yo doing c++/unix. Come back in about 10 or 20 years, and you'll see a lot of older programmers.
Dude, I couldn't disagree more.
C++ was taking hold as a mainstream language in the early 90s. Borland C++ came out in 1988 - I believe. When C++ came out and it was making a BIG splash I was in my early 20s. At the beginning of my development career, I was strictly C/C++ on PCs,Servers, and workstations. Back then, just knowing a language was enough, meaning a job description was "2-5 years C++ experience. AT&T Unix a plus" - I really miss those days!
In my say we made fun of the mainframe programmers as being old fogies.
Lastly, I'd like to point out, I know a few mainframe programmers and whenever they've been laid off, they got a job within a year - even when they're over 40. And here's the funny thing, the latest hardware technology is being developed for the mainframe. That wasn't the case when I started out. IBM develops a COBOL compiler and whatnot for the mainframe and on their way.
COBOL the language for the latest hardware.
Re:No really (Score:2, Insightful)
Failure of management (upper, middle or first line) to recognize ability coupled with a desire to streamline costs can do more harm than good.
I have seen cronyism, nepotism, corruption, theft, drunkenness, piss poor attitudes by both young and experienced workers.
I have seen managers that were aware of the above state that "they had no idea", and managers who took advantage of the situation by using the above information as leverage to ensure their own agendas were supported rather than corporate agendas.
It is truly sad that technological advances are crippled by flatlander mentalities.
Re:Obivous Answer (Score:2, Insightful)
Why is it that a "promotion" in the programming field is always to management or something beyond programming?
You don't see surgeons hoping to become hospital administrators, or research scientist hoping to become university
administrators...
I have never understood this paradigm - reward for technical prowess shouldn't be to remove that item from the technical realm...
Re:Young programmers keep me employed! (Score:2, Insightful)
Re:Programming has Changed (Score:3, Insightful)
Sure, but what do you think 40+ year old programmers have been doing for the last 20 years? We might not have been taught OOP but we've been using it since the guys who were taught it, were in diapers.
Cheaper young 'uns will work longer hours? (Score:4, Insightful)
I have observed the opposite. The young 'uns want to go home early so they can party and come in late 'cause they partied last night... And at home, when I'm punching in some extra hours, I only ever see old farts still on-line.
Re:Yes and No (Score:5, Insightful)
The code is written in a verbose, heavily-commented, yet easy-to-read style, and actually does what it appears that it should?
Re:Obivous Answer (Score:4, Insightful)
Re:jaded (Score:3, Insightful)
If you stay in one place too long, you're seen as being stuck in a rut and not growing your skillset (nevermind what the truth might actually be).
That mindset is probably not as prevalent as the opinions about job-hoppers you described ... It can also be countered by simply devoting more space in your CV to the skills learned/applied and work done during that time. But one thing I can guarantee: no employer wants employees that resign simply because they are concerned with the attractiveness of their CV above everything else (or any other things that are far beyond the employer's sphere of influence).
Re:It is age discrimination - Yes, It is (Score:5, Insightful)
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.
Re:Obivous Answer (Score:5, Insightful)
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:Ummmmmm, completely incorrect (Score:3, Insightful)
I've been in the industry for over 20 years and I've never encountered a developer in all that time who hasn't "learned anything new in 20 years".
Re:Obivous Answer (Score:2, Insightful)
"I'd rather write half as much code, spend half as much time debugging it, and go home. "
Thats why I like Test Driven Development: when I'm writing unit cases, I'm doing test case design AND I'm coding. Then I also get to write the code that passes the tests. So I end up enjoying the testing part of the work a little more.
Re:Obivous Answer (Score:3, Insightful)
Actually, it wasn't hype. It was just that the important code was fixed well in advance of the cut-off date (believe it or not, an I/T project that met the timeline). I know of several Y2K issues that were fixed at two different companies (I changed jobs in August of 1999). The hype lead to focus which lead to the event being a non-issue. Same went for several other over-hyped events (swine flu, anyone?); raised awareness turns catastrophe into non-event.
Re:Obivous Answer (Score:5, Insightful)
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.
Completely true (Score:2, Insightful)
I'm nearing 60 and have a vast experience programming all kinds of stuff, especially control systems, including satellite and other very critical ones, and the only reason I can keep programming is because I know obscure proprietary systems like AMX, Crestron, Alcorn McBride and so on. I often get offered system administration and similar jobs but programming in C, Java and so on never, ever. And it's not money as I'm ready to program for 1000 euros a month, even less than younger people.
As someone else has already pointed out, the problem is top management that, at least here in Spain, are completely ignorant of technological issues and believe everything they see in crappy movies. They are not even capable of using Internet: they have a secretary to do this for them.
Anonymous Coward (Score:1, Insightful)
In my opinion, experience counts for more than anything else in software development. I am a 42 year old developer who has been programming profesionally since I was 18. I think it was at least 10 years before I would have called myself a true professional developer. Younger guys often have tremendous talent, but not the insight that the additional years add, not to mention the lessons learned. Almost all the newer platforms are simply iterations or maturations of existing development languages and platforms, having the experience lends itself to much quicker consumption of an environment and project.
Re:Yes and No (Score:4, Insightful)
Non-technical hiring mgrs?! *That's* your problem (Score:2, Insightful)
Look, anytime you have HR (or anyone non-technical) hiring programmers you're going to have trouble. A technical candidate's value can _only_ ever be accurately evaluated by a more-senior technical person. If you're hiring any other way you're just buying by the pound.
Frankly, any organization that delegates its technical hires to HR is effectively saying "we don't need high-quality programmers." In that case, hiring young, cheap workers is probably the right move. I don't see the problem here.
Re:Obivous Answer (Score:2, Insightful)
I was not saying that Unit Tests cover everything. I was just saying that doing them raises my enjoyment of testing... I still do other kinds of testing and so does the company's QA team.
Re:Not so simple (Score:2, Insightful)
Simpler than you think.
Those other older programmers who didn't get promoted to management are the biggest threat to the security of the ones who did.
It's much better for the new managers to have a slew of 20 somethings around who don't really know how the world works yet than a few older jockeys who could take his place fairly easily. The new managers damn well know the value of those other older programmers and that's why they get replaced.
It's very simple.
Poorly phrased summery. (Score:3, Insightful)
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... 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.
I think I just read the definition of age discrimination.
A better way to summarize the article would have been: "While some people may assume that the recession has provided a handy cover for age discrimination, a closer look suggests that IT managers use age discrimination with no excuses from the recession.
Re:Yes and No (Score:3, Insightful)
I'm talking about basic things like...
Design your code so it can be maintained.
Design your code for growth.
Design your code for debugging.
Design your code so you only write 20% as much code.
Code for risks first- do the easy stuff last.
Young pups seem to very quickly code things that do not scale, is hard to debug in production, and fails as soon as the number of transactions goes up by 20% from the specs. Which is what the old geezers did 20 years ago.
They are also murderous about writing huge amounts of unnecessary code because they have no design experience. Patterns and so on are helping them some by externalizing common programming experience and coding solutions but still... Indians were good back in 2002-2004 but lately they are doing the same things which means to me that we must be getting more college grads (and trade school grades) where as previously we were getting masters degree types with more experience.
Without guidance, a young person will write code which isn't documented... OR is overdocumented in areas you don't need it... or stupidly documented (' add 1 to the counter) with teeny variable names "tw = p1 + b" instead of "tableWindow = row 1 + offset" instead of "invoiceTableWindow = (startOfPeriod + weekOffset)"
They will write routines which are only used once. They will write code without optional transaction recording to log files so when someone says "why did this happen" your only answer is, "we don't know".
And worst, they'll write 80% of the project before finding out something is impossible or impractical.
The ideal matchup seems to be one senior person and two to four junior people. The senior person uses the juniors and code monkeys and enforces good standards and practices. High Productivity + High Quality. When we have contractors they do this-- but at a 20:1 ratio instead of a 2or4:1 ratio. The results are predictable.
Re:Yes and No (Score:4, Insightful)
Re:lot of 50-something developers in my company (Score:3, Insightful)
I'd say the only drawback is you dont see people putting in more than 50-hour weeks at the most.
IMO working more than 40 hours a week is brain-dead stupid, unless you love your work more than you love your life. Why in the HELL would anybody sacrifice any more of their precious time than they have to? Just a couple of decades ago if your job required more than 40 hours it was referred to as a sweatshop. A hundred years ago when it was easier to exploit the poor, twelve hour seven day workweeks were the norm.
Things are going backwards, and you dumb kids are helping it happen. STOP IT!!!
Re:Yes and No (Score:1, Insightful)
I don't agree with you.
Programming is much the same in most popular languages today. Sure the syntax migh be different and some new concepts might be used that weren't used before. Someone used to cobol might need to get up to speed with object oriented techniques before starting with java or .net. But the basic concepts of computer science apply just the same. Things like datastructures, access times in O notation, working with stacks and basic algorithms and all the other development processes alongside it will remain relevant no matter which language you use.
Mediocre programmers are good in one thing.
Good programmers are good in many things, and able to adapt to new things.
Re:Obivous Answer (Score:5, Insightful)
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.
Re:Obivous Answer (Score:3, Insightful)
While I generally agree with you, there have been times when I'm "In the Zone" coding wise, and just hate to leave something half done until the next day, because then I'll have to pick things up after a long break and try to remember all the details of what I was doing, etc.
Re:Obivous Answer (Score:3, Insightful)
Re:Yes and No (Score:4, Insightful)
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 more experienced programmer you won't have to work nights and weekends to complete the project. 30 years experience provides the foresight to avoid the development black holes that create the situations where you have to work nights and weekends to complete the project.
Re:Yes and No (Score:1, Insightful)
Repeat with me. Software development != Building development.
Re:Yes and No - Hell No! (Score:3, Insightful)
"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.
Barring the curly braces and common control structures, no, they are not. Not even freaking close to be alike by any stretch of the imagination. C very much alike to Java, C#, PHP? Perl? I mean, C???? Of these bunch, only Java and C# are mildly similar, and only superficially.
Once you know one learning the rest are easy.
The problem with that thinking is that you only think about trivial code examples of any of those languages. When you start using them for non-trivial tasks, you find that there are obscure semantic idiosyncrasies that either make or break you. There are APIs, infrastructures, architectural considerations and limitations that are unique to each and which is the meat of the knowledge required to actually program non-trivial systems.
This is not taking into account that in almost all non-trivial systems (specially in IT computing), you do not develop in one single language.
I do agree that learning (minimal learning of) a new language is easy but learning to program is hard.
I do not agree though, that the *rest* is easy. It is not. It takes months of immersion to get minimally proficient any each one of them.
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.
Exactly the point. You still have to learn how to program by using those libraries. And you can't effectively know how to use them if you haven't burn the midnight oil in school doing many of those libraries from scratch. Because each of those libraries, each of those data structures and algorithms have pros and cons, run-time penalties and characteristics that you need to be aware of, and doing them from scratch is the only way to truly understand them.
What experence teachs you is when you need to use a hash vs a btree.
I don't know about you, but I learned that on my first 2000-level CS class in college, before even entering a 3000-level class devoted exclusively on data structures and algorithms.
Work is not the place to learn the basics. Employers don't pay us to learn the basics while we program for them. Work is where you get your experience which should consist of team work, domain specific knowledge, working under prolonged schedules (as opposed to working on throw-away programs for every class assignment), working with source control on a true system, knowing how to go live with a product, etc, etc.
Either you weren't paying attention in school, or your education was atrocious. Experience *is categorically NOT* the place where you learn how and when to use basic and fundamental 2000-3000 level data structures.
Re:Obivous Answer (Score:4, Insightful)
Now we're back at the other extreme. Management has done a great job convincing the labor at all levels, skilled and unskilled, that they're your buddies.
If I ever worked at a job where the management weren't my buddies, I'd leave and go to some other company.
Without any protections against abuses, it becomes easy to demand extra unpaid work or toss people out when they've outlived their short-term usefulness.
And with protections, it becomes impossible to toss the useless dead-weight that holds you and your company back. Look at the quality of education in the US, if you would like a vivid example of how unions harm society.
The adversarial split between labor and management needs to make a comeback - maybe in a less overt form, but with enough teeth to make employee demands count for something.
In good companies, there's no adversarial split. Why would I want to work in an environment where I'm working *against* management instead of my management and I working *for* my customers?
If you *ask* (not demand, because you're not an asshole) something from your boss, and he doesn't provide it, then either suck it up or go to a company that will. It's not hard.
Call me mediocre, but I'd rather give up the potential for being a total rock star employee for a fixed-hour work week, a contract that eliminates the salary shell game seen in corporate jobs, guaranteed raises, work rules and stability.
Losing more money from union dues than I earn from raises, having political contributions made with my money against my will, having to deal with useless dead weight co-workers who can't be fired...
Yah, it's not all sunny. There's no way our company would have a well-stocked bar if it was unionized.
Despite my tone in this post, I'm not really anti-Union-- I'm anti-being-forced-into-a-union. If you want to start a IT union, fine. Knock yourself out. But if you want to *force* me to join it to retain my current job, then you can go screw yourself-- I can't think of anything more anti-American and yet culturally accepted in the US than forced unionization. Hell, it's why I went into IT in the first place instead of becoming a school teacher.
Re:Youthful arrogance.... (Score:3, Insightful)
For simple projects that's true - where the application itself is straightforward and you just need people conversant in the tools you need to use to build it. That's not why you hire highly experienced people. No technology really takes more that 5 years to thoroughly master (although some complex domains may do).
Where you DO need experienced people is where the application is significantly complex or critical, where what the experience buys you is expertise in software architecture, and design. There are many obvious high-profile jobs like this - compiler design, radar systems, speech recognition, etc, but also many much more mundane ones... complex multi-threaded realtime software at the core of communications systems, industrial control systems, etc.
For these types of projects what you really need is years of experience in designing big complex systems. Being a hotshot in C++ or Java or the technology du jour (however many/few years it took you to get there) doesn't help at all if the scope and complexity of the project is just way over your head. This doesn't just apply to massive software projects - there are plently of complex one-man projects where someone without significant design experience is going to be struggling, making mistakes, and making slow progress (and ending up with a bunch of unmaintainable code that reflects the struggles) as opposed to a more senior person who'll design it right and in a fraction of the time because the job was well below his experience level rather than above it.
Re:lot of 50-something developers in my company (Score:3, Insightful)
Totally agree. I don't know why people can't grasp the concept that no matter how much work you do today there will be more to do tomorrow.
I hear people all in a tizzy say, "I HAVE to get this done" and I just shake my head. Why? What will happen if you don't? A deadline will slip? They've been slipping for thousands of years. Yours slipping won't bring civilization crashing down. Use this crisis to learn to set realistic deadlines and manage expectations.
Now I'm not advocating being slack or lazy. Put in a full day's work. Work hard. Get things done. But GO HOME! If you can't set borders on your life and personal time, your employer will happily work you 80 hours per week - and you'll still have too much to do, just like when you were only working 50 hours a week.
I think some people just operate in perpetual crisis mode. There's something about the feeling of urgency and immediacy that drives and sustains them. Not me.
FWIW, I'm 41, been a programmer/"software engineer" for going on 20 years, have been at my current position at a large company for 10 years. All my customers praise my performance and results. I deliver solutions that work on time - with very rare extra hours.
I continue to enjoy the software development process: study problem, select solution platform, implement. I'm mostly a Java hack (learned Pascal & C in school), am picking up Groovy & Grails, do a fair bit of XSLT, and am getting more versed in "semantic web" technologies (RDF, OWL, Sesame). Being a coder does mean constant learning, but I'm finding the things I'm learning these days are "higher up the stack" than earlier in my career.
As others have pointed out, the young bucks tend to have fewer obligations outside work (read family), and are more eager to make a name for themselves impressing management. I don't know that there's a way to solve that. I enjoy my job, but it is a job; I have other things to do with my life. If management chooses to discard the institutional knowledge and experience I have, that's their choice.
That was a long rambling response, but it is a subject I am definitely familiar with and interested in.
- Jasen.