I am a software engineer, database developer, web developer, social media user, programming geek, avid reader, sports fan, data geek, and statistics geek. I do not care if something is new and shiny. I want to know if it works, if it is better than what I use now, and whether it makes my job or my life easier. I am also the author of RegularGeek.com and Founder of YackTrack.com, a social media monitoring and tracking tool. Robert is a DZone MVB and is not an employee of DZone and has posted 108 posts at DZone. You can read more from them at their website. View Full User Profile

Can You Be Too Old For Software Development?

  • submit to reddit

It has been a while since a good bitchmeme came about, so it is with great pleasure that I participate in this one. Actually, is it not with great pleasure as the issue hits close to home. The issue at hand is regarding age in the software development profession. This is important to me because I am 38 years old and have been in software development for about 16 years. Some people are saying that Silicon Valley has a bias towards younger people. TechCrunch has an interesting article that makes some very good points:

The harsh reality is that in the tech world, companies prefer to hire young, inexperienced, engineers. And engineering is an “up or out” profession: you either move up the ladder or face unemployment. This is not something that tech executives publicly admit, because they fear being sued for age discrimination, but everyone knows that this is the way things are. Why would any company hire a computer programmer with the wrong skills for a salary of $150,000, when it can hire a fresh graduate—with no skills—for around $60,000?  Even if it spends a month training the younger worker, the company is still far ahead. The young understand new technologies better than the old do, and are like a clean slate: they will rapidly learn the latest coding methods and techniques, and they don’t carry any “technology baggage”.  As well, the older worker likely has a family and needs to leave by 6 pm, whereas the young can pull all-nighters.

Initially, I was going to leave this topic alone, but Dave Winer decided to complain as well:

If I can’t get into the game, I can’t imagine there’s much chance for most other people in their 50′s to play a role. Which is really fucked up. It’s probably the reason why we keep going around in the same loops over and over, because we chuck our experience, wholesale, every ten years or so.

The combination of the two struck a nerve. I only partially agree with either quote as they do not look at the real issues here. In particular, both posts talk about ages and startups. Startups are not a huge portion of the software development industry. They may be the beginnings of it, but there are tons of engineers slaving away in a cube for some corporation that has 50,000 employees. However, even in a large corporation, age can be an issue for a few reasons.

Age and Hours Worked

For startups, hours worked are extremely important. Sometimes developers will work 80 hour weeks for months in order to get the product shipped. Many people assume that this is a young person’s game. This is technically true, but not because the people are young. The main reason that older people cannot work long hours is because they typically have a family and kids at home. They may not want to work long hours because they want to see their children at night. Some of these family people will work long hours after their children go back to sleep, but this is not the majority of software developers. If your company requires long hours, and you do not want to work those hours, age is not the issue, the hours are the issue. Maybe you are just not cut out for the startup life.

Age and Cost

For a startup, cost can be a significant issue. Many veteran (10+ years) software developers will have a salary in the top 25% of the industry. This problem is also not specific to the startup world, though startups do feel the cost pinch sooner than a large corporation. Startups have a tendency to pay for significant benefits to offset a lower salary. Sometimes you can get stock options or maybe it is just free food. In either case, your startup salary is likely lower than your salary at an equivalent corporate job. The corporation will eventually cap the experienced developer’s salary as well. Experience is important, but sometimes people just become too expensive. If you are that person, you must realize that you will not always get a raise when you change jobs or get more experience. If you decide to stay in software development, you have decided to make some maximum dollar amount in your city. If you want more money, you need to get into management.

Age and Skills

The TechCrunch post states that “The young understand new technologies better than the old do, and are like a clean slate”. Dave Winer feels that we make the same mistakes over again because we are throwing away or ignoring experience by only hiring younger developers. The truth is somewhere in between. Experience is somewhat helpful when a product is first being developed, but that is not critical at the early stage. Experience is critical when the early startup gains more adoption and needs to become stable. Younger developers do not have the experience to stabilize a product, whether it is by scaling a product for millions of users or just dealing with all of the issues that software has after being used for some time. These skills come with experience. Younger developers can learn these skills, but typically the knowledge is passed on from someone with experience.

