What's up with the phrase, "Still programming?" Would anyone think it odd for a 60-year-old physician to still be doctoring, or a 60-year-old lawyer to still practice law. Or for that matter for a 60-year-old artist or craftsperson to "still" pursue their craft.
Corporate culture embraces the notion of management as a profession. I think programming would benefit greatly from more of a tradecraft model, where leadership is provided by the master practitioner rather than the professional manager. In the alternate universe that's how we do it. The bottom line productivity boost is awesome. I don't know if it scales, but I don't care to scale.
-- 63-year-old full-stack web and machine learning programmer...living the dream
What's up is the rampant ageism in the industry - the perception that you are washed up as a "dinosaur" developer after a certain age, maybe 40 or so, and belong in management.
We "dinosaurs" - we happy few - are living evidence to the contrary.
-- 58 year old broad-spectrum software guy, hard at work and loving it
There is a reason graybeards are valuable. It's not that they're over 50 or 60. It's experience. A full-stack developer with 20 years' worth of experience will not make certain kinds of mistakes.
I'm in the awkward position of having only gotten a CS degree and taken programming seriously after 30, so I suppose I'm the worst of both worlds. Of course, I also started going gray at 30, so...
I just graduated with a CS degree at 36; have an offer and will start soon. The age aspect is scary, but I've honestly found it less of an issue than I thought. The most difficult part is pushing past the part of me that says I'm too old to be starting now.
I'm currently working as a developer and aiming to go back to school within the next year or two for physics, after some catch-up math courses.
Good for you for even setting out. It's intimidating, if not down-right frightening to start all over again at something.
But hell, the unconventional is increasingly becoming the conventional. Some of the best advice I ever received was from a doctor I had when I was young. He was an old Jamaican man who went from the slums of Kingston to Chemical Engineering in the US to a practicing MD (physician, general practitioner) in a small town in Canada. He just said (kind of what you'd expect from a Jamaican man): not to worry about anything.
Just do things, make messes, clean them up, do more things. You just might do some good in the process.
I graduated CS at the age of 27 and thought I'd be at a disadvantage starting out in the industry due to it. If anything the couple more years seems to have helped me out quite a bit as I found it made me more relatable to the more senior technical people and management.
In the modern dev shops now the soft skills you've developed in the additional years you've had before getting into development will give you quite an advantage since 99% of places aren't just heads down coding anymore.
Where I've found I have a disadvantage is in my non-work commitments and free time outside of work. The younger guys can spend their evenings and weekends working on side projects, going to hackathons or just learning something new, whereas I come home to the family and try to spend quality time with them, do my share of the work in the upkeep of the house, yard, etc.
We only get one shot at life so you're never too old for anything in terms of what you want to spend 40+ hours a week doing to finance your life.
After 30 is totally fine. I know several programmers who either switched to programming around 30, or had a long break from programming. Sure, you may be a junior developer while younger people may already be senior, but there's time to catch up, and with a bit of maturity, you may have a far better attitude than young cowboys who think they know everything.
In enterprise adults are often more useful because understanding, dilevery in schedule and the ability to do what you are told is immensely more valuable than doing things in a fiery passionate way on some new tech.
On top of that, while you might learn slower, you probably attended more classes and played less video games during them than 90% of the twenty year olds.
By default, most programmers from two decades ago ARE full stack developers.
Back then, there was no separation of front end, back end or database - it was all melded into one, so if I wanted to write an app, I would have to learn the language, figure out how to display the data and collect user input from the screen, write the data tables and the code to update it etc. etc.
There was no question of learning SQL or raw file system I/O to manipulate data - there was no ORM or framework to fall back on. Until Windows came along, there was no standard on UI or UX principles. It was all 'build it as you go'.
Some of those older habits die hard. Though I use ORMs almost all the time now, I still find myself experimenting with queries in raw SQL before translating them to my ORM of choice. I still have a hard time separating my front end code, or the design elements thereof, for someone else to do, because I am so used to doing it myself.
Somehow, I still feel the need for ownership of all aspects of my application stack, and will often spend an inordinate amount of time learning about something that I am not familiar with. As I said before, Old habits die hard.
So, while I don't often refer to myself as a 'full stack developer', I do routinely say that I 'do it all, including making the coffee and sweeping the floor in the server room'.
Yes! Thank you. I never know what to call myself. I just signed a comment as "broad-spectrum software developer", but your description is more accurate.
We catch the things that fall between the cracks; we are the glue that binds together the things that fall apart; we are the toolmakers, the automaters, the pinch-hitter sysadmins; we are problem solvers, the ones that do whatever it takes - and if we don't know how, we learn.
Exactly right. Back in the day you had to know a lot more to get stuff done. You didn't have databases as a service with built in public APIs, authentication, etc.
Younger devs have it made in that regard. And the amount of tutorials and quality are amazing these days. They do have a lot more technologies to learn though.
Full stack is just new age lingo, and sure why not. We say AI (shudder) these days instead of ML, we say devops instead of sysadmin, we say cloud instead of vps/hosting.
Times change and so does language, true to any old fart out there, and the old farts to be.
Apparently the new hotness is AI. The last five years have seen titles with similar(ish) roles evolve from Data Scientist -> ML Engineer -> AI Engineer
I studied AI back in the 1990s, but these days it seems to be called ML everywhere. To me, ML sounds like the new hot name (of course it existed back then, but it was less commonly used).
No, no, that's just today speak for "systems developer". Really, someone who can dev/debug run-times for any languages, write C10K networking code, write good Haskell code, do wonders with average SQL RDBMSes, suffer through JS, and put together a complete solution.
I actually like the term "full stack developer". I take it to mean: can handle anything from assembly to HLL and everything in between.
I always took "full stack" to imply web stack, like MEAN or LAMP. Maybe I'm misusing it, but I tend to call myself a full stack developer and I don't know a lot about assembly or low-level languages like C.
It's such an insufficient title when your product is a robot and the database is closer to the top of the stack than bottom. I gave up on titles a few years ago when I began to realise that so much of it feels fitting of the dot com era but not today.
It's a thing, isn't it? I mean, as words and phrases go, it at least means something, like not just front-end, back-end, or client-side view-model reducer mapping specialist. AI is much close to fully content-free.
I've jokingly referred to myself as "full stack from transistors upwards" - I've done (professionally) a little bit of everything all the way from chip design to web server administration.
no, it only seems that way because the powerful silicon valley and finance giants are the only ones with access to the top-tier young talent. the rest of the young people out there are inexperienced and not that smart, and definitely aren't worth a six figure salary.
so everyone else just hires older people, but it isn't sexy and marketable to the impressionable technology crowd.
You also can't get away with demanding the same work conditions or work/life balance from an older person than you can from a 21 year old CS graduate who's very eager to impress and has little other commitments to attend to.
I can't imagine you'll find many older, experienced devs willing to put up with the "we need to ship so you've got to put in 80 hours this week. You build it, you support it so keep your phone and laptop by you at all times outside of work" shtick that a lot of tech companies beat the young guy devs with.
> I can't imagine you'll find many older, experienced devs willing to put up with the "we need to ship so you've got to put in 80 hours this week.
Yes, because we've fallen for that bullshit before, killed ourselves to meet the deadline, and found that the asshole manager made it artificially short to "motivate" us, and the other teams aren't even finished yet :)
I've read his Mythical Man Month book, including parts of the anniversary / silver jubilee edition, but it's been a while. A couple of questions:
- Was the toolsmith idea about some people in the team building tools, that others in the team use for the project? - and if so, what was the benefit cited - specialization?
- What was the second system effect about? I know I can google, but interested to read your take on it first.
"Was the toolsmith idea about some people in the team building tools, that others in the team use for the project? - and if so, what was the benefit cited - specialization?"
Yep. The benefit is efficiency. However, modern SCRUM advocates simply advocate grinding away at stories.
"What was the second system effect about?"
The glittering new rewrite of an existing system is usually overengineered and worse. Seen it several times.
Interesting about the 2nd point, thanks. Might make for interesting reading if there are any articles about that. Intuitively, I would have thought that a second system (rewrite of the first) may be better due to lessons learned.
>Intuitively, I would have thought that a second system (rewrite of the first) may be better due to lessons learned.
And at least in one case, it was: in a C database middleware product that I worked on, as the team leader. It did work earlier but had big issues of bugs, slowness, memory leaks, and maintainability. There were many reasons for that, including complete freshers put to work in it (a mistake). After me and a small new team took over, we improved it a lot and fixed all those issues. It went on to become a much more successful product, deployed somewhat widely within the company, for client projects ...
> Or for that matter for a 60-year-old artist or craftsperson to "still" pursue their craft.
I still find it rare for 50 or 60-something designers to still be actively hands-on designing purely as a designer. At a certain point, a lot of the ones I know of migrate into creative direction and ideation, delegating the hands-on work to younger designers. It actually scares me a tad because I like being hands-on and generally dislike focusing my time on managerial activities, but it's always going to be hard to just limit oneself in that role as the younger generation will always be a little bit faster and more talented.
Faster? Probably. Faster at making mistakes, certainly. More talented? Absolutely not. That's the myopia of SV's cult of youth.
We're all running the same hardware, and there is very little that does not get better with experience.
If you want an analogy in a different field, consider Dale Chihuly. From his wiki page:
>In 1976, while Chihuly was in England, he was involved in a head-on car accident during which he flew through the windshield.[6] His face was severely cut by glass and he was blinded in his left eye. After recovering, he continued to blow glass until he dislocated his right shoulder in a 1979 bodysurfing accident. No longer able to hold the glass blowing pipe, he hired others to do the work. Chihuly explained the change in a 2006 interview, saying "Once I stepped back, I liked the view," and pointed out that it allowed him to see the work from more perspectives and enabled him to anticipate problems faster. Chihuly describes his role as "more choreographer than dancer, more supervisor than participant, more director than actor."
There is no inherent reason a more managerial position involves less creativity. It can frequently enable more.
Honestly, I'd rather be led by a "dinosaur" programmer than some marketing or MBA geek any day. At least then I know that my boss would go to bat for me when it's clear something is achievable within the capacities of the team or department. I've worked for too many clowns that think computers are magic boxes where you just whisper a few words into then you get a fully fleshed out platform out of it. Seriously, it should be a legal requirement that you have at least a year of experience in the profession you'll be acting as manager in.
The management track seems unsustainable anyway if the projected career path is seen as Developer -> Manager with no alternative, unless you just keep adding layers of management.
Totally agree. I'm a partner in a small business and I don't have to do any programming but I enjoy it so I dedicate at least 50%. I also run some accounts myself and provide strategy and leadership in addition to the sr. programming. I manage my team too.
There is a notion that the next step should be to not do any programming and be a manager. All that does is ensure you have extra layers. I have respect as a manager because I'm still current and more skilled technically than my team. If I leave my craft my skills will decline and I wont be able to help my team accelerate in skillset. You're a better manager if you're also a subject matter expert.
You should move out of low value programming but I don't think giving it up is good.
* Knowing when to tell a product manager to go back and do some more product managing
* Knowing when to say "No"
* Knowing how to determine what a stake holder actually needs vs. what they think they want
* Understanding that 8 hours today and 8 hours tomorrow is 10x better than 16 hours today.
* Saying "I don't know" when asked "How long will it take" or "When will it be done"
* Fighting against shitty processes
* Fighting FOR processes
* Forcing PMs to use software designed for the purpose of creating software instead of accepting requirements through email/slack/invision/zeplin/google docs/tool of someone else's choice
> Saying "I don't know" when asked "How long will it take" or "When will it be done"
~5 years experience speaking: How do you do this?
I have a very good boss and he knows things, objectively, like "estimates are very squishy," and "developers suck at estimating time" etc. But he still demands time estimates to give clients.
Our clients are often agencies, and they get it as well.
I do estimates like "10-40 hours, depending on XYZ (things I don't know)" sometimes and it doesn't really raise any eyebrows. That may as well say "I don't know."
Are you better than this? Do you just outright refuse or do you have some way you handle it?
Give half-order-of-magnitude estimates as confidence intervals. Avoid using "hours" or "days" as estimates. Story points work really well here.
Be extra clear on priorities and burndowns to make it clear that you're not just blowing them off. Give short but frequent demos (not just reports) of progress. If later they're concerned about progress, you can point back to all the times you reviewed the product, touched base about priorities, and agreed on next steps.
Make risk really clear to them. If the project is 'get it done in three months or bust', then the payoff (ten times the principal?) better be high enough to account for the risk (30%? 50%? 70%) that you won't make it on time and on budget. That is, you don't want to wait until failure to discover a bad business plan.
At the end of the day, you need to be willing to be patient with and/or walk away from 'business people' that can't wrap their heads around the fact that 20% profit on a venture with a 50% failure rate is a bad business plan. Making employees stressed or overworked to compensate is not a humane solution to the problem. To that end, don't work crazy hours to meet a deadline. That is bad for you, bad for your team, and bad for management since it enables dysfunctional planning.
My current boss likes to ask "is it a day, a week, a month, or a year" and while sometimes I just want to say "yes, it's one of those" I actually think that's a pretty reasonable way to ask the question.
I heard a saying once, "Deadlines slip by the units they're measured in." If you say three weeks, it will slip by weeks, not days or months. If the estimate is months, etc.
Could you go more into detail how these story points would work. It seems like in the end a story point would always be associated with a number of days (or hours).
I measure effort, complexity, risk, and dependencies all with one number. If you don't
Things that affect story point values for me. Note that some are more about quantifying "risk" than "how long will it take?".
- how "big" is the change?
- how many parts will be changed?
- are the exit criteria vague or open to interpretation?
- is the change easy to test?
- do we have sample inputs and outputs?
- will we have to design for a tricky deployment?
- will we have to design for a tricky rollback?
- will it be hard to peer review?
- if this feature is impossible or more expensive than we thought, will we know early or late?
- is any of the code being changed extra finicky?
- do I need lots of help? code from other teams? approvals? new software installed? new hardware?
- can I iterate on this code? or does it really need to be perfect the first time?
- will we have developer 'concurrency' or 'parallelism' issues? can anyone chip in and help whenever? or is one distracted expert the only one that can do this?
...for me it's an intuitive guess at a number that flattens all that into something we can use to prioritize work and decide that work needs to be broken down more. What exactly is on that list will vary, certainly, but I would put on anything that could cause bugs, make you wait, or make you underestimate a task.
I'll often say something like "I don't know off the top of my head, but if you want I can get back to you with an estimate."
Once it's clear that I'm going to spend some non-trivial amount of time working on the estimate, the answer is often, "No, don't bother."
On the other hand, if person asking does want me to get back to them, I now have the time to do a good estimate—research the problem, break down the parts of the solution, think about the unknowns. Even a "good" estimate is still squishy, but it does tend to be based on explicit assumptions, and often flushes out hidden design or spec issues.
Spend time to fully estimate each task in each feature point in hours and double it of course. Now increase the unit of time by one: 3 hours = 6 days, 2 days = 4 weeks, 4 weeks = 8 months.
But my point is that if there is a relation of trust between the PM and the developers, padding is unnecessary.
I had PMs to who I could give optimistic estimations and risks. That way, the PM could plan the different scenarios (like extra features in case we had spare time).
Other PMs, the ones who converted estimations into deadlines, got lots of padding. And the problem of adding padding is that it is time lost, because a developer who adds padding cannot tell that they finished earlier.
Often times managers demand an estimate from you, not because they need the job urgently done, but just so that they can hold you accountable to something. If you promise something, they can assume that you will give your best to keep that deadline.
One way to do this is to point out how the requirements are vague, lack context and fail to state how the requirement will benefit the business. Point out how it is sloppiness in documenting requirements that leads to scope creep, cost overruns and ultimately, failure of the business. Tell management that if they really want to give developers responsibility for finding out what is needed then they should fire all the business analysts, project managers and product managers that are not doing their jobs properly.
Alternatively, they could accept new processes that make sure requirements are clearly written and include acceptance criteria.
The idea behind estimates is to get you to think about the scope the work that is to be done. Quickly walk yourself through the process, give a SWAG, do your best to track your time spent on the task, then review what you got right and wrong in your estimate. It's less about giving the exact time required (in theory - some managers will never understand that) and more about estimating if you have time to complete X, Y and Z.
One thing I do way less in my 40s is over engineer a solution, or worry about all possible someday maybe use cases of a class many Java developers seem to like to design for.
3-5X? What country is this? Typically in Silicon Valley there's a rapid rise in the first 5-7 years and then it gets pretty flat (say, 1.1X or 1.2X not 2-3X) unless you're actually taking on a bigger role (and thus getting paid for those responsibilities rather than "experience" per se).
When you look at it from a company cost perspective, the ratios get even smaller. The fixed costs (desk, power, healthcare, etc) are pretty much the same no matter the experience level of the engineer.
Jesus. When I started in '06, my total comp was 82k. My last year, 2010, my total comp was $115k. I managed to be both too late and too early to that party.
If I compare myself against when I just started, I'm easily 10x more valuable now (in some cases 100x). And I would still choose my current self over 5 copies of myself at 5-7 years of experience.
Maybe if you have a simple problem, like a CRUD application or a simple website, it wouldn't matter much. But for harder problems there is no contest.
This. Most development is CRUD and is trivial. Write a DSS and/or automation system that is bulletproof and saves millions and it's significantly more difficult. The difference between using something like Biztalk and writing something like Biztalk is orders of magnitude more difficult.
If you are using someone else's framework for the majority of what your application does, that's not really software development. I know many people won't like hearing that.
> Forcing PMs to use software designed for the purpose of creating software instead of accepting requirements through email/slack/invision/zeplin/google docs/tool of someone else's choice
Could you please specify examples of proper software for this purpose (communicating product/feature requirements is meant here I suppose)? Do you mean reqs must go through the issue tracker or official original spec document?
I feel similarly as far as being on a whole other level now. I'm 40 and semi-retired. I spend far more time coding per day than I did at the peak of my career in the industry. And compared to myself back then... I don't even know how to make the comparison. The concepts and systems I play with every day now wouldn't have been anywhere in sight for me then.
I was referring to the best way to model associations on client/server code and how that maps to the database schema. For some reason, I find that younger devs want to invent a new way to do relationships every time they have to implement a new one.
"StackOverflow’s survey on age shows that there are just about 13% of developers after 40. Where are the others?"
Not wasting time filling out online surveys?
I'm not even 40 yet and I realised online surveys were a waste of time years ago. :-)
A stackoverflow survey doesn't measure the answers of stackoverflow users. It measures the answers from the specific demographic of stackoverflow users who are inclined to answer surveys. Those demographics overlap but are not equal.
There is still some truth to it. I'm 37 and have had to repeatedly and forcefully turn down managerial roles. The idea of horizontal growth is a hard sell to people who've chosen the vertical path. It would be very easy to drift into a management role, and in fact it happened to me once and I had to take deliberate action to get off the management track.
I don't want to manage people. I want to build, and learn about building. And I hope to be lucky enough to do that until retirement age.
I've done management, and I can say that management experience has been invaluable to me.
I do consulting and freelance development now, and my success is in a large part due to the people skills I developed when managing others. You learn a lot about the many different ways people work (and don't work), and you learn a lot about yourself that you'd never see otherwise.
You learn how to mediate differences. You learn how to spot interpersonal problems on the horizon and head them off. You learn how to protect yourself. You learn how to promote harmony and goodwill. You learn how and when to compromise. You learn how to cooperate better. You learn to hear peoples voices. You learn how to be worthy of respect.
Without these skills, you'll forever be at the mercy of the prevailing political and emotional winds. The satisfaction of knowing you're 100% in the right won't unsink the ship.
Not only that, it's much harder to move around different companies as a manager. That's one of the reasons I stay away from it. Also, I don't like listening to people bitch about petty things. I manage small groups of people but I'm always deep in the code.
Also, most places want you to be a manager only. If you don't code every day, you lose it pretty fast. A friend of mine who is a VP had that problem. He got stuck in a shitty company and felt trapped. He jumped without a parachute but luckily landed.
I'm 10 years older than you but feel the same way.
I would be interested in hearing from people that did make the jump to management. Why did you do it? How did it turn out? Any regrets about making the jump or for not making the jump sooner?
I manage a small team of developers and still do a lot of development myself. My reason for doing it is that because what I want to work on now is bigger than a single person. I have a vision of what I want to accomplish and I can't do it all myself.
So far it's turned out well and I have no regrets. For me it wasn't a jump at all, just a gradual progression of what I've already been doing.
Thank you for posting this point of view. I have a feeling there's plenty of people on HN like this, but I don't see others explicitly talk about it often.
So I'm not terribly old yet (37) but I'm a manager for the last 2 years. I'm on the fence about the whole issue. At my root I'm a builder, I love it and really would never leave that. That said, I've had a lot of REALLY bad managers and I know that I can do it better. I love leading my team. It's amazing and thrilling to be able to tune the situation and work being done to benefit everyone involved to the maximum that the situation allows.
Then comes the downside. Dealing with the other managers and the higher level business people. Some days, maybe even most days, it makes me miserable. I loathe it. So much self interest and political games. The really bad situation is that I work for a company that is actually really tame with that kind of thing. It's just the nature of the beast once you start up the chain.
Honestly I don't think it holds a future for me. At some point I'm moving to starting my own company... again or trying to turn my manager role into an architect/CTO type role or even more likely going back to being a lead developer. I don't regret it because I know what it is and that I can answer that bell when I need to. I just don't want to anymore.
I went into product management (not people management) because I was tired of being a cog just implementing other people's ideas. Admired the product managers as "deciders" and wanted that creative aspect. Little did I realize it'd simply mean writing requirement documents for other people's ideas. Project management is similar: Executing the schedule for other people's ideas. Unfortunately it's pretty rare in the corporate software world to actually get to create something yourself end-to-end.
It's turtles all the way down. Even CEO's feel like they have no agency at times.
It depends on the maturity level of the business you're in. In mature industries customers have a clear picture of what the software should do, even if suboptimal, and you're just there to turn their preconceptions into running software. In new industries nobody knows exactly what it can do, so you have a lot more agency as a developer.
I spent years working on an IWMS system and always felt trapped by other people's ideas, and then moved on inside the same company to a smart building project where I can pretty much do what I want because the market hasn't decided yet what such a system should do. The tricky part is selling something people don't understand yet, but luckily smart building is in the leading edge of a hype cycle.
I'm now 40 years old and recently took a position as Software Development Manager. I manage a small team (currently 2 developers, 1 test engineer, and a product owner, and should be adding 2-4 more devs over the summer). The PO and I still wear our developer hats for a good portion of the day.
The "why?" is simple - I like the challenge. Yes, I can challenge myself with 100% technical tasks, but moving into management was something completely new.
The move into management has been gradual. I followed a standard developer path for years - dev, senior dev, principal dev, architect. Did the architect thing for a few years, then decided I wanted to work on my soft skills, so took over the scrum master role. I have a great boss/mentor, the position worked out well, and I recently took over a full development manager role (basically, same as I was doing, with the addition of personnel management).
How did it work out? Pretty well, I suppose. So far, I'm enjoying the new responsibilities.
Regrets? No, not really. But, I'm also not far enough removed from 100% developer that I couldn't pick up that hat again should the need arise.
Reason is simple, very few people love programming and even fewer love to keep learning to stay up-to-date with new technologies. Its simply hard if you are not much interested in doing programming and were in the profession to get a nice job because everyone else was jumping on the bandwagon while you were in college. It is also possible to lose love for programming after initial interest fades away. It has happened to me multiple times. The only reason I stayed as programmer is because I hate management even more.
I'm 63 and love programming. But my job is mostly other things. I coach a scrum team of 5 devs, PO and a proxy PO. I manage 2 developers, I do some security work and a whole lot more. I manage to write code most weeks. Python, php and Java. For the record I love python but my skills are not where I want them. I'm better, much better at Java, but I really don't like coding in Java much anymore and well I do php when I have to.
I do love learning and will continue to learn as I get older.
It doesn't even matter if they get thousands or millions of survey responses - the methodology to collect the surveys doesn't avoid biases (random collection), nor is there a method to remove the bias.
So much this. A problem with nearly all these statistics is you're gathering answers from the people who are the type of people who answer surveys. This often tends to be a less-private and younger crowd.
I'm 48 and working on shifting back into coding after too much time doing more generalized IT consulting/support/admin/etc. for medical practices, and I'm not nearly as likely to spend time on Stack Overflow as I was 6-7 years ago.
There's still useful stuff on there and some gems, but it feels like there's a lot more cruft to wade through as well and I'm not feeling the same desire to surf the site or look for questions to answer because that's just not as personally rewarding as it once was.
Programmers over 40 would have started programming before 1995. Programmer cohorts who started in 1985-1995 were likely much smaller than the web boom cohorts.
I'm 42, programming is the fun part of the job (meetings, nonsensical time estimates and travel tend to be worst part of the job). Had a computer my whole life (Vic-20, oh yeah!) I strongly agree with what others have said in the article: Keep learning new things. I did nothing but C++ for 13 years (console games) and felt like a dinosaur. Despite the fact that there are still (a few) C++ jobs out there, I made a point to avoid them. Did a python based app for a year (IPython is fantastic!). Did a GO app for a year (which was kind of interesting, only luke warm on the language for some reason). At the moment I am learning Elixir and Phoenix and still get the excited feeling when the program works. It is strange that such a well paid / interesting field has so few older people in it. One concern I have is that my hair is starting to turn grey so I think the HR process will get a bit trickier (planning on moving to more remote work so they can't see the grey :)).
> One concern I have is that my hair is starting to turn grey so I think the HR process will get a bit trickier (planning on moving to more remote work so they can't see the grey :)
I'm thinking of dyeing hair before interviews when I face the same problem.
Not all bias is conscious, or intentional. The hair dye may not be a bad idea, just temporarily, during the search. Get a pro though, obvious shoe polish color is, er, obvious.
As a 48 year old developer with a lot of gray hair...I've never seen anyone with dyed hair where it wasn't pretty obvious. To me it makes you seem a bit desperate.
That's the thing though, if it was done well, you didn't see it. Ask a few women, that already trust you, if they dye their gray... especially the ones you think don't.
They'll notice, yes. Anecdotal, but my experience is that age discrimination tends to mostly manifest at hire time. They think you're too expensive before even throwing numbers. Or too rigid, etc. Things that shouldn't be an issue once you're there.
Kind of funny. I'm going on 40 but look much younger. People think I'm a Millenial. I'd never dye my grey and white hair because looking older helps me close business for my team and I think clients and partners generally feel more comfortable with people that appear to be close in age. If you were client facing they'd want grey hair. But if you aren't the culture seems to disadvantage you. Pretty dumb. I can't discriminate and hire based on having grey, but I can tell you that there are a lot of companies out there that are welcoming. So I think you should rock the grey and you'll land at a better place. :)
I'm 63 and started coding FORTRAN in High School on a GE teletype. Did just a little coding. Went to college and took a FORTRAN class and a PL1 class. I loved PL1. All my undergraduate coding was with punch cards. IBM 360/50.
Im graduate school for engineering I coded just FORTRAN with punch card images but on a terminal. So that was 1000 times better than physical cards. IBM 3090.
In a character cell terminal editor we would create data files with one line per card image. In essence a punch card for fortran as each line. This is not much different than what we do today. Today we create a line for each line of code (or comments). It was just that punch cards required specific columns for code and other controlling characters.
With physical cards you would carry boxes of card around. If the cards got dropped you were hosed unless the cards were numbers. We had columns for numbering the cards. But when writing a program from scratch you could not number the cards till the program ran correctly. Much fun!
I'm 71, I wrote a best-seller in the early 1980s (Apple Writer for the Apple ][), I still code regularly but not for income, so my circumstances might not be what the article focuses on. I write a lot of Python, JavaScript, some Java, I have a number of Android apps listed at the Google Play store -- all of them free, no ads (https://play.google.com/store/apps/developer?id=Paul+Lutus&h...).
Why do I still program? Because I like programming. I never experienced serious burnout, probably because I didn't have to program for anyone else -- I was always my own boss.
Apropos the article's topic, I often visit StackOverflow but I never post anything there, I only read the inquiries of others, which invariably provide the information I need. This practice might make people like me essentially invisible.
Paul Lutus, you a mith of my Apple ][ times. cant believe (and SO happy..) you online!! IIRC you were programming in a bungalow out of nowhere at that time.. right?
really, you made my day^W week!! honored to be chatting with you, really.
BTW it's amazing this "virtual gathering" happening online in 2017. who could have been thinking, 30 years ago, this to be possible this way, so smoothly.. can't imagine where we are headed in the next 30..
Wow how cool. I used your software on my Apple //c and pretty much wrote my entire middle school and most high school reports on it. In fact, when I switched to word perfect I longed for apple writer. Thanks for making it.
".. However, StackOverflow’s survey on age shows that there are just about 13% of developers after 40. Where are the others?"
Obviously not on StackOverflow. Perhaps they have enough experience and knowledge to not need the site because they either know how to read tech books and sites to get the info they need when they have a problem using pre-existing docs, or conversely, are fully able to debug issues themselves.
Definitely. The content on Stack Overflow is heavily weighted towards languages and specialties less likely to be of interest to older programmers. We (I'm 51) are far more likely to be working on infrastructure and devops than on front-end. To do it, we're using C, maybe C++, maybe Python or even perl and bash, not Java, definitely not JavaScript or any of its variants, or Erlang, or Clojure, or whatever. Not always, but much of the time. The things we need to know are scantly represented on SO.
The atmosphere on SO is probably also more of a turn-off for older programmers. Those who are established don't need to bulk up their karma on some website, and the one-upmanship from the resident karma whores gets tiresome really fast. So does the rules lawyering that leads to answers being hidden, questions being closed, and so on. The few times I've found myself there, it has seemed like a game and a distraction that I just don't have the time or inclination to keep playing, so I get out and don't come back for months. For those with broad work responsibilities plus homes and families and other outside connections, life's too short to spend much of it in a virtual mosh pit. HN is enough for that. ;)
> To do it, we're using C, maybe C++, maybe Python or even perl and bash, not Java, definitely not JavaScript or any of its variants, or Erlang, or Clojure, or whatever. Not always, but much of the time. The things we need to know are scantly represented on SO.
The languages you mention using are all in the top 20 tags. Yes, JavaScript, Java, and C# are the top three, but Python is #7, C++ is #9, and C is #18. Bash is on the second page and Perl on the third, but there are a bunch of other, less trend-sensitive, tags in between (e.g. regex, string, and multithreading). http://stackoverflow.com/tags/
True, but ordinal position doesn't matter as much as absolute value, which tends to fall off according to a power-law distribution. For example, Python (#7) is tagged barely half as often. C (#18) is a third of that. Topic-based (instead of language-based) tags fare even worse. "Filesystems" has been used only 6K times, "storage" less than 4K. As someone interested in those areas, there's just not going to be much content for me - few answers to my own questions, even fewer opportunities to answer others'. When the density of interesting content falls below a decent threshold, my interest doesn't continue to decline linearly. It simply drops to zero. I suspect that's true for a lot of people working outside of the web/app/mobile space. SO is just not seen as a forum for them. It's a forum for a particular (common) kind of programmer, and everyone else feels like a bystander or gatecrasher.
>I don't understand how someone can "have enough experience and knowledge to not need the site".
If you've been programming for a couple of decades and you don't follow the trends du jour it's actually quite easy (note: I'm not at that level myself).
Seasoned C and C++ programmers, for example, don't have much to learn from Stack Overflow in the same way a (1) new programmer, (2) 0-20 years programmer who constantly juggles languages, APIs and frameworks etc depending on the job and the fads of the season.
You think someone like Linus checks SO to get his answers?
There are tons of programmers with such levels of experience (even if somewhat less so than Linus).
Let's put it another way: before 2008 NO programmer checked "Stack Overflow" all the time. Before 2000 they didn't even have Google, and before 1995 or so they didn't have much (if anything) in the way of online documentation and similar resources.
That's not ancient history: a 20 year-ish programmer has managed for 10+ years of their career without Stack Overflow.
I don't tend to use StackOverflow all that much. Once in a while I'll look up a poorly documented error code on Google and one of the results will be S.O. But, then again, I tend to stick with languages and libraries with adequate documentation.
Honestly, if one is constantly looking everything up on StackOverflow, they're either using a very poorly documented technology or they might want to hit the books a bit and work on proficiency. "Knowing the literature" is becoming more and more underrated.
I think the idea is that after being a developer for 20+ years, one may either develop some intuition about how to use some package even if the documentation is poorly written, or else you have so much experience reading source code that doing so is almost as fast as reading the documentation.
I'm not saying that either of these is correct, but they could be plausible explanations.
I'm 48 and use StackOverflow... not so much because I can't read tech books and docs, but because often times it's faster to at least get a lead (and to be fair, I'm usually using a search engine which in turn places StackOverflow answers towards the top of my result list). Also, if it's tech that I'm less familiar with, I'm often times looking for how others think about the issue I'm looking at which you often times don't get from documentation. Sometimes, I'm looking for contrary arguments if I've decided on an approach/usage but am less confident of my direction.
Now I do use my experience and knowledge to decide if I think any given answer on StackOverflow is likely to be "correct" in some sense (and by no means are all the answers, accepted or not, good all the time)... and there are occasions where I end up just going back to straight docs.
I have worked with other very smart over 40's (and over 50's) that do something similar to what I do with StackOverflow. I know none of us would take an online survey either.
The number of new CS grads has grown year over year making a raw percentage meaningless. A more useful statistics would be the percentage of developers the exit the field at each age.
I grew up in an era where if I somehow forgot the option for recursive for the rm command I reflexively typed "man rm" and "/recursive" and maybe "/" a couple times. It seems younger people will context switch from the console to the web browser, pull up a google window, search for "unix.stackexchange rm recurse" and slowly scroll thru "About 43,700 results (0.97 seconds)" for perhaps hours, opening multiple tabs. Perhaps they'll very sloooooly use a touch screen phone, or even worse scream across an open office interrupting 100 people who were in flow mode, but hey it saved them five seconds with the "man" command.
The other problem is I removed my training wheels in the 80s or 90s, and my problems are almost purely subjective, like "what is the best virtualization system running on FreeBSD" Google search of stackoverflow finds no question asked. Thanks stackoverflow you're really helpful when I forget what command copies files on linux (kidding), but not for the important stuff.
OK thanks stackoverflow for having the same question but for linux perhaps I can work off that ... wait, whats that, "asked 4 years, 2 months ago" Well I can't work with data that old, may as well not even be on line... And whats this... "As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance." Well, stackoverflow can just go F itself. It certainly doesn't answer any question I need answered.
My examples above were pretty staged, but across real topics, SO does boil down to a medium-to-slow speed way of answering relatively low level questions. Old timers work too quick, and they've already learned too much to ask the kind of question SO can answer.
I do this, but I googled it first to know that the recursive option actually exists and what it is called. Those man pages are decent references, but are usually useless for actually learning the tool.
Maybe elsewhere. My specific examples were inexperience leads to massive time inefficiency which is hardly limited to age, and young people are sometimes a bit inconsiderate of others which seems so universal its not even a bash, almost a definition of being youthful, could be filed as social inexperience. If I wanted to imply they're stupid I'd falsely claim they just don't have the IQ/mental horsepower to figure it out, or they can't generalize that a lot of CLI recursive options tend to be dash-R, or they can't remember and have to look it up every time. But I didn't...
The meta observation is inexperience can lead to not understanding critique. Which again is not even a "youth" thing.
Mid 40's and older had to learn without the use of the internet. Programming as a profession wasn't ubiquitous as it is now for that same age group.
Above 50 and they didn't have a computer in their house growing up. I'm mid 40's and I had one by 9th grade, but it was a high bar for entry compared to today.
52 and I started with a KIM-1, https://en.wikipedia.org/wiki/KIM-1 (mowed lawns to save up for it, still have it, still works). Been programming ever since and rarely use SO (most of the time I just read the code when I'm trying to grock some aspect of a library.)
That's my bet. I've gotten away without asking any questions on stack overflow since its genesis. There's usually enough already asked on there that I can synthesize the answer or trigger an idea for something to try that ends up working.
Yeah, and I feel there's not much point contributing answers either, because it seems most situations are either:
1. Simple and quickly snapped up by other users who are aggressively trying to grow their reputation on the site (perhaps with more free-time than I) and there's a first-response advantage that crowds out later answers.
2. Duplicate of something else. Why bother making a good answer when it'll get closed because somebody else happens to think a different question is the "better" one?
3. Way outside my expertise and it's probably better for everyone involved if I don't try to answer when I'm not sure.
So in a way SO is a victim of its own success when it comes to lowered engagement.
P.S.: I've even had an answer I was proud of converted into a "community wiki" just for a few tiny wording changes, with the side-effect that I get no reputation from it. So yeah, it seems like a rat-race.
48 here, programming since my early teens and I enjoy contributing to StackOverflow when I can and leaning on it in return for help keeping up with the explosion of 'modern' programming techniques. I'm not too proud to recognize it for the invaluable resource that it is.
I use it to look up things now and then as the result of a google search but generally its a distraction and I'm not there to find validation so I don't even have a login. I don't think this has anything to do with age though. Maybe older people just have less enthusiasm for filling out surveys.
Using StackOverflow is often the fastest way to find results. Your implication that it means we don't know how to debug issues ourselves or use pre-existing docs is insulting and farcical. I'm perfectly capable of using other resources—that doesn't change the fact that a quick Google is often the fastest way to reference something I forgot.
I'd never hire someone who saw using Stack Overflow (when it made sense) as a flaw.
I think for certain roles it absolutely is a requirement. If a web or backend software developer insisted that they refused to use Stack Overflow I don't think they'd make a good employee. It sounds like they're letting ideological hangups and tradition override practicality.
He assumed that Stack Overflow users don't have the experience to read books or debug themselves, which from the other replies is obviously incorrect and naive.
Software development/engineering is still a young industry, most developer jobs really came about with the internet in the mid-90s on up and increasing every year. So the numbers will skew younger at least for a few decades.
The bulk of people that have been coding since jr/high school and college are around or in their 40s now. C++ was invented in mid 80s for instance and not really fully in taking over desktop apps for a few years, combined with the internet then browsers, from that everything today + mobile which is another growth area. People were pushed into management because there were minimal veterans in the early 90s/00s, and you could be a senior coder within a few years.
The ages will eventually skew up especially with GenY/Millenials being greater in numbers than Gen X who were really the first generation to fully have internet jr/high school/college on, and many went into development, older than that some switched but most had their path in life already going. Ages will skew older with the next couple generations as they age. When radio started everyone was young in it as well for many of the same reasons.
If I had to have someone operate and suture a ruptured artery inside me after a terrible accident or something - I would rather a human doctor be able to do it. Also, a human being would be better at doing that in a non clinical environment (such as road side assistance at a vehicle accident scene etc.).
Also, as the son of a respected doctor, I see other aspect of 'doctoring' that extend to far beyond technical or diagnostic skills. Hardly a day went by when we were out in public when a former patient of his would approach us and thank him for safely delivering their child or saving their lives. I don't think that an email thanking AutoDocBot3000 v2.33 for diagnosis & drug dispensation # 288374 would have the same impact.
> If doctors are replaced it's because medical care has improved beyond their capabilities.
Don't bet on it. Software is much cheaper, so when cost of resulting mistakes + cost of software < cost of doctors and their mistakes, some hospitals will do the switch.
I like the thread here, but I'd like to point out that we shouldn't limit our check on ageism to the people who are "still coding".
If we want people in dead-end jobs and failing industries to have a chance to move forward in new ways, we need to willing to accept qualified "junior" engineers of all ages and backgrounds.
I have seen this sort of ageism in the interview process and it's tricky to constructively correct people in having different standards for 22 year-olds than they have for 32, 42, or 52 year-olds.
I'm 52, started writing code professionally in 1985. Started my career on 68K assembler. In the 90's I was a Windows SDK developer (then COM/ATL, etc.), In 1999 started a company but chose Linux and embraced FOSS and built a company on a Lamp stack (sold it in 2014).
The only thing that can hurt you in this industry is that you stop learning and stop growing. I tell my employees to always learn something new every month. Pick something cool, learn it. This industry changes too fast to stick in one area of technology. Two years ago, nobody was talking about Node.js as being "important", now you can't see a company or startup not looking for Node/MEAN stack developers -- that's how quick this industry moves.
But hey. I am old... I use Emacs (still), but have moved to Visual Code on my Mac (with Emacs bindings of course...). I do most of my work in the ZSH, but use Bullet Train and Powerline Shell... So I embrace "new" and am open to things that make it easier and better.
Personally? How do I keep pace being the old man? I take 3-6 months off and learn a new technology. What I mean about "learn" is that I actually build an app that's useful or used by customers (people). I don't just play with something, I learn it to become productive and then move to the next thing...
Right now, I've just got to the point of feeling "productive" in Elixir. Which I think is going to be the "game changer" on the full stack side and love functional programming (after being an OO guy for what, 25 years!?)... Elixir is my new love and haven't been this excited about a stack in a long time.
Learn, learn, learn... write code, keep your brain active. Age means nothing in this field other than when you show up for an interview and the rest of the employees are wearing Skinny Jeans and you've got Dockers on.
> The only thing that can hurt you in this industry is that you stop learning and stop growing. I tell my employees to always learn something new every month.
I am lucky enough to work in an environment where we work with many technologies in a rapidly-evolving area, and most of us have multiple responsibilities, so I can say without fear of hyperbole that, on average, I learn something new every day, be it how to find the signing cert needed to verify an ADFS OAuth2 JWT, or configure Gitlab EE correctly to authenticate with an LDAP server. I think I would simply croak if I had to do a conventional job.
When I say "take 3-6 months off", I mean from distractions of life around you. Most people working, it's not reasonable to take that much time off. What I mean is, focus for 3-6 months on something new, spend 3-4 hours a day -- even if you have to box out some time at night to learning something. Often times over my life, I've told my wife, "OK, I'm going into hunker down mode..." which she new that I wasn't going to be counting on me for "free time" all that much for the next several months because I'll be in a mode of heads-down and learning. Like going to the gym or class, you need to carve out time and make time (weekends, nights, etc.). Make the time mandatory in your day. If you DO have the luxury of taking 30 days off (I know people who do have that), use that time for possibly going to an on-site bootcamp. Another thing I've done is take that 3-6 months and attend a class or bootcamp. With Bootcamp's becoming so much the rage these days, you can go 2 or 3 nights a week and learn a technology in 3 months. It's awesome.
Snap! - your programming life (and age and timeframes) matches mine almost to a 'T'.
Totally agree about constantly learning new stuff, but also doing it the right way (i.e. real world apps rather than another 'Hello World' or simple blog post/commenting app).
Excellent! Here's to gray hair Docker wearing developers!
Until you've built a useful application on the stack, something that can be utilized for something, you've not spent enough valuable time to be productive on it... just something I learned a long time ago and stuck with.
I second that. Things began to get much funnier when I started learning additional languages beyond the first one (:Java, that I still like very much).
I'm 50 and still writing new code and launching new apps. In fact, I've probably release more apps in the last 5 years that I did in my previous 25+ years of programming (started when I was about 18).
While I concur that I am not as energetic as I used to be in my 20's and 30's - i.e. I cannot do non stop 12 hour code marathons etc., I think my code these days is a lot more disciplined and well thought out, and better organised.
I will happily spend time to look at the latest and greatest bleeding edge technology or framework, but when it comes time to write 'money code', I usually fall back on tech that has been around for 5+ years.
My passion for coding has not diminished - I am still excited every time I sit down at the keyboard. As long as I feel that, I will keep coding or working around software.
Lead developer on VMS, NT and Azure. Working on the core of XBox up to couple of years ago (still is?).
I won't say what age I am when the article seems to think that 45 is relatively old, but Dave Cutler shows that there's no excuses. If you're good, you're good, young or old.
What will Microsoft do without him? All of Cutlers former team members that worked on WinNT series kernel retired long ago. Less and less devs understand the internals and the Win32 userland. You see new bolted on frameworks, and new apps instead of extending older one. Newer devs want to create new things instead of msintaining decade old code. No one wants to pay QA... the user is now the alpha/beta tester.
Late 20s? I've seen title structures where the first promotion is to "senior" and that is often granted ~18 months into working. It's early enough that it can be ambiguous as to whether it means your working title or your year in college.
I saw someone get promoted to a "senior" for rolling his own logging framework. And then starts arguing with me about how long functionality will take when he clearly hasn't got a scooby of what's involved (me 2 months, him 2 days, 2 weeks later and he's still trying to pick apart how the code even works).
At a previous gig, I had to explain to my CTO what JSON was and why it was better than the ad-hoc serialization format he made up where every field was delimited by multiple dollar signs. I interned there, and I was probably twice as old as everyone else.
Oh, and that JSON was supported natively in PHP. The language they were using.
You can blame job ads for that. Since nobody wants to be called 'junior' there are job ads that are clearly targeted at fresh-out-of-school people who somehow are also senior developers.
I've seen some amazing young coders that definitely were worthy of that title but they were the exception, not the rule. The tell tale is if the salary that goes with the job is one that you could support a family and a mortgage on. If that's not the case then the position is 'junior'.
Agree. Especially with startups. I have to say, I'd been to a bunch of local Meetups and have bent the age curve at them. Looking around going, "wow, these could all be my kids...". And most of them are good programmers but terrible at decision making.
My only problem with "today's young programmer" is really the lack of experience to know enough to "see this movie before". I've seen a lot of mistakes in companies that I've been at and worked at only to go "Umm... yeah, don't do that..." -- only to see them make the mistake because they haven't had enough time or experience it. It's like watching my kids touch the hot stove for the first time.
But the industry loves "young". Don't they?
When funding comes for a startup, it appears VC's are willing to dump the money on the 24 year old with a pitch deck that excites them... it's amazing.
Being young has advantages when starting a company. Naivety reduces the barriers to entry, as does having nothing to lose. I've never founded a company, but I was employee #1 once, and I couldn't do that at this point in my life.
I expect one contributing factor to this statistic is the proliferation of software development over the past decade. As millennials get older, so too will this generation of coders and hackers. The mid-twenties image "software engineer" conjures, will keep getting older. I'm fascinated to see how this will make software engineering a less sexy job / will change tech culture among deveopers
Keep in mind that the industry is aging as a whole (and hopefully maturing in the process). So if you ask the question 10 years later, there will be a lot more developers in the 40+, 50+, 60+ buckets than today.
"The median U.S. worker is 42. However, StackOverflow’s survey on age shows that there are just about 13% of developers after 40. Where are the others?"
I think most of this is due to the simple fact that software development has been a steadily growing profession for decades. Thus, the "population pyramid" of software engineers will very much be a pyramid and older developers will be proportionally scarce. If you want to make meaningful predictions about your personal likelihood of staying in software development beyond a certain age, you'd need to slice the numbers differently.
I believe that once the number of software engineers stabilizes, the age distribution will become more similar to other fields. Some will leave the field during their career due to changes of interest or due to life throwing them curveballs. But a lot will stay.
I'm 43, BTW. Still find software development and tech enjoyable.
What about Linus Torvalds?
Born: Linus Benedict Torvalds, December 28, 1969 (age 47), Helsinki, Finland
I guess he's still coding, right? Does it count?
Fabrice Bellward is 45, John Carmack is 46. Michael Abrash is probably in his mid-50's. Rob Pike, Guido Von Rossum, and Larry Wall are all still programming and they're in their 60's.
I think it's safe to say you won't magically lose your programming ability as you get older.
But you do lose the patience to keep using what amounts to the reinvention of the wheel and having the same problems over and over, and you do lose much of your free time to other responsibilities, which manifests itself in not having the time to play with every new tech under the sun.
I agree, but I think you lose that patience for reinvention in about year 6, not year 21. So, dealing with it becomes part of being a software developer. If you can't, you won't get to year 7.
And yes, there are more responsibilities with age, which means you also have to improve your time management. But, that's not unique to software developers. Waiting to see how new technology evolves before jumping on the band wagon is a good time management strategy for software developers.
Lot's of scientists and engineers and physicians are still doing what they know best. These kinds of knowledge and skills do not go away with age, and since practitioners of these arts are constantly learning new things, and looking for better solutions to problems, people in these fields often work until the very day that death catches up to them.
Programmers tend to be just like these other STEM like professions. Although with age we tend also to broaden our horizons a bit, perhaps into genomics or massively scalable systems or new approaches to cyber security.
“Over 30 years, I had to relearn almost everything about every 4 years more or less. I work with a team of six developers from ages 48 to 56. All of us have totally retrained our skills from 3 to 8 times.” . I have been doing embedded coding for years, which does not need train myself every four years, but still, keep learning is the key, age plays its role, but not as important as keeping learning.
57, I build and maintain 911 (911, E911, V911), Telematics, Alarm, PERS and custom SIP programming systems. On any given day my job is a software developer, dba, systems analyst, process analyst and data analyst, sysadmin. Not mention fire putter outer and consult with outside companies to best implement their requirements.
Most of my developer colleagues are over 40. No one thinks less of them for it.
On the contrary, an experienced developer is someone who has at least a good fifteen years under their belt. That usually mean "over 40". That experience manifests in ways such as not reinventing the wheel (a favorite, unintentional pass-time for the young and inexperienced).
This whole topic is so interesting to me. Software programming is actually, in reality, a mind numbing process involving extremely repetitive actions. Thanks to Hollywood and the fact that technology is transforming our world (not programmers... technology) the myth of the programmer as an intellect has flourished. That is true for most programmers; there are brilliant programmer of all ages who make the tools the rest use, and that's another topic altogether.
The reality is that young programmers are popular not because they're brilliant, but because they are more willing to engage in repetitive tasks for long hours. The idea that older people don't have the intellectual chops is total BS; it's rather that as people get older they lose interest in unrewarding endlessly repetitive tasks. That is to say, they become more intelligent about how they are going to spend their time and their life.
I am early 40s and have been coding professionally for 25 years; I will never stop doing it as I like it and it keeps me up to date with my colleagues/employees so I can help them and support them where needed. I spend a lot less time worrying about frameworks, programming languages etc then I used to. I practically deliver things my companies need. In my spare time I program as well; working on formal verification, development tools & games. For me it is just creating something from nothing that drew me into programming the around 34 years ago and I have not found anything that works that powerful on me.
I notice, with every year passing, that I need less and less time actually behind my computer and typing to write more and better software. Which is great as I don't like the typing part all too much :)
52 here and code everyday, some for work, some for personal development, but most because I enjoy it. I am also manage a security engineering team for a living. I've been coding since I was 12ish. Most of what I code in now is Python for work and Swift and Java for mobile development, which I find a hell of a lot of fun. Mostly making tutor apps for my kids studies.
What I find interesting is that when I walk into a meeting with younger developers they immediately assume I only know cobol or rpg and not the various stacks I work with. Once we start working with them on securing their code they realize what experience brings to the table. It's hard to believe that there are still some programmers out there that don't know what cross site scripting is, or how to prevent SQL injection etc.
Am I in the top 13% at Stackoverflow? I had no idea, but I'm going to use this as a new source of pride, just because I can.
I don't consider 40+ very old for a programmer. My father was 65 when he retired from professional programming, and at first continued working on an open source project (though that now seems to have stopped). I've always seen plenty of older programmers. Only at the few startups where I worked was I one of the oldest programmers, but even there the demographics get more balanced as the company grows.
The weird stories about Silicon Valley's love for inexperienced programmers where 30 is apparently old, sound weird and alien to me. I get better as I get older and more experienced.
I'm reluctant to weight in as I'm only 36 and well not terribly impressive. However as the owner of a company I must say programming is so much more relaxing than dealing with people... well mainly just people external of our company and family.
There is something extremely cathartic about programming. I'm not sure I can ever fully describe it. All I know is when I have to talk to a customer or partner I occasionally think... god I wish I was programming right now... even in Perl or PHP... anything.
The irony is I actively seek conversation as I always want to improve our company but about 20 minutes in and I start feeling uncomfortable.
The thought of never programming again is a scary thought to me.
I'm 57 and I "Can't Stop Coding" as I'm still having too much fun. Whenever I stop having fun... I change programming jobs. I wrote about this in a blog post (http://corgibytes.com/blog/2016/12/06/getting-old-er-in-tech...) that was widely read.
I will say, however, that I have seen a lot of developers become obsolete mostly because they stayed with the same company (and programming language) for too long or ignored opportunities to stay abreast of technology.
I'm 57 and I "Can't Stop Coding" as I'm still having too much fun. Whenever I stop having fun... I change programming jobs. I wrote about this in a blog post (http://corgibytes.com/blog/2016/12/06/getting-old-er-in-tech...) that was widely read.
I will say, however, that I have seen a lot of developers become obsolete mostly because they stayed with the same company (and programming language) for too long or ignored opportunities to stay abreast of technology.
I'm 51, still codeing almost every day and I use SO a lot. I used to contribute more, when it started, but lately use it more as a reference.
Didn't know about the survey - would have probably filled it out, actually.
I feel it's pretty easy to keep up with new technologies when necessary, since I don't have to relearn the basics and almost always have a reference point as in "oh X is similar to what we used to call Y in Z".
One huge shift for me is distribution - as the browser is now almost capable as a general UI it's easier to not worry about OSes, installers, versioning, etc. This is true even for people who primarily don't work on web apps.
I have to wonder how well the SO survey reflects the overall dev population. I could imagine, for example, more experienced devs spending less time on SO, or being less likely to respond to a surveys in general.
60 in 2017 => 20 in 1977. How many programming jobs were there in 1977? Plenty, sure, but not to the extent we see today. Is it really suprising that a brand-new industry is also full of young people?
creak. 69 here, still employed and coding etc, started in 1967, spent too many years having to make it up as I went along to specialize. If anything that specialty might be embedded systems, but not only. I would definitely guess my demographic is small. I find SO sometimes useful where my Google-fu fails me, but every so often I also get to ask the developer of the language/whatever directly instead. We're all about that age now, and it's a small and shrinking community.
For anybody who attending a community college or University for technical courses, you would have realized that overwhelming majority of your Professors (aka computer scientists) are 40+ with a large chunk being 55+
I think human beings have infinite capacity to grow intelligent - that is until our bodies start shutting down (e.g. Alzheimer) but nobody knows at what age that happens (it can happen when a person is in their 20s or 80s or may never happen until one day the person simply stops breathing).
50 and coding. There's nothing more satisfactory that carefully crafted code. Or maybe just releasing something and mostly never looking back because it. just. works.
41. I learned programming when I was 8 (basic on a C64) and I have as much fun programming today as I've ever had. Besides, there's no doubt I'm a better programmer today than I was 5 or 10 years ago and I keep learning new things.
Actually, I'm more worried about ageism than about the decline of my abilities. I work in academia, but I wonder if I could get a software engineer position if I wanted to.
Logical analysis of a problem and its implementation into a computer system is a "high skill". There are programmers who can do the job and then there are people who actually innately think logically.
I'm betting the older devs (like myself) are the ones who have had that innate logic skill since they were born.
Putting aside the question of what reality the 13% statistic in this survey might be representative of... When one looks at how much this industry has grown since today's 40 year-olds entered the job market, my surprise at the 13% number is at how high it is, not how low.
I'm 38 and have coded ~30 years, professionally for half that. That's 15 years into a career of perhaps 45 years. A third! I can't believe I'm even worrying about being "old" in the business.
I started coding after 40, as I needed the skill set to do my other job properly (molecular biologist). Love it, with the added advantages my job is more secure and higher paying.
49, write code every day. The whole SO thing mistifies me. I really think the survey skews, because "graybeards", don't waste time filling out surveys and they know how to RTFM to get answers.
I came across a graybeard in an interview recently who refused to take a coding challenge and cited his experience instead. He did not advance through the interview process.
I'm a graybeard so far be it from me to pass judgement. If you're applying for $300k/yr architect level job, then you should be good at every level of software development, including writing it.
Corporate culture embraces the notion of management as a profession. I think programming would benefit greatly from more of a tradecraft model, where leadership is provided by the master practitioner rather than the professional manager. In the alternate universe that's how we do it. The bottom line productivity boost is awesome. I don't know if it scales, but I don't care to scale.
-- 63-year-old full-stack web and machine learning programmer...living the dream