Software Ageism
Software AgeismMaybe it works both ways: business managers can discriminate against the young but one of the biggest concerns I have had for some time about software is the ruthless discarding of the old.
Funny how it started to matter when I turned forty. No, in fact that's not true, I've always been a "young fogey" in attitude I guess. I believe there are many great things to learn from those with years of experience at various levels, from software management right up to coding. It doesn't matter whether the code was assembler or the earliest hand assembled machine code if KentBeck and TimBernersLee are anything to go by (see SecondGenerationProgrammer).
HistoryRepeatsItself more often than necessary in this business, in my short experience. But there are some obstacles in overcoming SoftwareAgeism. Any ideas?
All contributors to this page must record their age. (Only partly joking.)
-- Blissex (46)
My impression is that there is little SoftwareAgeism; then how comes that older programmers find it so hard to get jobs?
Well, what I see in the industry is that there is discrimination, but not based on age as such, but against skills and experience, which often correlate with age. It is not even discrimination against salary expectations, because older or experienced/skilled candidates get rejected even if they apply for low paying positions.
What is happening is in part that the career structure at most tech companies is ostensibly based on merit, or more usually skills and experience, but is in practice based on employee number with only some regard paid to skills and experience.
The only way to satisfy both constraints is to avoid hiring people with greater skills than any existing employees. In other words, only hire beginners.
Hiring an experienced and skilled older employer might eventually result in either flaunting the ostensible policy of promotion on merit, or in promoting recently hired people ahead of people with greater seniority of service. Both things may and do happen, but in general are regarded as very grave political mistakes, especially in rapidly growing companies.
Also, many hiring decisions are delegated to the team leader/team level. Often team leaders' main asset and claim to promotion is seniority of service, so they may be extremely reluctant to hire someone who may come ahead of them on skills and experience. The same goes for other team members. This often leads to team leaders and teams to hire the least qualified candidate they can find when the team expands.
People who switch to programming as a career late in their life find it much easier to find employment than programmers of the same age with a longer experience and greater skills, even if the salary expectations are the same.
Obviously more experienced and skilled employees may be more valuable to the company and to project success than less skilled and experienced ones. However often this does not matter much because:
If these older time serving PHBs need, exceptionally, people with greater skills and experience than the bulk headcount they have hired, they turn to contractors, which by definition are not part of and don't threaten their career path.
-- RichardDrake (42)
Gee, why am I suddenly reluctant to post on this page? -- anon (103?)
Clueless managers who expect programmers to "give their all". When the plan fails or something unexpected comes up, programmers find themselves in the bind of being a "team player" vs "having a life" - older programmers have the experience to know which is the more valuable ("having a life"), and the clueless managers brand them as having a "bad attitude".
-- Blissex (46)
As to Clueless managers expect programmers to "give their all". When the plan fails I see a different logic: most projects are destined for failure or cancellation, and this is usually fairly clear from the beginning.
In such a case an astute (far from clueless) PointyHairedBoss will make sure the team is pressured to work as hard as possible, even if it is quite clear that this will not save the project. The reason is that when the end comes the PHB (and his minions too) will be able to use this excuse: I made them work as hard as possible, so it is not for want of trying, which works well in fair organizations that value effort and hard work as well or more than results.
Otherwise someone will blame the failure on the manager and the team: if only you had worked harder, which can only be defended against by working as hard as possible. Because if you work 8 hour days harder becomes 10 hour, and if you work 10 hour days harder becomes 12 hours, and so on...
The impact of tiredness and low morale on actual work done is irrelevant in these common cases, because these are hard to prove qualitative issues; hours worked is an easily proved fact, for or against.
In such cases if older or more experiences workers refuse to work long hours, for various reasons, they are committing a very grave crime in the eyes of their manager: they are depriving the manager of what is often a career-saving excuse.
I can understand that some older PointyHairedBosses might want younger workers that might be easier to pressure into providing that excuse, turning the project into a DeathMarch.
-- RobCrawford (29)
No manager can make me more stressed, or cause me to work more hours, than I choose. Especially in this job market. Ask me again when the market changes.
-- WayneConrad (38)
mARKET HAS cHANGED! nOW, WHAT, wAYNE?
This page is a result of my comments on EdYourdon and Richard's response: "It really concerns me the general disdain for 'old troopers,' whether rich and famous like Ed or not, that seems to prevail in so many software circles. In other words SoftwareAgeism."
For me, it's not the ageism. I feel that people get better and more experienced with age! (I hope!) They are able to see more of the big picture. I'm all for "older" developers. My problem with EdYourdon is that I've been too busy working with the latest Microsoft service packs for the last fifteen years or so and admit I've lost touch with the old "dinosaur".
-- RespectedOldMan? (78)
So you haven't read anything that Ed Yourdon has written over the last 15 years? In particular the Coad-Yourdon OOA&D book, one of the first on the market (c1991), and one that recommended - perish the thought - CRC cards. Or "DeclineAndFallOfTheAmericanProgrammer" (~1995) where he recommended that people needed to get with the program and learn OO and components? Ed's a forward-looking kind of guy - if he's a dinosaur, he's one that's evolved into a bird and survived...
-- KyleBrown (33)
I have my doubts. See CoadAndYourdon -- KeithBraithwaite (28)
Really? thought you were older (a compliment I think).
Yes, really, the beard makes me look older, and: thanks, I'll take it as one.
Thanks Kyle, I admit that at the time I didn't think the CoadAndYourdon efforts were that significant but then I didn't remember them recommending IndexCards. But there's a number of things I do really respect about Ed and one of them I guess is that he seems to grow old more gracefully than so many folk in software, being both open to the new and honoring the old where appropriate. His comments on his web site on the anniversary edition of MythicalManMonth by FredBrooks really moved me. Maybe that just shows what a strange guy I am...
-- RichardDrake (still 42)
It's interesting reading this page, and probably out of order making a contribution, being the young interloper :-). I've followed the Wiki now for about 18 months, and have been inspired by it's content. I find myself suffering from ageism of sorts, brimming with ideas and wanting to try them out, a CV full of these new technologies. The one thing against me with my current employer is my age, project offers come in then suddenly, "not enough experience, sorry". It's driven me to the point of looking elsewhere for more dynamic environments, where I don't feel so restrained. I suppose it'll all open up as I get older (and wiser!):-)
-- StuartBarker (25 almost 26!)
Apparently, console games shops sometimes combine young games fanatics, for the contents, with boring oldies, who have the mathematics and are used to squeezing cycles out of small machines.
Sounds interesting. Can I be one of the boring oldies? -- AlastairBridgewater (20)
What bothers me most about SoftwareAgeism is that I *know* there are people out there that are older and wiser than I, and I just can't convince management to hire them, primarily because of the high salaries of the "expert contractor". SurvivingGuruStatus when you're young & have no one experienced to talk to is an exercise in frustration. -- StuCharlton (22)
This is very common. Thanks for pointing to SurvivingGuruStatus, another page showing the healthy WikiBias? against both ageism and premature guru - one of Wiki's strengths in my (one remaining) book. We seem to agree that SoftwareAgeism is a problem. So WhatCausesSoftwareAgeism -- rd
I've encountered heavy age discrimination on a recent project: The early 20-something?s aggressively categorizing the high-30s and 40-or-so's as "over the hill legacy programmers" with nothing to contribute to their "leading edge high technology rewrite of the system." So they exclude the older developers from design discussions.
Now, they have a real point that some (less than half!) of the older team members really are "LegacyDevelopers?" - concrete thinkers (having a very difficult time with abstraction), slow to learn, and really not very skilled with the tools or techniques they're using. But I see that the inexperience of the young punks is far more dangerous to the success of the project: They have no idea how much risk they're taking on, nor any idea of how long it will take to write that much code.
It's my opinion that every member of the team has valuable contributions to make: The interns and recent graduates come in with fresh ideas, and often know more about the latest academic research done in the universities. The older developers bring their valuable experience to the table, along with a generally more realistic view of how long things will take, and what political pitfalls are likely. Also, because such a breadth and depth of knowledge is needed to be successful in our industry, I've found that no one person could possibly know it all. Whenever I pair with another developer, I learn - and it doesn't matter if they're more or less experienced than I. -- JeffGrigg (37; programming for 24 years: 5 in school, 19 for pay)
SoftwareAgeism isn't a new phenomenon. It is just part of the old burn em up and throw em out mind-set of some management. Some companies adopt this as a principle, others have the stack the deadwood in the corner syndrome. The bottom line is good is good no matter how old you are. The other bottom line is what Deming said - It's all process - so both ideas are really bad - both burn-em up and stack-em up. XP is a process change that calls into question the traditional ways we are doing things. We need more such thinking. Ageism, software or other, is simply a component of our narcissistic society that somehow thinks that youth conveys wisdom - a rather dumb idea in any age. -- RaySchneider (57)
It's not wisdom that society thinks that youth has. It's enthusiasm, an enthusiasm unbridled by experience of past disasters, unrestrained by wisdom, free of deep critical thinking. Young programmers won't stand up to management and say, "That is perhaps the stupidest idea I've heard this month." They say, "Yessir!" and willingly spend 60 hours a week working on something which was doomed from the outset. And when the project inevitably implodes, they work even longer hours to try to repair it. -- Doug (49)
I'd have to disagree with Doug on this. Enthusiasm is certainly not a particular attribute of the young. Perhaps energy or unbridled willingness to run into brick walls, not yet knowing that the wall is brick - but not enthusiasm. Enthusiasm to me is a kind of infectious support for an idea or project, that spreads. It is often a component of leadership and a positive attitude since I think enthusiasm is almost always optimistic and pro-active. Perhaps what youth brings as rd points out below, is a certain naivete - not having the experience to be wary. I've worked in R and D for 30 some years and one of the things I bring to the table is enthusiasm. -- RaySchneider (57)
I did not mean to imply that us old folks cannot be enthusiastic, given something worthy of being enthusiastic about, but rather that we will stand up and object when a terrible mistake is about to be made. -- Doug
Let's not forget one of the most important things about young people is that they don't know what's impossible ... so sometimes they prove that it isn't. -- rd
The story Musashi is interesting from this perspective. The young samurai had no concept of experts getting older, seemingly thinking that if you're good you're good at any age, and would happily challenge a 70-year-old master to a duel. The old master often would lose and then go off to a monastery.
That is a different form of "youth"-centric society. In our current culture (as evidenced on wiki) it takes the form of JustaProgrammer, a reverse self-condescension that becomes a machismo badge. I have my doubts that a 40- or 50-year old programmer can contribute double or triple what a 25- or 35-year old can. But that's what their salary would require. Between that and the next point, I think that drives most of them out of programming. It certainly is driving me out.
Also, I find that older people are fed up with learning every new technology that comes along (and doesn't really simplify life, just changes it). Back in 1975 a middle-aged codger told me, "I just picked the right language (APL) to start with, and I'll wait for you C.S. guys to stop changing your minds, and catch up." I hit that point after I learned my 8th operating system, and ran into Smalltalk. LifesJustTooShort. -- AlistairCockburn (46)
If I may politely ask, Alistair, to what are you being driven towards, if away from programming? (Hint: I'm looking to compare notes with a kindred spirit) -- AnthonyLander (body: 30 attitude:15 crotchetiness: 65)
I'll answer that question on my name page, and it you want to extend it, copy over to a new page of your choice and extend away. -- AlistairCockburn
Alistair is right on here! I started out with Fortran, learned BASIC, then Pascal, then C, then dabbled in Smalltalk and Lisp, Matlab and more recently Perl and Python. I taught a Programming Languages course two semesters ago and touched on about 70 languages and gave assignments in about 15 - there was a document I used to give some perspective to the course that had over 2000 languages for which compilers had been written. Is something wrong here? -- RaySchneider (57)
Well, I think something is wrong somewhere in the vicinity! I would agree with FredBrooks in his keynote for HistoryOfProgrammingLanguagesTwo that new language design remains important, for various reasons, but also that the real world benefit of adopting a new language is likely to be increasingly marginal. The pace of change in language should therefore reduce at some point - though the changes in libraries and environments will presumably take longer to slow down. But this of course will help with the unproductive side of SoftwareAgeism, when everyone realizes Smalltalk is best (oops sorry ... let it slip). -- Richard
1. I try to concentrate on the logical problems, not on the technical. As an example : Componentware is a huge challenge nowadays. Identify the components of a domain, inventing 'glue' languages etc. This kind of problems tends to make you wiser and train your intuition. Learning the 5th language and the 8th OS maybe looks better on your CV :-)
2. Of course can good developers (young or old doesn't matter ) be 10 times more efficient. No Question. Sometimes the factor is infinite, when the rookie get lost in complexity. -- ManfredSchaefer (30)
I don't really think that changes in technology are the underlying cause here. I've found that over time new technologies have gotten easier to learn because I have more mental references. And while we put way too much emphasis on technologies in the hiring process, I would much rather have someone good than someone average who has a certificate in the language du jour.
In this industry, experience does not necessarily lead to increased productivity. Many over-40 programmers are not more productive than 28-30 year-old programmers. Perhaps it is the nature of the problem. Perhaps people have a certain innate level of complexity or difficulty they can deal with. It is certainly my experience that I'd rather have a great 26 year-old programmer than an average programmer of any age. And most people reach their level before they are out of their 20s. Unfortunately, the salary structure doesn't recognize that so programmers eventually price their way out of the market.
Of course, as an industry, we do a particularly poor job developing our people. Maybe the level is not innate. Maybe we can teach people to solve more difficult and complex problems. But we don't. Sure, we have courses in the latest languages and technologies. But these are the easiest things the learn and have the least actual value. This was, imho, the greatest promise of the patterns movement - developing real programming ability. Still, there's no time on the job to learn this stuff. So it's available only to those who love it enough to make it their life - not to those who most need it. -- HowardFear (40)
I believe that the salary structures have to change too though - for example for excellent and experienced programmers to be paid as much if not more than managers with less business value to offer - if the SoftwareRenaissance is finally to take place. CollectiveCodeOwnership can't imply the economics of the communist collective. -- rd
This page is just like the 24 bus from Hampstead - you wait days for someone older than you to contribute to SoftwareAgeism and then lots of them come along together! Thanks for these honest, mature reflections. Where would Wiki have been without the wisdom of those of around 46? (mentioning no names of course). -- rd
A different spin: Job Unready Graduates. One of the problems we see in Australia is that many university graduates are not fit for commercial programming.
I believe it will be the same in the US, and in many other countries including India.
Unfortunately, when there are so many bad graduates around, the good graduates suffer, too.
-- NickBishop (34, 3.5 years C++)
Indeed, I would say that the quality of graduate software engineers has been steadily dropping, thanks in the main (IMO) to the predominance of visual basic style programming (i.e., write the GUI first then write routines for each button-press).
In terms of sheer physical labour, the young and inexperienced can 'produce' as much as more experienced engineers. But to me this is like driving a car at top speed in the wrong direction. I'd rather have one car going slowly but the right way than any number going at speed the wrong way. I was no exception when I was younger: full of energy and raring to go before I'd thought through the wisdom of what I was doing.
To avoid lots of wasted energy, I think the only place you should put young engineers is with older engineers to mentor them. The more experienced engineers are also the only ones who really understand the value of quality and are hence the right people to enforce it in projects / products. -- RichardDevelyn (36)
I think part of the problem is that somehow people think of programming as a sort of a sport, where you need to be young to be great. I like to compare programming to PlayingJazz. In general jazz musicians get better with age, as they learn more of what is important.
Of course, often a young gun comes along who can play real well technically, but still his playing, although impressive at the time, has no lasting power.
In the long run, it is the older guys - Louis Armstrong, Duke Ellington, Miles Davis - that really change the world.
I think the same is true of programmers. -- RichieBielak (44)
How much do younger programmers critically examine their discipline? Part of truth of the PlayingJazz analogy may lie in the fact that it often takes a fair amount of exposure to the subject before you can question its underpinnings and move to the "meta" level. Most of my co-workers really don't think about things that way. They come in and write code their way. A question for those who feel comfortable answering: at what point did you begin reading about software development? Books like MythicalManMonth, PeopleWare, DesignPatternsBook, StructuredDesign?, etc. What caused you to do so at that time. I'm curious as whether these interests are developed after some amount of experience, or if these interests are always there. -- PaulTevis (23)
For me, my major frustration was not being listened to, probably because I started out very vocal and stubborn-like. I used the study of software development as a way to try to gain respect (and also as self-training since I wasn't getting any at my job). Well, that didn't work - it takes more than knowledge to be respected. But then I realized, "Hey, after all this reading and studying (I've learned more in the past two years than I did at University), I really do have a good grasp of what software development is all about." After trying out the theory on real projects and seeing it work, I was hooked! Now I don't study it to gain respect, I study it because I value the lessons I learn from it. And now that I'm starting my own business, I study it because it will make me lots of money (well, hopefully anyway :-). Oh, and by the way, I did start gaining respect, but it was from learning about people, not software (a certain book by DaleCarnegie changed my whole attitude). -- RobHarwood (25; just)
Sometimes I think I practise software ageism on myself - I might have an idea for how to do/change/improve something, but if one of the more experienced developers suggests something else, then I will go along with it because I think "they've been here so much longer than me, they know so much more stuff, they are bound to be right". So often I don't give my own ideas the benefit of the doubt. Although the majority of my ideas might turn out to be no-hopers, at least through exploring them and finding out why they would not work, I would learn more. JoGay (24)
For the past five years or so, I've had the pleasure of working with a woman who has been in the computing and consulting businesses for nearly thirty years. I've learned more about transaction systems, virtual memory systems, software architecture and, most importantly, effective development techniques and how to interact with clients than I ever could have by joining my age cohorts coding EnterpriseJavaBeans (HistoryRepeatsItself). In a recent interview, I was asked to name an important technology. I said CiCs and went on to explain how it was pretty much the root of everything that we do now (certainly from a web perspective). I should have realized that that didn't really score me any points with people who grew up thinking applets are cool and WebLogic is the source of all that is good and true. -- MarkAddleman (30)
I'm certain that SoftwareAgeism and TechnologyChurn feed off each other. Employers feel they must have the latest "technologies" (how I hate the abuse of that word), and that inclines them to hire the younger programmers. In turn, the younger programmers may be more enamoured of the newer versions of database engines, network protocols, and programming languages, even though their feature sets frequently amount to nothing more than old wine in new bottles. Hardly ever is the new stuff so much better than the old that you can't easily afford to skip a "generation" at the very minimum, but noooooOOOOooo the bosses need extensive experience with the latest point-release! Bah. -- MarkSchumann (34, whoa, now 40)
Younger programmers are simply better able to show more enthusiasm for bullshit because they don't yet recognize the smell.
Interesting, in this era of multiple serial careers, that you all assume that an older software developer is going to have more experience. I'm 39, and have worked in IT for 2 years, 1.5 of which were spent in the wastelands of tech support. I'm less experienced than my 19-34 yr old peers. As far as I can see there's no difference between us that experience plus the usual human variation in faculties cannot explain. Generalizations about what aged persons you would rather work with seem pointless in my context.
But you do know the converse: that there's a hard upper limit on the younger developer's experience. -- MarkSchumann
I think the reason why employers prefer younger ones is that younger programmers might:
I've been developing Java software for three years after nearly 20 years as an opera conductor and pianist. I'm the oldest developer in my company (though most are over 30), and yet I have fewer sick days than most of the others. I often wish I had the formal foundation of my colleagues who studied CS (though I'm picking up as much as possible on my own), yet I don't regret the career path I've taken. I think my employers value the experience that often comes with age; I'm pretty sure I can write Java code as well as most anyone else of any age who's been coding for three years. I'm acutely aware that I might have severe difficulties getting a new job at my age, should I be compelled to switch, and I also wonder a bit what I'll be doing in ten years. In Germany, you see a lot of ads that explicitly are looking for developers (or other professions) "up to age 35" - that's legal in this country. -- JohnWebber (45)
"Yes it's true in Germany" - most big (and even small) companies stop hiring people over 35. -- AndreasSchweikardt (38) from Germany
I just completed a contract engagement with a company where the average age of the programmers was around my age (maybe even a little higher). It was quite refreshing to work with people who know what they're doing, who understand what I'm talking about when I make suggestions, and who don't spend all their time arguing about irrelevancies. -- KrisJohnson (35)
I started coding when I was really young (5) and went professional (read: got paid) at age nine. I often think back on my teenage years and the sheer volume of code I could produce was staggering. Still, this year has been exceptional for me in terms of my productivity (around 120KLOC) mostly in Java, C#, and VB.NET. I've learned so much since those nascent years of my programming career that I'm really a totally different "programmer person" than I was then. I believe I'll continue to improve and hope I can program for the rest of my life in some form or another. -- JeffPanici (was 28 when I wrote this, now 31. Geez, where does the time go?)
Good point. I learned programming in 1971 (just type and debug). I relearned programming from Michael Jackson, David Gries and Edsgar Dijkstra books (program derivation) in 1984. I rerelearned programming from Kent Beck and Ward Cunningham and that crowd (CRC cards) in 1992. I rererelearned programming again from Kent Beck and the XP crowd (TDD) in 2002. My current view is that anyone who hasn't re(re)learned programming in the last 5 years is waaayyyy out of date. From the above trend, I expect to rerererelearn programming (from Kent Beck again?) around 2010 or 2012. (p.s the languages are getting suckier, but the development techniques are getting better) -- AlistairCockburn (formerly 46, currently 50)
Interesting. I must say that's a different take on it then I thought. At least for me, I wouldn't consider myself as a productive a programmer as a lot of people - I spend my time learning about new concepts and thinking about design of a program a lot more before working on it... and I seem to be doing more of this as I get older rather then less. Generally, as Alistair noted, a lot of it is spent relearning a lot of things. In the long run I think its helped me out quite a bit. When I was younger and developing I would have to work my code a lot just for it to pass the compiler's checks, and often had to rewrite things. Now a lot of times I can write a bunch of code and sometimes I won't even need to touch it - it will just be done right then and there. To tell you the truth I don't know which type of programmer is "better", maybe its just that they are better suited for different things. -- RyanNorton (22)
I can relate but with a twist - I started coding at 16 (in 1981) and spent several years in LarvalStage? - but didn't go into IT until I was 32. While I continued to write programs during that interval - I was working in other areas. Initially I learned by trial and error and was prodigious - but then I started getting more interested in how to do it right - and that lead me to self study and eventually to the university. At the university I was able to focus more energy beyond the homework and studies [since I already grasped the basics] to grasp concepts that were there to be had - that most of my peers were too busy trying to pass to see. When I entered the job market - I was able to outperform my peers because while they were still building up the patterns and pointers in their heads - I had all of that down and could generate solutions fast; I could see the forest instead of worrying about individual trees. So today - I've been writing code for 31 years - and while I don't write as much code as I used to - the code that I do write does more and is way better that when I started - and my experience has been that it only continues to improve (I seriously don't understand the experience of some that say they level off - I'm constantly learning new things). I've managed to survive two periods of IT outsourcing over the years. Early on I determined that a proper measure of programmer productivity was never lines of code - it was correctly working systems; I also determined never to be JustaProgrammer, and like Bruce Lee - I was constantly evaluating what tools I needed to accomplish that - discarding what didn't work. Being able to deliver consistently and quickly never gets old. Today I've moved into an architect position, but I already know that if worse comes to worse and I have to move back into doing development, I'll have many options (starting my own contracting service, working for a contractor, working for other groups within my current company that have expressed interest in my skills etc). The key I think is staying young at heart (and FPS and MMO games keep your brain sharp - FYI) -- MalcolmCampbell (48) [2012]
New code languages create more money for businesses. If there was only one language... and it did everything that everyone wanted (maybe opensource or GNU?), then there would be less to sell. If there was no Java, for example, then Sun would have to be under the control of some other language. If they create their own language, they make tons of money. But it also causes confusion. If there are too many languages, doesn't that just make everything more confusing? Standards usually HELP things... for example, HTML. I think the basis of most languages is EGO. No one wants to work together, everyone wants to create their own. Even the opensource/GNU stuff is based on EGO sometimes, because wouldn't it be great if you could invent a new language. You could just help some people out with an existing language, but that would be like living in a house with everyone else and not buying your own. When does the EGO take play?
I think in an ultimate world, you'd just have one main language with a bunch of sublanguages. We tried that: it was called PL-1. Example: visual basic is just C++. So you could have several different tools that were based on one big complex language, and several different sublanguages. But there has to be some standard. Where there is no standard, there is EGO. HTML is a standard, why don't we have 5 different types of HTML type languages for browsers?
It's not just ego, it's money. It's difficult to get customers to cough over $200 for version 35.0 when version 34.0 already is bloated with features. You have to present something as new and improved in order to charge lots. It's like the split-ends (hair) TV commercials. People never noticed split-ends until TV ads made a big deal about them. Take a small problem, make a tool that "fixes" it, and blow the importance of the problem out of proportion. When that dies down, find another problem, and do it all over again.
Why are you getting hung up on language libraries? If you really examine all the TuringComplete languages - you'll see a core of functionality that is consistent from one to the other (all variations in syntax aside). For the most part, the various libraries build upon that same primary functionality. To learn a new language focus on those core items exclusively until you master them. If you have a very consistent set of rules in your head about how to combine those things in useful ways (which you should if you've been programming for any significant length of time) then you'll be productive faster. At that point you can recreate your own libraries for extended functionality very easily without having to go down a RatHole? to learn what a particular vendor decides the 'right interface' is for similar/same functionality, if you so desire. On the whole this allows you to be very efficient, and as an added bonus - your code is likely to be far more portable than code that hinges upon language libraries who's interfaces may morph from one release to the next or are broken in subtle ways. From an ecosystem perspective - having only ONE invariant thing is dangerous for various reasons, and assumes that you have fully defined everything up front correctly; without the option to move and improve - progress will cease.
I thought SoftwareAgeism was going to be a rant against the pervasive bias against old (or young) software. -- TomStambaugh (51 in March of 2004)
People go softer with age, mellowing? And they wear out. So people are software too.
-- DavidLiu (just TooOld to remember)
Software doesn't wear out. It gets rewritten. This is progress.
What is interesting is that we tend to do the same thing over and over again. We built ASCII card systems to pump formatted data in and out. Then we used green screens to pump field data in and out. Then we built colorful windowing systems to pump data in and out. Then we built client front ends to pump data in and out. Then we built HTML browsers to pump data in and out. Now we build XML web services to pump data in and out. And now I learn about aspect-oriented programming that says we still have boilerplate for logging, exceptions, and management. Reminds me of building COBOL systems?
People don't wear out. They get older. And supposedly wiser. Just not rewritten.
-- WilliamMiles (52)
External Links
Article: "Too old for dot-coms" http://www.sjmercury.com/svtech/news/viewpoints/docs/047732.htm [link broke?]
http://techcrunch.com/2010/08/28/silicon-valley%E2%80%99s-dark-secret-it%E2%80%99s-all-about-age/
A chart from above link:
See also: MindOverhaulEconomics, AbleBodiedTwentyFiveYearOldMaleAssumption, WhatCausesSoftwareAgeism
EditText of this page
(last edited July 14, 2012)
or FindPage with title or text search