Older developers have always had the stigma of staleness attached to them as well. I think this stems from the long tenure at large corporations. The internet changed a lot of that as well. Now, older developers are starting companies of their own. Technology is significantly easier to learn today because of the wealth of information available. 15 years ago, your ability to learn a new technology depended upon how many books you could read and whether your company would send you to training. This would become very expensive, potentially over $5000 per year. Now, I can find better information, quick than before and it is free.

Age Is Just A Number

In reality, age is just a number. There are plenty of younger developers that have no interest in working at a startup, just like those family-oriented older developers. Older developers can learn new technologies without being hampered by whatever “technology baggage” they carry. They just need to decide to do so. There are some younger developers that learned Java in school and have no interest in learning anything else because it is stable and used at many large corporations. There are people of all ages that refuse to work for less than they feel they are worth. Some of these people are misguided, and others may be worth the money. In all of these cases, developers young and old may not be a fit for a startup. To be a fit for a startup, you must have the desire to be in a startup. If that means working long hours at a lower salary while learning all sorts of new technology, then you must be prepared.

Preparation and desire are not age related.


From http://regulargeek.com/2010/08/29/can-you-be-too-old-for-software-development/

Published at DZone with permission of Robert Diana, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)



Alessandro Santini replied on Mon, 2010/08/30 - 5:20am

Robert, I have reached a point in my career where I rather wonder if it is of any value to be a software engineer today. Leaving aside the romantic facet of this job for a moment, it is quickly becoming very comparable to factory jobs: always in the competition of cheaper salaries, of younger, inexperienced colleagues and with salaries that nowadays have been exceeded by many other jobs.

I tend to agree that age is playing an important role and that experienced IT engineers do not have the same speed, productivity and - sometimes - the same attitude to think out-of-the-box.

John J. Franey replied on Mon, 2010/08/30 - 6:04am

The techcrunch article looks at the practices of start-ups and attempts to generalize those across the entire industry, and so do you. bah!. Because start-ups can only offer pizza and a dream, the 'skilled' are not interested, and the start-ups have to take the 'un skilled'. Working for a start-up is like playing the lottery, there is little chance for success or any kind of stability.

Robert Diana replied on Mon, 2010/08/30 - 7:05am in response to: Alessandro Santini

Alessandro Software development requires you to learn continuously, so you are mostly forced to learn new things. The competition of cheaper salaries and other things is something that stems from the bias in the TechCrunch post. A lot of companies feel that way, and if you really like the company you may need to change some things. Other times, the company is the problem and you can move to a better position somewhere else. Software development is not the only industry that has this problem, but it does seem it bit more magnified there.

Robert Diana replied on Mon, 2010/08/30 - 7:13am in response to: John J. Franey

John, I tried not to generalize the startup culture to everything else, but there are some similar issues in large corporations as well. I apologize if that was not conveyed clearly enough. However, in this economy, stability in a larger corporation just does not exist. Too many companies are cutting people in order to save money in the short term. Even some tech companies that people thought would never have problems, IBM, Microsoft and Google, had rounds of layoffs recently. Also, plenty of startups are hiring "skilled" workers, and plenty of corporations have "unskilled" workers. That is a similar generalization to the ones you complain about.

Tim Boudreau replied on Mon, 2010/08/30 - 8:30am

When I interview a programmer, I am really trying to get the answer to a few questions: When they write code, do they actually understand what they are asking the computer to physically do? When they look at code, can they "run it in their head"? How many moving parts of a system can this person hold in their head at the same time, and how do they use abstraction as a tool to help themselves do that? These are skills which have very little to do with age. I have a few problems with that article. First, Silicon Valley startups are not "the tech industry," they are a small part of it; generally a startup's goal is either to get big really fast, or to get bought. For better or worse, you don't need good technology to get bought. You probably do, and hopefully you know it, to get big. Without splitting out the hiring practices by what the exit strategy of the startup is, I doubt anything terribly meaningful can be said about it. Second, the talk about hiring being a choice between "the wrong skills" and "no skills" is a false choice - someone who knows a few programming languages and technologies will pick up new ones far more quickly and use them skillfully faster. Those "wrong" skills say a lot about someone's ability to...acquire skills. Third, the "up the ladder" bit seems like a non-engineer's view of engineering. If you enjoy coding, you will probably be good at it, in which case there are opportunities in any economy because at worst you can always make your own. This article is really about the hiring strategies of a particular subset of the technology industry that the press considers glamorous; and it seems to take the perspective that hiring engineers is comparable to hiring cooks at McDonald's. Much as some would like to imagine a world where it is that way, it isn't.

