Software Developers after 40, 50 and 60 Who're Still Coding
belitsoft.com
belitsoft.com
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
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.
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.
Just be willing to learn from those who are more proficient than you, even if they are younger.
You'll soon catch up.
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.
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'.
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.
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.
Times change and so does language, true to any old fart out there, and the old farts to be.
I thought it was the other way around. With ML taking a more statistical approach to traditional AI problems.
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 like that - may I use it?
-- 58 year old full-attack dev
so everyone else just hires older people, but it isn't sexy and marketable to the impressionable technology crowd.
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.
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 :)
- 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.
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.
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 ...
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.
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.
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.
* Writing less code
* Writing maintainable code
* Re-using existing code (requires reading existing code)
* Know how APIs should be written
* Knowing how to properly map associations
* Know when or when not to use another library
* 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
~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.
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.
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.
- I think it will take a week, but this part looks a bit complex, so we may have delays.
- Or, I did something similar last month, so I am quite sure that will take 3 days.
A good PM will know how to deal with this information and what to expect.
If I don't trust the PM, I just add massive paddings.
You know in your mind it will take you 3 days
You give me, your PM, an estimate of 2 weeks
I report up the chain that it will take a month
When it's all said and done, you end up getting it done in a month by the skin of your teeth :-)
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.
I draw them the Cone of Uncertainty (http://www.construx.com/Thought_Leadership/Books/The_Cone_of...).
Alternatively, they could accept new processes that make sure requirements are clearly written and include acceptance criteria.
People are just trying to make decisions about spending money, keeping clients informed, etc.
There are some research and moon shot type exceptions. But, for the most part, estimates are a necessary evil.
can you justify the 2-3x difference between you and a guy who was been coding for 5-7 years ?
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.
First 5 years = ridiculous year over year growth, including getting raises without having to change jobs!
Next 5 years = slow growth, generally have to change jobs in order to get a raise.
Next 5 years = flatline, cost of living increases only, IF THAT.
I don't know any other professional field that plateaus this quickly.
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.
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.
Also, knowing why the points in your list are significant and advantageous.
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?
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.
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 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.
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 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?
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.
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.
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.
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.
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.
I'm thinking of dyeing hair before interviews when I face the same problem.
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.
Then Apple II, IBM PC, IBM PC-XT, IBM-AT...
First hard drive for IBM PC was $1000 for 10MB.
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!
Edit: added details
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.
me, 50 yo, still coding embedded sw..
Yep, that be me:
http://www.atariarchives.org/deli/cottage_computer_programmi...
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..
me, 51yo, system administrator.
Grew up marvelling at Apple Writer knowing that a guy wrote it in a cabin in the woods.
Sir, you were (and still are) a great inspiration !
Age 50 and writing C# .NET Core web services.
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.
That's what I do, anyway. (I'm 46)
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. ;)
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/
I use StackOverflow practically all the time. I always think to myself, "yep, this (Wikipedia, YouTube and... yah HN) is what the internet is for".
But maybe I'm just too young. (I'm 47 ;) )
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.
MS provided lots of example code and docs.
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'm not saying that either of these is correct, but they could be plausible explanations.
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 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.
The next problem is seen at this URL
https://stackoverflow.com/questions/14966014/whats-the-best-...
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.
Every thread there is some old guy going on about how stupid young people are.
The meta observation is inexperience can lead to not understanding critique. Which again is not even a "youth" thing.
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.
I would say that during the 8-bit computer era having a home computer was not that odd (well, excluding the Apple II because that was expensive).
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.
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.
Besides, for some of the stuff some of us do, the technology isn't on Stack overflow.
I'd theorize that perhaps older developers don't put as much stock in participating in those sorts of surveys.
No, he doesn't. You do though.
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.
(Note: there are more useful jobs: doctor, nurse, farmer).
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.
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.
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.
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.
I like to call it "Dad coding".
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.
-- 58 year old attack dev
Did you take a sabbatical? Is your current company ok with this? What did you work on?
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).
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.
39 and I consider myself just getting started.
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.
One of many reasons I bailed from that gig asap.
Oh, and that JSON was supported natively in PHP. The language they were using.
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'.
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.
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.
I think it's safe to say you won't magically lose your programming ability as you get older.
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.
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.
I'm 56 now. I'm just going to go until I can't do it any more; 75 would be great. Writing software and working with hardware is pretty awesome.
Consider how fortunate we are, who have found successful professions that we enjoy -- many people don't get that opportunity.
But I'd rather be out riding my motorcycle.
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).
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 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 :)
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.
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.
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.
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 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).
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.
Anyone who is willing to learn and accept new technologies, the above quote holds true.
I'm betting the older devs (like myself) are the ones who have had that innate logic skill since they were born.
Everyone else moved on to management.
Just a theory.
Does a driver stop driving at age 40? Or a Dr. stop being a Dr.?
I can identify bad patterns both in code and designs as well as teams that escape many younger engineers and managers.
By the way, I was at an Azure Bootcamp on Saturday (great event!) and there was a 70+ year old there with his laptop doing the labs.
Programming and exercise are two of the three best ways to stay young.
What in your opinion is the third one? (Starting curious?).
It's not a young man's game.
Don't think I'll be stopping any time soon.
I think he made the right choice there.