Slashdot Mirror
Study Shows Programmers Get Better With Age
mikejuk writes "It's a prejudice the young and old both share, but with opposite conclusions, of course. Young is best or old is best — most have an opinion. Now we have some interesting statistics ingeniously gathered and processed by Peter Knego, 'big data' style, that 'proves' older is better when it comes to programming, at least!"
Claims of agism always seemed funny to me in the context of programming (or really most industries).
Someone with 25 years experience is far more employable than someone with 5 years because they... have more experience?
It's not like the "olden days" where how many years of service you'd get out of someone mattered. Now people are lucky if they have the same job for 5 years. Manpower requirements fluctuate so much in today's industry that the days of "get a job out of school and stay there till you retire" are long gone.
And there is value in young blood as well, but you really need a mixture of people out of university with new ideas and people with experience to make them work (or who understand why they won't). Even if a person loses touch with current technologies, it is worth having people around who have seen a lot of shit fail and know the warning signs.
This of course assumes we arn't talking about someone who learns to program at the age of 40 or something.. then all bets are off I guess.
A guy where I work is retiring in two months. We have known this for like a year and we are _still_ scrambling to get all the info out of his head (we maintain some very old systems... and he was around when they were _designed_). If I retired tomorrow no one would give a shit. "Just hire another c/c++/java guy with a little asm". Obviously this more more related to knowledge than skill.. but still.. that's value!
Also.. interesting (yet pretty thin) way of getting the stats! And I can't be the only one who was pleasantly surprised not to find some huge 50 page report at the pointy end of that link.
Unfortunately the data might just prove that good programmers continue to older age while their less skilled kin get promoted out of it. I also hold the opinion that older programmers who were typically maths graduates are far more skilled than the younger "computer science" graduates (I include myself in the latter group).
Is it age or experience that makes the difference? I am going with the latter.
Assuming it's someone not stuck in 1972 and only knows cobol
People are only realizing this now, having been burned time and time again by young programmers who don't have a fucking clue what they're doing.
Yes, most of them are proponents of using Ruby and Ruby on Rails. In fact, those are the only tools in their toolbox. The solution to every problem is a web app. Then again, that's exactly what we should expect from 18-year-olds who have no university-level training, and merely picked up their "craft" by reading blog posts.
Well, it turns out that writing anything larger than a blog using Ruby and Rails just isn't a good idea. It's not maintainable, the performance is absolutely shitty, and the product itself doesn't provide any value. Unfortunately, many customers didn't find that out until well after these Rubyists had made a mess of the situation.
These days, it's only safe to trust developers who know languages like C or C++. Even if you're having them use Java, C#, Python or even Perl, at least they have a wide base of knowledge that lets them make sensible and correct decisions.
I believe that. The older programmers that I know have a better sence of what is neccessary, what works, and what doesn't need to be done. The young guys out code them by number of lines, the old coders write much more code that survies for years and doesn't need to be rewritten six monthes from now.
I like to think you need a mixture of the extremes.
You need the "fresh outa university" types who want to re-write everything in executable UML and shift to SCRUM. That's where a lot of your new ideas come from.
You also need the guy's with 25 years experience seeing this shit go wrong to keep them in check.
You can't change your development paradigm with every graduating class.. and you need the old-timers to keep things moving in the right direction. That said, I wouldn't want to have a whole company of them. We'd still be using COBOL.
Sportsmen and women, almost universally.
"Bad programmers get fired, and do not continue to have reputations as programmers once they are taxi drivers 20 years later". Programmers who don't get fired, after years and years, have more respect. The same curve would show up with race car drivers and bagel bakers. People in their 20s outnumber other new applicants, and as someone who hires a lot of people, most applicants are not qualified to begin with. I'm a budding codger, but sorry guys, this is data trickery.
Gently reply
I've been in the industry for over 30 years now. I've witnessed first-hand the transition from COBOL-based systems from the 1960s and 1970s, to C-based systems of the 1970s, to C++ applications of the 1980s, to Java systems of the 1990s, to C# apps of the 2000s, to today's web apps.
Users today are worse off than they've ever been. Web apps, especially those hosted externally from an organization, are among the most inefficient, ineffective software systems ever created.
Ask any long-time computer/software user in a given organization how software has helped their productivity. They will immediately tell you that the software they had to use was much better when it was actual native applications, rather than the web apps they have to use today.
Native apps are always better. That's why smart people still use real email clients, rather than GMail and other webmail systems.
You can always add network connectivity to a native app. You can't add quality to a web app.
Where experience counts is in the "soft" areas: recognising approaches that will or will not work, as they have or haven't in the past. Knowing where your limits are and knowing being able to tell when others need help (even if they don't have the experience, or are too vain to know or ask, themselves). And knowing whether an unknown problem will take a couple of days to solve or a couple of years.
The problem with experience is that those who have it frequently end up working for those who don't, but who display the "can do" attitude that attracts lots of employers - as opposed to the "that'll never work" which can be the voice of experience, itself. As there's nobody as unswervingly certain as the truly ignorant, the experienced people have learned not to try to "advise" these individuals as they will only resent it, feel threatened by it and become even more steadfast in their refusal to accept advice.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
To prove what everyone with more than two neurons already knew. Thirty years ago.
Well, that seems to exclude HR departments. But then, we already knew that.
Quidnam Latine loqui modo coepi?
I actually think web apps are a good idea. The problem is in their execution.
Specifically the problem is that while web apps are becoming popular for "real applications" .. they are still being developed in a style suitable for your personal blog.
Which is where I think the mixing of experience with new ideas needs to come into play. You need old experienced guys getting young "web types" to go through proper program design, development and testing. You also need web technologies to evolve from their "copy+paste from the web and modify as needed" state into something designed for real work.
You also need the guy's with 25 years experience seeing this shit go wrong to keep them in check.
Yes, but you need the right sort of guy with 25 years of experience. You don't want the guy who says "we tried that: it didn't work." You want the guy who, as somebody above said, says "This is why it didn't work last time. Can we find a way of dealing with that this time?" The other thing the right guy with 25 years experience might be able to do is spot connections: "You want to do that? Hmm, that seems to tie in with this thing I worked on 15 years ago. Maybe some of the ideas from that will help."
Quidnam Latine loqui modo coepi?
I think older programmers might be more adaptable than you think. The more languages I've learned (at least to a basic level) the faster I pick up new ones because I recognize stuff I've seen before and only have to pick up the deltas.
Quidnam Latine loqui modo coepi?
I look at code I wrote a few months ago, and I cringe. I look at code I wrote years ago, and I feel like inventing a time machine just so I can slap past-me in the face for being so stupid.
I mean, seriously, why did I use #DEFINES so much for constant variables? And goto... I still have nightmares about some of my older code. And I'm sure that 2 years from now I'll look back at the code I wrote now and feel just as ashamed.
Programming skills don't really age. Some of my best code styles have come from looking back at ancient stuff - LISP in particular, but I have style quirks I picked up from almost every language I know. Sure, I write everything in more-or-less modern languages (C++ is still modern, right?), but that's just syntax. If you know the heart of programming, you can only get better as time goes on.
That neatly describes new, young, callow graduates coming into their first job. It doesn't describe many people over 35 with family commitments, a good network of professional contacts and an impressive array of successes under their belts. Hence, companies are not very likely to rate "experience" highly as it tends to make employees who will question decisions, undermine authority with "suggestions", know what their employment record is worth and have developed the ability to promote their skills.
Never mind that experienced people can produce better results. The quality of their product is ultimately defined by the quality of the design decisions - good implementations don't matter if the underlying basis of the product is rocky - either from a technical point of view or that it simply doesn't address any needs that would make it sell profitably. Companies would argue that it's better to have fast workers, doing 60 hour weeks with no time off and get a shaky design out the door quickly, since then the failure comes to light sooner. That the young workers also get paid a lot less helps too as it makes the failures even cheaper - though it does make them a lot more probable, too.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
The "study" that doesn't deserve to be called one claims that people who write more answers and ask fewer questions on SO are better programmers. That is as dumb as saying that business consultants are better CEOs or football trainers are better football players... As far as I am concerned, I am 38 now and I'd say that I've become more experienced and much lazier, but I wouldn't pay myself a higher salary for a programming job than I'd have for the younger me at 25. Among other things, because I could spend 20 hours in a row trying to solve a particular problem back then, i.e. what I lacked in experience, I more than made up for with persistence and enthusiasm.
"I love my job, but I hate talking to people like you" (Freddie Mercury)
"Nuff said.
No one ever had to evacuate a city because the solar panels broke!
Outlook is not the only native email client, you know.
...our lawns are less cluttered with errant youngsters. Gives us space to think more clearly.
It must have been something you assimilated. . . .
Another factor is that with increased experience you don't do the same mistakes again.
A young programmer may be very good and specialized in a detail making the most of a single building block while an old programmer also has the ability to break down a problem better and get it structured. And an old programmer has gained the experience that tells him where it is important to focus on problems and where it's less important. This will be extra important when you do multi-threading and concurrent access to data. It's easy to screw up those parts - especially if you are inexperienced. A young programmer can get something that works perfect as long as it runs as a single task but when there is concurrency the whole world gets into a brain hemorrhage. An experienced programmer can figure out ways around problems like that and still allow for a solution with good performance - sometimes with simple "ugly" tweaks that ensures that concurrency won't occur frequently. Those tweaks may mean that the system that should have been perfectly symmetrical in distribution of load isn't in reality but it's not visible unless you know what to look for.
An example analogy would be a motorway scenario where you have four lanes of traffic. The "ideal" scenario would have been to spread traffic on all four lanes and allow lane changes whenever necessary if one lane gets 'full'. But a lane change means interaction between lanes and can slow down the overall traffic. If traffic was locked to a single lane then the overall speed might be higher since a 110mph lane won't get interference from a 25mph lane.
Or as a system I have been working on - the previous generation had 4 threads sending commands and expecting responses from several devices (let's say 40 devices). These threads were always running, and commands for a specific device could show up in any thread. As soon as one device got "sick" and didn't answer or was slow in response this affected commands to all the other devices. A revised way of doing it was to start a device dedicated thread instead for each of the devices that were of interest. Since not all devices were of interest all the time threads could die after a time and be started when needed. This way a single malfunctioning device wouldn't have an impact on all the other devices.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Yeah, but then you still have the web app that kicks off the wget. It's web apps all the way down!
JOIN US FOR PONG!
It's been my experience that experience does help quite a bit. Those who have been there and done that are able to do that again much better. I know I've learned a lot since I wrote my first program over 30 years ago. But that's the key. I keep learning. I keep exposing myself to new technology and new methods of accomplishing complex tasks. Trouble is, I've found that I tend to be the exception, rather than the rule.
The biggest trap experienced programmers fall into is to get in a rut. It worked that way once so they see no reason to ever think about doing anything else any other way. When change eventually finds them, i.e. when their 30 year old processor, language, and development environment is no longer supported, they have an incredibly difficult time adapting to new technology. I've seen more than once the troubles that come when the old crew refuses to evolve. It can get ugly.
Kids are great at taking up the newest technology and learning the new ways of doing things. Trouble is, they don't have the experience to build upon so they often don't understand how yet to really plan and execute anything on a scale beyond a college class assignment. So they're great for accepting the new ideas on how to do things but you really need some experience to get things done.
I've had the best luck working with people who have a broad range of experience working on several different projects. They've been exposed to different ways of doing different things. They are usually more open to trying to find the best solution rather than stick with one way of solving everything. If I see someone's resume and they've worked at the same place doing the same thing for decades, I'm usually more reluctant to hire them than I am a college grad. I know I'll have to teach both of them but the college grad is usually more open to learning than the dinosaur who's looking for a new job because he has to rather than wanting to.
Stack Overflow reputation is cumulative. This means that if two people are providing answers of the same quality and at the same rate over time, the folks who have been there longest will have higher reputations, and that the higher reputation will reflect only tenure. Not any kind of quality.
If you want to look at quality, you should be looking at a metric that is something like (total reputation / number of months active). Even this is imperfect of course, since if people take a hiatus or something that will present the appearance of worse quality using this metric.
I was going to say that this fatal flaw invalidated the conclusions because the correlation between reputation and age just reflected the older people being around longer. The problem with that is that Stack Overflow opened in 2008. That's not enough time to explain a linear trend that tracks from age 16 to nearly age 50, but the final conclusion "So, senior coders earn their higher reputation by providing more answers, not by having answers of (significantly) higher quality." should still be re-examined with tenure-controlled analysis to try and see whether older aged members have been members longer.
The Southern Baptist Convention has creationism. On Slashdot, we have porn.
What age really brought me is a very realistic way of evaluating things in the respect of "how can that be maintained, by somebody who is not me?".
Very insightful but think of the corollary: "How can this be maintained by someone who can't REMEMBER the details anymore?"
Way too often You have to maintain Your own shit so You might as well keep the smell down. Making You code obvious is a Big Win and often a sign of deeper understanding although few seems to understand it. Another lesson from a graybeard.
TCAP-Abort
John Carmack managed to kickstart a genre with an 'embarrassing' crappy VGA raycaster.
and look where we are now!
ACID is a false god. Isolation is, in fact, theoretically impossible. In almost any problem domain, there will be situations where the permutation group of the data is not solvable. This is pretty much why relational wins over trees. Having said that, in most situations, isolation is attainable or something close-enough to it is attainable.
Any guest worker system is indistinguishable from indentured servitude.
I'm 50 next year. My programming ability gets better and better all the time, and has done since I started in 1980. When I look back at stuff I wrote in the 80s, it's cringe-worthy and an embarrassment. I'll probably say the same about the stuff I'm doing now when I'm 70.
What has changed for the worse though is my energy. Back then I could code like a demon, then go out and party half the night and carry on next day without feeling any the worse. Of course, I was pouring my energy into a lot of bad code, but it often ended up working by brute force. Now I find it hard to stare at the screen for long periods at a time and overall my work rate is much lower - but its effectiveness is much higher.
which is a little different from being the most modern coder. I code in .net mostly, either vb or C#. After a while, you start seeing repetitive problems (It sounds cooler if you call them "patterns" even though the term adds almost nothing semantically). After a while, you can write a class with a function to append an array to an array either horizontally or vertically in your sleep.
But you don't. You have them all pre-written after a while, which is why it seems to management that you're not working as hard. You just solve the problem and go home without noise or drama.
Please do not read this sig. Thank you.
After 20+ years of programming, I definitely feel that I program better now; especially with regard to making the code more flexible to change and better algorithm design based on years of trial and error with diff approaches.
However, I have to admit that I've gotten slower at reading other people's code. My eyes just are not as good. They are not blurry; it's just that they don't move as fast, take longer to focus into position, and I can't quite read (absorb) as fast. Can I get a bionic implant?
So, age is a trade-off.
Table-ized A.I.
I agreed with you right up until you started shitting all over Ruby on Rails. Yeah, I don't like Ruby on Rails. I don't like cream cheese either, but I'm not going to twist the topic into a discussion about cream cheese. Yes, young programmers who don't know anything are stupid and annoying, I agree. I also agree that stupid and annoying programmers propose a web app for everything. One of my teachers, a ten year+ programmer, recommended doing a web app for everything, and he was in his late 30's. The problem with those who want to create a web app for every problem isn't that the programmers are young, it's that those specific programmers are stupid, or don't want to learn anything new. It's like using a hammer to cut wood. If it's the only tool you know, you'll make it work, but the result will be fucking ugly.
Be honest. By "untainted", you mean "untainted by things like family, health care, the future, working conditions, and benefits". They're also no "tainted" by notions of what's legal and/or ethical and what's not.
People don't get "tainted" by experience, friend. In fact, brain research shows that experience makes us more flexible not less.
You are welcome on my lawn.