Osvaldo Doederlein replied on Mon, 2010/08/30 - 8:48am

I'm always puzzled about the part of "young enginer working 80h/week". How exactly this is cost-effective? If my boss requires working at night or weekends, I will do it but I'll be paid 50% to 100% extra depending on how bad are the working hours. So, a full-month 80h/week would cost my employer significantly more than hiring a second engineer with the same hourly rate, even after writing off overheads like labor taxes and hiring work.

These tales of excessive late-night work also smell to pure management incompetence. It's OK to have a crisis a few times per year - i.e. we're missing an important deadline or our QA failed and there's a major regression in production - then everybody forgets family and other issues and is put to work until the problem is solved. It's just part of the business, and even with a family I'm prepared to carry my share of that load. But this should be the exception, not the rule. Besides, everybody knows that very extended working hours is just not productive, remarkably for intellectual work. Kids may have more stamina to pull 16h+ working days, several days in a row; but this doesn't mean they will deliver the same volume and quality of work that they would on two normal 8-9h days. Managers who don't notice this are just stupid; they are manipulated by these kids. Just as some veterans use their legacy code as job security (you ain't fired because nobody else understands that old crap), I suspect that some young devs use this tactics to assure their position (you ain't fired because when a crisis happens - and it often happens because you're a rookie on everything from estimation to design to coding to testing - the manager knows that you're available to be working up to 2AM of Sundays).

On a final note, the equation of young developers to 80h/week developers is indeed a bad stereotype. I'd rather equate a 80h/week developer to a person who just doesn't have life.  I don't do regular 80h, even 60h weeks, but I never did that even when I was 18 - and everybody knows me as a passionate software developer. The family has mostly taken the time that I used to spend in other personal things: movies (was a cinephile who watched 5-10 movies/week), hanging with friends, literature (aka "books without any code"), computer games, etc.

John Wooten replied on Mon, 2010/08/30 - 9:36am

I had worked in government labs for many years (very much like corporate software culture), and then branched out with my first consulting job in Silicon Valley. I was significantly older than the typical software engineer (57 at the time) and was really worried about whether I could compete with the reputed "hot shots" during the dot com growth. I found that it was mostly all hype! I got to work at 7AM in the morning. No one else showed up until they roller bladed in around 9:30 or so. They took 2 hour lunches and left at 5. It was not difficult to compete, there was no competition! None of the young hot-shots knew anything about system engineering, scalability, real testing, abstraction, stubbing, mock tests, etc.
We assembled a team of 5 Ph.D., all very experienced, and did a complete delivery of a financial application from start to first 100,000 users with a write-up in the Wall Street Journal in 100 calendar days and no application errors in two years of continuous use. You don't get this with new outs! My partner and I then repeated this performance 19 more times, creating highly functional, reliable, scalable applications within 100 business days (got a little slack there).
We always use small numbers of highly trained professionals who can abstract, who have experience, who cost more, and who can and will produce. These capabilities are not age related other than the obvious relationship for experience. We have excellent 30 year olds and up into their 60s. Many have families and have normal hours but put in the extra effort when required. One thing we've learned to avoid is the "hero" syndrome. A good software engineer produces very good software and avoids the long over nighters except when a real crisis occurs. We've found that our skills at estimation based upon known production rates allow us to make realistic schedules. This requires experienced people so that we have reliable production rates. Without these, program managers are guessing and deliveries cannot be made as promised.

I'll take a small team of older skilled professionals any time I have to deliver on-time, on-spec, and on-budget!

Andrew McVeigh replied on Mon, 2010/08/30 - 12:53pm

ageism is definitely a factor in IT. i work in investment banking IT and I've seen it first hand. i've also seen the huge cost of lack of experience on some larger projects. case in point - i recently finished a trade integration project, which resulted in having to draw down into some pretty deep reserves of technical and political experience (i'm 42 btw). when the project was almost completed, they informed me that the project had been attempted before twice before in the last 5 years and failed due to factors which an experienced team lead would have accounted for...

so, having said that experience is very important, it is not always linearly correlated with age. i've seen some older programmers with less "good" experience than many junior developers.

and i've also seen unfortunately people lose their enthusiasm for programming as they get older, and watched in horror as they've hung onto their roles despite it being time to move on... in this respect, i've certainly learned to appreciate the immense enthusiasm of youth.

Mike P(Okidoky) replied on Mon, 2010/08/30 - 8:14pm

"take a month to train a young developer and they're still ahead. Rriigghhtt....

Experience is the most valuable asset, period. The spaghetti disasters that most of these young developers spit out is a dead end almost every time. I've seen this time and time again for over 20 years. Many of the young developers will not invent any new solutions, but instead can only extrapolate from existing constructs, and even then they butcher it up. It's that true inventiveness that contributes to a company's technology base that gives them the edge. Unique technologies bring a great deal of value to a company in more ways than one. You attain those values with experienced people, not people that are just good at following orders.
However, not every "old" ("experienced") developer has become of the Jedi caliper either. Some put out the same convoluted clutter they put out when they started out.
Companies should ask the developer to spend some time and create and implement a solution to a problem, before hiring, as part of the hiring process. Perhaps make him/her create a prototype under a 3 month contract.

I guess my point is that the truly inventive people that can really make things work, are almost always found amongst the experienced, and not the young. A company has to decide if what they want to do is just perform basic routine things, or if they want be in a unique marketing position. The former are a dime a dozen. They also come and go.

Tom Smtih replied on Wed, 2010/09/01 - 8:14am

The reason a young, inexperienced programmer needs to work 80hrs in a week is because they don't know plan and program. They just program.

 An experienced developer thinks first, then programs.  Thus, an experienced programmer get more work done in a lot less time.



Edwin Martin replied on Thu, 2010/09/02 - 5:10pm

Just ask any programmer to look at code they wrote one or two years ago. Many times they will think how they could write garbage like that and how they would do much better now.

Programming is so complex, you can (and hopefully will) always improve yourself. The longer you program, the better you are.

You'll learn how to write programs with fewer bugs, which are very readable and easily maintanable.

As a 42 year old freelancer who worked at many places, it's my experience that the more professional the end product is, the higher the average age of the programmers is.

In IT, knowledge is outdated quickly. If you stop learning, you can't find work a couple of years later. I think that's the main problem of "older" programmers who can't find work: they just stoppen learning at some point. For a little bit I also hope that is the problem and it's not the recruiters fault.


Hassan Turhal replied on Sun, 2012/09/16 - 3:09am

Seems to me that age isn’t what it used to be either. Most of the older (40s+) developers I worked with when I first started out in the 90′s had been working at the same place for ages, typically using the same skills their entire career. Change scared them. That is still true for many developers in their 50s and older, but many developers I meet now in their 40s have been building on and changing their skill sets regularly throughout their career. They are used to and comfortable with rapid change and learning, and appear ready to keep doing this for the rest of their career. So, yes, they might need to make different choices regarding the hours they work, but their ability to become productive with new tools or languages is at least as good as younger developer and often better. I would never have said that about the older developers I worked with early in my career.

Advanced Java Examples 

Richard Mullins replied on Thu, 2012/06/21 - 6:13am

Thanks for the comments.

I was fortunate to work in USA (St Paul) in 1995, at the age of 50. My career was already "toast" in Australia, thought I was able to teach or tutor computing up to the age of 58. I learnt Cobol/DMSII at the Burroughs factory in 1973 but did not build on this. Thankfully now, products such as Microsoft Access and Java are almost ubiquitous, and provide a usable  "programmer workbench".

I still haven't given up on the idea of being paid to write computer code. I don't think my skills have diminished at all.

When I was 30, or even on occasions up the age of 60, I have worked all night to complete work, sometimes getting little sleep for several days in a row. I am not willing to work like this now, as I would expect to drop dead. But in hindsight,  I don't think it was a good idea at any time.

In hindsight, I would get some exercise every day, e.g. swimming, jogging, or cycling, and also plan to socialise most days, and limit my work to 6 hours a day only. 

I noticed recently that I had plenty of time to write code, but lacked the motivation to do so. Following this I began to work on an "automated dictionary" project, which would study a database of parallel text in two languages, and decipher the meaning of words. After working on this for 6 months, I have to concede that IBM and Google are a million miles ahead of me along the same track. The project isn't dead, but I haven't written any code for a couple of weeks. 

I worked for 4 weeks at Burroughs factory in November 1973. Almost everyone there came it at 9 and went home at 5. These people were writing serious software, e.g. PL/I compiler. Because of the strange work habits I had recently developed worked at Burroughs in Canberra, I would work most of the night 3 or 4 nights a week.

 I noticed in 1981 that some computer students at a university were working all night. Maybe this idea came in initially because computers were expensive (even if they were only 40Kb in 1968) and therefore it seemed ok to have shifts of computer operators working around the clock.

Thanks for the opportunity to comment.

Sergo Cusiani replied on Sat, 2012/12/15 - 9:22am

The whole discussion is about how new art transforms into simple craftsmanship. Until the beginning of 19th century there was no definition for what we call and presume engineering. "Engineers" were rear because the industry was small. The role of engineer were perfectly played by artists, mathematicians, philosophers, etc. (Leonardo da Vinci being the ultimate example). These dedicated and talented people did not need descriptive geometry to simplify drawings so that any craftsman could do the work. Of course, workshops also had high-skilled staff. Number of talented individuals is limited in every society, so that when the need increased with industrialization development, it became obvious: not everyone can be an artist to make drawings. Descriptive geometry, theoretical mechanics and other subjects made it possible to "churn out" thousands of engineers every year!

Current software market requires more and more developers. Currently, most of university undergraduates learn the subject because it is highly paid, is popular, provides comfortable office, or other reason. They do not understand how the code works inside the machine because they have no incentive such as  "ancient" enthusiasts had. In addition, while  enthusiasts were spending time on development, their fellow workers from sales and marketing were planning their career to become top managers after 15-20 years. Of course, these top managers will hire young stuff, which is easier to control. Until the young gets 10-15 years of experience! But this is not a problem since you can fire them, too, to bring another bunch of young programmers hiding behind the bullshit like "the availability for overtime work ours".

As a result, modern software is huge in gigabytes and slow in motion. Has millions of bugs propagating from one release to the other, despite the support desk insurances.  

Dealing with  support desk is another Kadomtsev-Petviashvili equation !

Sergo Cusiani replied on Sun, 2012/12/16 - 3:30am

Overtime work on a constant base is not cost effective! This may not be written in management books, but I know that from my experience, though from other activity. 

Plastic liner layers of Joint Venture worked 8 hours a day. The Chief Engineer ordered 12 hours' daily work time to speed up the process, paying at x1.5 hourly rate for extra 4 hours a day. The workers were happy with doing more work and getting paid for it. This did not last long: in 2 weeks they were exhausted so much that could not lay even what they used to do in square feet previously with 8 hours. And they were using any opportunity as an excuse for  underperformance, such as: windy weather, too much raining or snowing, et.c. Quality of butt welding also suffered.

In Soviet era such an approach was called "Extensive way of development", which was disregarded even under the late Soviet leadership. 

Kevin Walker replied on Fri, 2014/03/21 - 11:05am

Really what's the end point. You go to Engineering college where you learn progamming, mathematics and then you go to Graduate School and learn computer Science. You know you are confident enough to say I am better than most people. But some person who went to get a history, psychology or language degree and could not find a job enters into IT. They know they cannot do programming so they enter into testing or requirements. Slowly while you are working hard solving the main issue which is producing software these non-technical people who think they know the IT process or how to take requirements(which believe me can be taught in less than a week to a high school kid)  end up being your manager. And the reason well "I don't have to be technical to be a manager, I just have to know the process". They will create tickets, ask you to put estimates, and then track your progress. Whole IT field is a joke. People who become process improvement "experts" or high level managers are mostly who couldn't find a job as a teacher or a sales person or a speech therapist. :)

Kevin Walker replied on Tue, 2014/09/09 - 10:20pm

Just go back to college, get a degree in history or music or audiology or something totally unrelated to IT, don't do any technical work EVER, that way you cannot do any programming or IT technical work and therefore you can become a PM : ). That way you never ever have to learn anything new in technology, EXCEL will remain the same, and color RED GREEN and ORANGE will remain the same too. 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.