For kicks, I'm going to throw out a possibly odd analogy.
The length of a string determines how quickly it vibrates (assuming tension is the same). Shorter strings vibrate faster than long strings. If you're in a noisy environment and you want to make sense of all of the chaotic sounds around you, one way to do it would be to take a bunch of strings of different lengths (say a piano) and see which ones resonate more than others. The gentle ringing of those piano strings, some louder than others, tells you which frequencies are more dominant in the surrounding acoustic environment, because they cause their matching strings to resonate more.
As I get older (I'm in my forties), I feel like a lengthening string. When I was a twenty-something programmer, I could tell you how things had changed over a year or two, but trends or cycles on longer timescales than that were hidden to me. Now I know what a decade or two feels like and can see and intuitively sense cycles of that scale. At the same time, shorter trends are harder for me to pick up on now. It feels like noise or beneath my notice.
Having people of different ages in your organization is incredibly value because they all resonate at different time scales like this and help you pick up chronological patterns at frequencies you'd otherwise miss.
I am under 30. I find it very frustrating and unfair to see older programmers being displaced or misstreated because 1) I need to squeeze out every damn ounce of wisdom these people have in order to accelerate my own progress and 2) one day I'll be in their place. I want them to be treated the same way I will be treated.
I have a real life example of the five monkeys story. A company I used to work for had a pile of legacy systems in php4, mysql 5.0 and a frontend working only on IE8, no ci/cd, no tests. Almost instantly I was lead to beleive this system is a black hole that can't be saved due to the technical difficulties plus management issues. The head of IT was there for almost 20 years watching tons of developers contribute to this mess and failing to take meaningful action to address the problem. Thus he had insane clarity of all the problems, but also was pesimistic about any possitive outcome. With his experience on these systems and my determination (probably stemming from my youth) we managed to upgrade php to 5.6 (almost compatible with 7), mysql 5.5 and most of the front end could work on latest chrome in a year (+ a great deal of performance optimizations). We both left that place having layed out a solid foundation for the people who were left behind to continue this modernization endavour (which I've learned was carried on)
There is an assumption that "old" means "experienced" which is not necessarily true. There are people who transition to programming from other fields and are "old". Their value shouldn't depend on whether or not they fit the stereotype of "old timer hacker geeks". They should be judged by their skills, the same way the young ones are being judged.
I think using the "five monkeys" parable as an argument to favour the young is fallacious.
Your tale is great, and sounds like a great experience, but I don't think it's necessarily related to the age of the participants, and to me the key here is this -
"The head of IT was there for almost 20 years"
To me that reeks of stagnation. 20 years in the same place! This person hasn't exposed themselves to new ideas, cross pollination of techniques and skills etc etc. They've become ossified and cynical, and not because they're older, but because they haven't moved around. Anyone being somewhere more than a handful of years (5?) is a red flag to me, if you're looking for technical competency.
I'm glad, for his sake, that story ends with the guy moving on!
I think one of the main values of senior developers is they've seen a few cycles. If something has been tried four times before and failed there's a pretty good chance that it will fail the fifth time. But if the boss has only seen it fail once he's going to try again, then when it fails get mad at you. He will be mad because of your calling it out in advance he will feel you're undermining his authority whether or not that's your intention.
Had a friend tell me when he was a newly minted lieutenant. All the new guys were put in a competition with their platoon to build a temporary bridge across a river. While all the others called out orders he consulted the grizzled old Sarge and asked him what he recommended. He took his advice and said lets proceed. Instead of barking orders he spent time working alongside his men doing physical labor. His team not only won they set a record for that task. As a result his platoon would walk through a wall for him.
But what if there isn't an old experienced Sarge? The organization is the worse for it and I've seen it time and time again.
There is no old grizzled sarge because either the resume gets canned because it shows a university graduation date from last century, or because someone with a greying neckbeard and 40 years successful on-the-job experience can't be bothered spending a day doing pointless whiteboard exercises to prove he knows something that will never be used and is not applicable to anything but pointless whiteboard exercises.
Both are really needed, especially when there is a lot of complexity. It's no fun to work buggy code that is buggy because lots of best practices were ignored/there is too much experimental stuff there at once. There is also a need for (usually young) people who doubt existing wisdom and try impossible things to find out they suddenly work.
I’ve observed a company in London who followed a brilliant strategy with hiring old engineers and (very) junior ones.
This was a company in finance, doing not-very-interesting things. You’ve probably never heard of it. About half the devs were above 50, and the other half straight out of bootcamp, with a few people in-between.
It worked so great. The “old ones” brought a lot of maturity, practices (TDD, tests, even XP at times) and loved mentoring the super enthusiastic grads. The grads just finished bootcamps, many of them junior on paper, but had a different career in the past. They soaked it all in and grew fast. Sure, some left after a while, but a surprisingly large number stayed because of the environment and the people.
And the company did well. The pay for the expeirenced devs was probably a bit under the market, somewhere at £50-60K. The new grads were cheap. Still, attrition was low, morale high, output consistent and quality high.
I think of this example many times. Why do so few places not try something similar? Especially at places where you don’t need to use the latest and greatest, where business is stable, and where you can get a bunch of these benefits altogether.
There's a fundamentally incorrect claim at the heart of this article.
>Technology changes rapidly in software development.
That might be true of specific kinds of software development. People developing what used to be called "applications" (and now increasingly is once again called by the same name) are using very diffferent technologies than they were in 1985 or even 1995 and perhaps even 2005.
But if you're writing, for example, "creative" software (audio, video, graphics), the toolchains and fundamentals haven't changed much in 20-30 years. The rise of GPUs has added a wrinkle to the mix if you're doing video/graphics, but often at a layer you likely don't think much about on a day to day basis.
As a programmer of 35 years, I've got nothing to teach younger programmers who are doing webdev work in JS and/or some server-side stuff. But a younger programmer who wants to do native realtime audio has nothing to teach me, no new technologies to show me (they could easily be a better programmer, though).
Let's try to remember that "software" is bigger than webdev, and the rate of change outside of the volatile webdev sphere isn't always as dynamic as this article makes out. For some of us, GPT-N is fascinating as hell, but will make absolutely no difference to our work as programmers for the rest of our lives no matter how old we are right now.
I agree so much. When I started my career as a programmer around 25 years ago... I used a text editor in a GUI. OOP frameworks were new, but they weren't much different from the ones around today. Sure, some of the specific tools have changed. But the day to day and the concepts used (OOP, processes/threads/async, networking, filesystems, signals, etc.) are all the same. I think the biggest changes is the huge increase in availability of information (docs, sample code, etc).
IMO, software development fashions changes rapidly. But actual software development? The changes and improvements are glacially slow. I suspect that architecture (which is a discipline literally as old as human civilization) has changed more in the last 30 years than software development has. But that was mostly thanks to software. So there's that. :-)
That 5 monkeys story is definitely not false, nor fabricated.
I've seen it myself in a social experiment where actors were placed in a waiting room. There were 5 actors that stood up for 5 seconds every time a bell was rang at random moments. A "test subject" was added and quickly joined in. They swapped out the actors one by one and long behold - after 30 minutes 6 random strangers were standing up when the bell was rang without having the slightest clue why.
That entire video smells of being fake. I’ll admit I don’t have anything other than a gut reaction to the combination of production quality, editing, and sheer silliness to go on. But there’s enough off that it raises my skepticism a lot.
Do you want to discuss pedagogy, and why some people only need one youtube video to do this task just fine, while you could show 100 to others and they would fail every time, regardless of experience?
As an experienced software engineer and also an experienced home remodeler, you make a great point.
A kitchen remodel typically requires skills in plumbing, electric, framing carpentry, finish carpentry, drywall, painting.
None of this will be appreciated or understood by someone watching a video.
Each of these skills can take quite a while even for basic proficiency, let alone mastery to the level required to work smoothly, and quickly enough to make any money at it (or avoid divorce as your kitchen sits for months in an unusable state).
This has nothing to do with age, and little with experience.
You mix up knowledge, skills and proficiencies.
If you watch 10 youtube videos, you might gain the knowledge of building a kitchen, but you neither gained the skills of using tools, nor the proficiency of planning and building a kitchen.
Those are very distinct things, which pedagogues are aware of.
Seems like the better question would be to hire someone under 30 (who has some means to demonstrate basic qualifications) to do step (2) if you want your point to have any meaning.
He explicitly said that experience does matter. It's just that it was a well known argument so he wouldn't bother retreading it. So, I'm not sure what your point is.
Simple demographics cause the number of programmers to double every 5 years. I'm 45. Any project I join, I'm extremely likely to be the oldest person around. That's not because all my generation has long retired into management but because there are about (2^4) 16x more younger people around in the industry, with most of them being below 30 and because becoming a developer was just not a common career path when I left high school. In 5 years it will be 2^5=32 for me. I'll still be coding though because I like doing that.
On an average ten person team, the average age is not going to get much above 30, if you are lucky. Most of those people would be considered senior.
I've been on a few projects that went against the trend and worked with a few people above 40. These projects are expensive because (properly) senior people cost money. But older does not mean wiser or better. So, the value for money is not always that obvious. Of course some people that are good only get better with age. But the reverse is true as well and there are a lot of not so great developers that will still be coding for the next few decades. That ratio good to bad programmers doesn't really change; though of course the bad ones might pick up a few useful skills eventually.
Well, I'm a bit tired of this "debate" (there actually isn't one -it's all about personal emotional baggage, when it gets stripped down to the bare skeleton, and we can't actually reason with our reptile brains; which is where this stuff lives).
I admit that I did my share of whining. It was quite jarring for me to encounter the naked, unapologetic ageism in tech, but I have now come to accept that it's just "part of the landscape." I can't change anyone else's mind, so I don't even try, anymore.
You don't want what I have? Don't worry; You won't get it. I won't waste any of our time, trying to convince you otherwise.
My age (and commensurate experience) helps me to get stuff done. I don't pretend to have the creative flair that can dream up reusable boosters and smartphones, but I definitely have a long, long record of ship. I've been working on shipping product, for my entire adult life. I'm pretty good at working in a layered, modular fashion that can result in robust, highly-usable, scalable, localizable and accessible software that can project and reinforce branding, as well as actually provide a revenue stream, and establish a legacy. I've written software that lasts decades.
But that doesn't seem to be what the industry wants. Quick lash-ups are more valuable. I understand why. They can act as "MVPs," and iterate quickly. That's actually a really important feature, and one that us ol' fogeys don't always appreciate. When I look back on my career, I shipped a lot of dross, as well as a (far fewer) number of really good products. The quality of my work improved dramatically as I got older; mostly because I screwed up so much, earlier. I'm grateful that none of my screwups turned into the Jurassic-scale disasters we read about all the time.
"Good judgment comes from experience. Experience comes from bad judgment."
At the moment, I'm working on a social media-style system. It's fairly ambitious. I can't even imagine my younger self working on this kind of thing, but I am grateful for the long trail of work by others that give me pitfalls and patterns to use. Younger me would have ignored all that, slapped together stuff without proper design or testing, and turned out some real crap. A lot of people would have been hurt by my cruddy workmanship.
> We need old people because they're in a position to speak truth to the world
This isn't really about age at all - its more about incremental change vs disruptive change and who has the power to make those kinds of changes.
The old are in positions of power/influence and are often aiming to move things forward incrementally. They are rarely willing to risk everything for the chance to make paradigm leaps. Outsiders, on the other hand, are more willing to take audacious risks and have nothing to lose.
The young are nearly always outsiders but not all outsiders are young. Interestingly, when an old person retires, they become outsiders too with less to lose than before and therefore more willing to speak truth to power. The dynamic here isn't really about age at all but about power.
We need to get better at recognizing when change requires a patch of our models and paradigms vs when it is actually more effective to perform a full rewrite and create new ones. If we were better at that, we'd perhaps be better at valuing the types of people required for those changes.
> They are rarely willing to risk everything for the chance to make paradigm leaps.
Yes, and your phrasing of that is one of the most accurate I've seen in these threads. We who are old are completely capable to make leaps... but we are not incentivized to do so. Stock options and a chance to make a couple million will inspire the young to work wonders. But those of us who have been saving our income for a few decades already have a nice nest egg, so an incremental update to our nest egg isn't so compelling. The rewards at the end must also be a paradigm leap.
And there are paradigm leaps in this life - most of us start at the point where we struggle to pay bills. Then you jump to where you are not struggling. Then you have enough to own nice things. Then you have a home that truly makes you feel at home. Then your home is paid off and you measure your nest egg by how many years you could go without a job. Then you hit the point where that number is higher than the number of years you are likely to live. And then you hit the point where you have extra money to enable you to change your lifestyle and give more money to charity and still have enough to live out your whole life.
Any job that doesn't move us to the next one of those points is not incentive to work harder and give up time with
our family, etc. That is also why we have less to lose as we get older. Because each of those points also means we are less dependent on our job.
At the end of the day, the differences in behavior are real. But anyone who thinks it is due to a difference in skills hasn't yet seen the big picture. Give us compensation that drives a paradigm shift in our lives, and we can drive a paradigm shift in our work to match it.
The most useful 3 things that age/experience has taught me personally are:
1. There are unknown unknowns (I don’t know why Donald Rumsfeld got so much flak for saying this)
2. Developing something that gets used is far more rewarding in the long term than using the latest technology or paradigm, or coding for codings sake (It took me over a decade to realize this - it may just be me)
3. In more cases than not it doesn’t matter what the technology, language, or paradigm used to develop a system or product is. It’s more important that the people developing the system are committed to building it (and them choosing that technology often helps)
> There are unknown unknowns (I don’t know why Donald Rumsfeld got so much flak for saying this)
He got flak for what he used it to justify. Out of context of the question to which it responds, the unknown unknowns statement wouldn't have been controversial (similarly with his “you go to war with the Army you have, not the Army you wish you had” offered in regard to a war of choice, not of imminent defense.)
Here's the "unknown unknowns" quote [0] in context. Rumsfeld is responding to a question on whether Iraq had any connections to WMDs. He's justifying the invasion by saying that inspectors aren't allowed in the country, so the US doesn't know if there are WMDs or not.
> Q: Could I follow up, Mr. Secretary, on what you just said, please? In regard to Iraq weapons of mass destruction and terrorists, is there any evidence to indicate that Iraq has attempted to or is willing to supply terrorists with weapons of mass destruction? Because there are reports that there is no evidence of a direct link between Baghdad and some of these terrorist organizations.
> Rumsfeld: Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones.
> And so people who have the omniscience that they can say with high certainty that something has not happened or is not being tried, have capabilities that are -- what was the word you used, Pam, earlier?
> Q: Free associate? (laughs)
> Rumsfeld: Yeah. They can -- (chuckles) -- they can do things I can't do. (laughter)
> Q: Excuse me. But is this an unknown unknown?
> Rumsfeld: I'm not --
> Q: Because you said several unknowns, and I'm just wondering if this is an unknown unknown.
Off topic: We gave Rumsfeld grief because most of his unknowns were in fact well known! He just didn’t like the facts on hand and led NATO into an evil disaster because reasons.
This is about control by managers. Older or more experienced developers will often call out BS if a manager makes a faux pas for whatever they are delivering. Younger programmers will work longer hours to make the managers look good.
With experience comes wisdom. Wisdom is a manager's worst nightmare unless they were technical in the first place.
Somebody else finding the Monkey experiment a good one but wrong for the Authors cause?
I mean, the cold water was an artificial external influence and just the opposite of something fundamentally impossible.
To be precise, exactly the exact kind of obstacles against which youth has rebelled at all times. Its not the same as the changed circumstances he relates later in his article to.
Galois: Was shot in a fabricated duel (like Lermontov and Pushkin BTW). The setup exploited certain concepts of honor and - kind of ironically - hot-tempered youthness, susceptive to this.
The author is saying that the cold water represents the technological limitations in the past. "What old people don't realise is that sometimes, circumstances change."
One solution is to be self-employed and make a product. I'm 71, I code C++/C# forty+ hours a week, and I'm having a blast. I just discovered the STL a couple of years ago.
I'm not an "old" programmer (I don't think... I did have an intern ask me one time if I had ever worked with punch cards, so maybe I am...).
This article plays off a stereotype that I don't think it particularly helpful (or accurate). I've worked with experienced engineers who are all about the RDBMS, but I've also come across young engineers that don't know about anything more than RDBMSs because their university didn't teach them any more than that. I've worked with young engineers who were reluctant to go out of their comfort zone (and by that, I mean work in the JavaScript layer of the Java webapp they were working on), and I've worked with a whole team of really experienced engineers who had spent their whole career doing C/C++ who decided to build a product on Node.js.
I would agree with the point that having a diversity of backgrounds and perspective can be helpful on a software team. We need people who keep asking "why" on a team, and we need people with historical background. But to assume engineers are a particular way because they are old are young is (1) not accurate and (2) setting a large part of the population up to not meet your assumed expectations.
I'm 36. I interviewed in last 10 years probably more than 250 candidates. Young programmers. Imagine that more than half couldn't explain what is the difference between queue and stack.
There is maybe 1 in 10 or 50 Young devs that had luck to work in something like good dev agency and build serveral projects to gain needed experience.
For me age doesn't matter that much because:
* You could be 50 and worked on 2-3 projects entire life
* You could be 30 and worked on 25 projects or more.
You could take any of those young dev, teach them what a stack and a queue are in almost no time. The fact that they didn’t face that question before doesn’t mean they are bad picks for a job.
To be fair, I've been programming enterprise systems for 6 years now and haven't been interviewing in at least 18 months. This question threw me off. Once I googled it and read a whole two paragraphs it jarred my memory and I can speak to it. I can speak to what they do and when I would use one or the other. I can also reference real-world situations where I implemented a queue or a stack.
But lately I've been knee deep in data analytics for the last 18 months and simply haven't touched those "queue / stack" tools in a while. So I needed a "quick lookup" to refresh my memory.
Now if I was actively interviewing, this might be something I would review, as it's a fairly common interview question.
> Imagine that more than half couldn't explain what is the difference between queue and stack
> There is maybe 1 in 10 or 50 Young devs that had luck to work in something like good dev agency and build serveral projects to gain needed experience
This seems like it's implying that knowing the difference between a Queue and a Stack is a good indicator of experience.
Perhaps instead pose a problem where a queue and a stack would normally be used and have them solve it and explain their solution. You can tell a lot more about someone than asking a context free question on theoretical constructs. Is it more important to have someone who approaches a problem theoretically or practically?
While I don't disagree with the conclusion, I'm not sold on the argument.
It would rather seem the key is to not make people afraid of speaking their mind or making mistakes.
Someone who's young, just got their first job, needs the money and is insecure about their ability to get another job will not take the same risks as someone with a decade of experience, that has a network and knows they can get a new job if they need to.
Similarly someone close to retirement might have the most to lose in the few years before pension kicks in.
So it rather seems that what we need is to give people a work environment where they don't have to be afraid of speaking their mind or making mistakes.
> While I don't disagree with the conclusion, I'm not sold on the argument.
> It would rather seem the key is to not make people afraid of speaking their mind or making mistakes.
Wholeheartedly agree.
Notably, this is also the underlying key to accelerating a team's velocity, whether we're talking about TDD, CI, blue/green deployments, database schema rollbacks, canary releases, blameless retrospectives, Lean Startup MVPs, or many other tactics.
The basic strategy is: focus on reducing the cost of making a mistake (and learning from it) instead of on making fewer mistakes.
Because the easiest way to make fewer mistakes is always to do nothing (alternatively, "nothing interesting", or "nothing new", etc.).
Developing without fear isn't so much "move fast and break things", it's more "Move fast and have an undo button (for anything important you might break)."
For me, the big thing is that older developers need to use their experience in helpful manners. In my experience, it's used it to simply block or scoff at the actions of younger devs or managers while not always working to solve the issue. In order to be useful, you have to also work and suggest alternatives and solutions, otherwise you're just a curmudgeon. That's at least what I've found working at a site that is mostly older engineers.
> "Once, if you had lots of data, you had to store it in fully normalised form, because storage was expensive."
> I don't think normalization was ever about storage space.
I'm not the GP, but...
I had to sell the "extra" work and complexity to a nontechnical stakeholder who considers themselves a power user of Access and Excel and wants every report to be a single simple query with no joins that they can write and run on their own.
BTW, the same stakeholder also wanted to shard data by month through table-naming conventions (ie. SELECT SUM(Total) June_Total FROM June_Sales) and get aggregate reports by looping through these tables.
So, yeah, the winning argument came down to money for storage (larger hard drives & bigger backups of the duplicated data) vs. having an employee run reports for him.
[+] [-] munificent|5 years ago|reply
The length of a string determines how quickly it vibrates (assuming tension is the same). Shorter strings vibrate faster than long strings. If you're in a noisy environment and you want to make sense of all of the chaotic sounds around you, one way to do it would be to take a bunch of strings of different lengths (say a piano) and see which ones resonate more than others. The gentle ringing of those piano strings, some louder than others, tells you which frequencies are more dominant in the surrounding acoustic environment, because they cause their matching strings to resonate more.
As I get older (I'm in my forties), I feel like a lengthening string. When I was a twenty-something programmer, I could tell you how things had changed over a year or two, but trends or cycles on longer timescales than that were hidden to me. Now I know what a decade or two feels like and can see and intuitively sense cycles of that scale. At the same time, shorter trends are harder for me to pick up on now. It feels like noise or beneath my notice.
Having people of different ages in your organization is incredibly value because they all resonate at different time scales like this and help you pick up chronological patterns at frequencies you'd otherwise miss.
[+] [-] gtsop|5 years ago|reply
I have a real life example of the five monkeys story. A company I used to work for had a pile of legacy systems in php4, mysql 5.0 and a frontend working only on IE8, no ci/cd, no tests. Almost instantly I was lead to beleive this system is a black hole that can't be saved due to the technical difficulties plus management issues. The head of IT was there for almost 20 years watching tons of developers contribute to this mess and failing to take meaningful action to address the problem. Thus he had insane clarity of all the problems, but also was pesimistic about any possitive outcome. With his experience on these systems and my determination (probably stemming from my youth) we managed to upgrade php to 5.6 (almost compatible with 7), mysql 5.5 and most of the front end could work on latest chrome in a year (+ a great deal of performance optimizations). We both left that place having layed out a solid foundation for the people who were left behind to continue this modernization endavour (which I've learned was carried on)
[+] [-] maratumba|5 years ago|reply
[+] [-] mtberatwork|5 years ago|reply
That one day will be here in a blink of an eye. Seems like only yesterday I was the wide-eyed, naive programmer fresh from uni... :)
[+] [-] Nursie|5 years ago|reply
Your tale is great, and sounds like a great experience, but I don't think it's necessarily related to the age of the participants, and to me the key here is this -
"The head of IT was there for almost 20 years"
To me that reeks of stagnation. 20 years in the same place! This person hasn't exposed themselves to new ideas, cross pollination of techniques and skills etc etc. They've become ossified and cynical, and not because they're older, but because they haven't moved around. Anyone being somewhere more than a handful of years (5?) is a red flag to me, if you're looking for technical competency.
I'm glad, for his sake, that story ends with the guy moving on!
[+] [-] rmason|5 years ago|reply
Had a friend tell me when he was a newly minted lieutenant. All the new guys were put in a competition with their platoon to build a temporary bridge across a river. While all the others called out orders he consulted the grizzled old Sarge and asked him what he recommended. He took his advice and said lets proceed. Instead of barking orders he spent time working alongside his men doing physical labor. His team not only won they set a record for that task. As a result his platoon would walk through a wall for him.
But what if there isn't an old experienced Sarge? The organization is the worse for it and I've seen it time and time again.
[+] [-] bregma|5 years ago|reply
[+] [-] blablabla123|5 years ago|reply
[+] [-] proverbialbunny|5 years ago|reply
This is where communication skills come in. The more one levels up their communication skills the easier situations like this are to overcome.
[+] [-] gregdoesit|5 years ago|reply
This was a company in finance, doing not-very-interesting things. You’ve probably never heard of it. About half the devs were above 50, and the other half straight out of bootcamp, with a few people in-between.
It worked so great. The “old ones” brought a lot of maturity, practices (TDD, tests, even XP at times) and loved mentoring the super enthusiastic grads. The grads just finished bootcamps, many of them junior on paper, but had a different career in the past. They soaked it all in and grew fast. Sure, some left after a while, but a surprisingly large number stayed because of the environment and the people.
And the company did well. The pay for the expeirenced devs was probably a bit under the market, somewhere at £50-60K. The new grads were cheap. Still, attrition was low, morale high, output consistent and quality high.
I think of this example many times. Why do so few places not try something similar? Especially at places where you don’t need to use the latest and greatest, where business is stable, and where you can get a bunch of these benefits altogether.
[+] [-] username90|5 years ago|reply
You do realize that most people in their 20's have many years of experience and know all of those things? Young doesn't mean inexperienced.
[+] [-] PaulDavisThe1st|5 years ago|reply
>Technology changes rapidly in software development.
That might be true of specific kinds of software development. People developing what used to be called "applications" (and now increasingly is once again called by the same name) are using very diffferent technologies than they were in 1985 or even 1995 and perhaps even 2005.
But if you're writing, for example, "creative" software (audio, video, graphics), the toolchains and fundamentals haven't changed much in 20-30 years. The rise of GPUs has added a wrinkle to the mix if you're doing video/graphics, but often at a layer you likely don't think much about on a day to day basis.
As a programmer of 35 years, I've got nothing to teach younger programmers who are doing webdev work in JS and/or some server-side stuff. But a younger programmer who wants to do native realtime audio has nothing to teach me, no new technologies to show me (they could easily be a better programmer, though).
Let's try to remember that "software" is bigger than webdev, and the rate of change outside of the volatile webdev sphere isn't always as dynamic as this article makes out. For some of us, GPT-N is fascinating as hell, but will make absolutely no difference to our work as programmers for the rest of our lives no matter how old we are right now.
[+] [-] rmah|5 years ago|reply
IMO, software development fashions changes rapidly. But actual software development? The changes and improvements are glacially slow. I suspect that architecture (which is a discipline literally as old as human civilization) has changed more in the last 30 years than software development has. But that was mostly thanks to software. So there's that. :-)
[+] [-] dstick|5 years ago|reply
I've seen it myself in a social experiment where actors were placed in a waiting room. There were 5 actors that stood up for 5 seconds every time a bell was rang at random moments. A "test subject" was added and quickly joined in. They swapped out the actors one by one and long behold - after 30 minutes 6 random strangers were standing up when the bell was rang without having the slightest clue why.
We're funny creatures :D
Just did a quick Google, here's the video: https://www.youtube.com/watch?v=MEhSk71gUCQ
[+] [-] geuis|5 years ago|reply
[+] [-] simongray|5 years ago|reply
[+] [-] ransom1538|5 years ago|reply
0) watch 10 youtube videos on kitchen remodels
1) take a sledge hammer and remove your kitchen this weekend
2) rebuild your kitchen
Let me know how this goes.
[+] [-] kebman|5 years ago|reply
[+] [-] tomohawk|5 years ago|reply
A kitchen remodel typically requires skills in plumbing, electric, framing carpentry, finish carpentry, drywall, painting.
None of this will be appreciated or understood by someone watching a video.
Each of these skills can take quite a while even for basic proficiency, let alone mastery to the level required to work smoothly, and quickly enough to make any money at it (or avoid divorce as your kitchen sits for months in an unusable state).
[+] [-] teraku|5 years ago|reply
You mix up knowledge, skills and proficiencies.
If you watch 10 youtube videos, you might gain the knowledge of building a kitchen, but you neither gained the skills of using tools, nor the proficiency of planning and building a kitchen.
Those are very distinct things, which pedagogues are aware of.
[+] [-] klmadfejno|5 years ago|reply
[+] [-] klunger|5 years ago|reply
[+] [-] jillesvangurp|5 years ago|reply
On an average ten person team, the average age is not going to get much above 30, if you are lucky. Most of those people would be considered senior.
I've been on a few projects that went against the trend and worked with a few people above 40. These projects are expensive because (properly) senior people cost money. But older does not mean wiser or better. So, the value for money is not always that obvious. Of course some people that are good only get better with age. But the reverse is true as well and there are a lot of not so great developers that will still be coding for the next few decades. That ratio good to bad programmers doesn't really change; though of course the bad ones might pick up a few useful skills eventually.
[+] [-] dpc_pw|5 years ago|reply
[+] [-] ChrisMarshallNY|5 years ago|reply
I admit that I did my share of whining. It was quite jarring for me to encounter the naked, unapologetic ageism in tech, but I have now come to accept that it's just "part of the landscape." I can't change anyone else's mind, so I don't even try, anymore.
You don't want what I have? Don't worry; You won't get it. I won't waste any of our time, trying to convince you otherwise.
My age (and commensurate experience) helps me to get stuff done. I don't pretend to have the creative flair that can dream up reusable boosters and smartphones, but I definitely have a long, long record of ship. I've been working on shipping product, for my entire adult life. I'm pretty good at working in a layered, modular fashion that can result in robust, highly-usable, scalable, localizable and accessible software that can project and reinforce branding, as well as actually provide a revenue stream, and establish a legacy. I've written software that lasts decades.
But that doesn't seem to be what the industry wants. Quick lash-ups are more valuable. I understand why. They can act as "MVPs," and iterate quickly. That's actually a really important feature, and one that us ol' fogeys don't always appreciate. When I look back on my career, I shipped a lot of dross, as well as a (far fewer) number of really good products. The quality of my work improved dramatically as I got older; mostly because I screwed up so much, earlier. I'm grateful that none of my screwups turned into the Jurassic-scale disasters we read about all the time.
"Good judgment comes from experience. Experience comes from bad judgment."
At the moment, I'm working on a social media-style system. It's fairly ambitious. I can't even imagine my younger self working on this kind of thing, but I am grateful for the long trail of work by others that give me pitfalls and patterns to use. Younger me would have ignored all that, slapped together stuff without proper design or testing, and turned out some real crap. A lot of people would have been hurt by my cruddy workmanship.
[+] [-] etripe|5 years ago|reply
Thanks for introducing me to that quote!
> You don't want what I have? Don't worry; You won't get it. I won't waste any of our time, trying to convince you otherwise.
I'm glad you're not letting it get you down. As long as there still are opportunities to be had, you'll be fine in the end.
[+] [-] benjaminjosephw|5 years ago|reply
This isn't really about age at all - its more about incremental change vs disruptive change and who has the power to make those kinds of changes.
The old are in positions of power/influence and are often aiming to move things forward incrementally. They are rarely willing to risk everything for the chance to make paradigm leaps. Outsiders, on the other hand, are more willing to take audacious risks and have nothing to lose.
The young are nearly always outsiders but not all outsiders are young. Interestingly, when an old person retires, they become outsiders too with less to lose than before and therefore more willing to speak truth to power. The dynamic here isn't really about age at all but about power.
We need to get better at recognizing when change requires a patch of our models and paradigms vs when it is actually more effective to perform a full rewrite and create new ones. If we were better at that, we'd perhaps be better at valuing the types of people required for those changes.
[+] [-] codingdave|5 years ago|reply
Yes, and your phrasing of that is one of the most accurate I've seen in these threads. We who are old are completely capable to make leaps... but we are not incentivized to do so. Stock options and a chance to make a couple million will inspire the young to work wonders. But those of us who have been saving our income for a few decades already have a nice nest egg, so an incremental update to our nest egg isn't so compelling. The rewards at the end must also be a paradigm leap.
And there are paradigm leaps in this life - most of us start at the point where we struggle to pay bills. Then you jump to where you are not struggling. Then you have enough to own nice things. Then you have a home that truly makes you feel at home. Then your home is paid off and you measure your nest egg by how many years you could go without a job. Then you hit the point where that number is higher than the number of years you are likely to live. And then you hit the point where you have extra money to enable you to change your lifestyle and give more money to charity and still have enough to live out your whole life.
Any job that doesn't move us to the next one of those points is not incentive to work harder and give up time with our family, etc. That is also why we have less to lose as we get older. Because each of those points also means we are less dependent on our job.
At the end of the day, the differences in behavior are real. But anyone who thinks it is due to a difference in skills hasn't yet seen the big picture. Give us compensation that drives a paradigm shift in our lives, and we can drive a paradigm shift in our work to match it.
[+] [-] helsinkiandrew|5 years ago|reply
1. There are unknown unknowns (I don’t know why Donald Rumsfeld got so much flak for saying this)
2. Developing something that gets used is far more rewarding in the long term than using the latest technology or paradigm, or coding for codings sake (It took me over a decade to realize this - it may just be me)
3. In more cases than not it doesn’t matter what the technology, language, or paradigm used to develop a system or product is. It’s more important that the people developing the system are committed to building it (and them choosing that technology often helps)
[+] [-] dragonwriter|5 years ago|reply
He got flak for what he used it to justify. Out of context of the question to which it responds, the unknown unknowns statement wouldn't have been controversial (similarly with his “you go to war with the Army you have, not the Army you wish you had” offered in regard to a war of choice, not of imminent defense.)
[+] [-] rovolo|5 years ago|reply
> Q: Could I follow up, Mr. Secretary, on what you just said, please? In regard to Iraq weapons of mass destruction and terrorists, is there any evidence to indicate that Iraq has attempted to or is willing to supply terrorists with weapons of mass destruction? Because there are reports that there is no evidence of a direct link between Baghdad and some of these terrorist organizations.
> Rumsfeld: Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns -- the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tend to be the difficult ones.
> And so people who have the omniscience that they can say with high certainty that something has not happened or is not being tried, have capabilities that are -- what was the word you used, Pam, earlier?
> Q: Free associate? (laughs)
> Rumsfeld: Yeah. They can -- (chuckles) -- they can do things I can't do. (laughter)
> Q: Excuse me. But is this an unknown unknown?
> Rumsfeld: I'm not --
> Q: Because you said several unknowns, and I'm just wondering if this is an unknown unknown.
> Rumsfeld: I'm not going to say which it is.
[0] https://archive.defense.gov/Transcripts/Transcript.aspx?Tran...
[+] [-] michael1999|5 years ago|reply
[+] [-] waylandsmithers|5 years ago|reply
[+] [-] sys_64738|5 years ago|reply
With experience comes wisdom. Wisdom is a manager's worst nightmare unless they were technical in the first place.
[+] [-] mbeex|5 years ago|reply
Galois: Was shot in a fabricated duel (like Lermontov and Pushkin BTW). The setup exploited certain concepts of honor and - kind of ironically - hot-tempered youthness, susceptive to this.
[+] [-] rovolo|5 years ago|reply
[+] [-] GnarfGnarf|5 years ago|reply
[+] [-] artificial|5 years ago|reply
[+] [-] jkingsbery|5 years ago|reply
This article plays off a stereotype that I don't think it particularly helpful (or accurate). I've worked with experienced engineers who are all about the RDBMS, but I've also come across young engineers that don't know about anything more than RDBMSs because their university didn't teach them any more than that. I've worked with young engineers who were reluctant to go out of their comfort zone (and by that, I mean work in the JavaScript layer of the Java webapp they were working on), and I've worked with a whole team of really experienced engineers who had spent their whole career doing C/C++ who decided to build a product on Node.js.
I would agree with the point that having a diversity of backgrounds and perspective can be helpful on a software team. We need people who keep asking "why" on a team, and we need people with historical background. But to assume engineers are a particular way because they are old are young is (1) not accurate and (2) setting a large part of the population up to not meet your assumed expectations.
[+] [-] jakuboboza|5 years ago|reply
There is maybe 1 in 10 or 50 Young devs that had luck to work in something like good dev agency and build serveral projects to gain needed experience.
For me age doesn't matter that much because:
* You could be 50 and worked on 2-3 projects entire life * You could be 30 and worked on 25 projects or more.
[+] [-] dgellow|5 years ago|reply
[+] [-] SamuelAdams|5 years ago|reply
To be fair, I've been programming enterprise systems for 6 years now and haven't been interviewing in at least 18 months. This question threw me off. Once I googled it and read a whole two paragraphs it jarred my memory and I can speak to it. I can speak to what they do and when I would use one or the other. I can also reference real-world situations where I implemented a queue or a stack.
But lately I've been knee deep in data analytics for the last 18 months and simply haven't touched those "queue / stack" tools in a while. So I needed a "quick lookup" to refresh my memory.
Now if I was actively interviewing, this might be something I would review, as it's a fairly common interview question.
[+] [-] ZephyrBlu|5 years ago|reply
> There is maybe 1 in 10 or 50 Young devs that had luck to work in something like good dev agency and build serveral projects to gain needed experience
This seems like it's implying that knowing the difference between a Queue and a Stack is a good indicator of experience.
How do you figure that as a good signal?
[+] [-] tomohawk|5 years ago|reply
[+] [-] lmilcin|5 years ago|reply
There is tendency for some people to stop progressing and change their demeanor as they age and that's what I call "old".
On the other hand if you keep being inquisitive, energized, continue learning including from your own mistakes, you are getting "experienced".
--
- What does a company pay for when they pay large sallary for an experienced engineer?
- They pay for all the mistakes he/she made at her previous job.
[+] [-] magicalhippo|5 years ago|reply
It would rather seem the key is to not make people afraid of speaking their mind or making mistakes.
Someone who's young, just got their first job, needs the money and is insecure about their ability to get another job will not take the same risks as someone with a decade of experience, that has a network and knows they can get a new job if they need to.
Similarly someone close to retirement might have the most to lose in the few years before pension kicks in.
So it rather seems that what we need is to give people a work environment where they don't have to be afraid of speaking their mind or making mistakes.
[+] [-] webmaven|5 years ago|reply
> It would rather seem the key is to not make people afraid of speaking their mind or making mistakes.
Wholeheartedly agree.
Notably, this is also the underlying key to accelerating a team's velocity, whether we're talking about TDD, CI, blue/green deployments, database schema rollbacks, canary releases, blameless retrospectives, Lean Startup MVPs, or many other tactics.
The basic strategy is: focus on reducing the cost of making a mistake (and learning from it) instead of on making fewer mistakes.
Because the easiest way to make fewer mistakes is always to do nothing (alternatively, "nothing interesting", or "nothing new", etc.).
Developing without fear isn't so much "move fast and break things", it's more "Move fast and have an undo button (for anything important you might break)."
[+] [-] sheepybloke|5 years ago|reply
[+] [-] incompatible|5 years ago|reply
I don't think normalization was ever about storage space.
[+] [-] webmaven|5 years ago|reply
> I don't think normalization was ever about storage space.
I'm not the GP, but...
I had to sell the "extra" work and complexity to a nontechnical stakeholder who considers themselves a power user of Access and Excel and wants every report to be a single simple query with no joins that they can write and run on their own.
BTW, the same stakeholder also wanted to shard data by month through table-naming conventions (ie. SELECT SUM(Total) June_Total FROM June_Sales) and get aggregate reports by looping through these tables.
So, yeah, the winning argument came down to money for storage (larger hard drives & bigger backups of the duplicated data) vs. having an employee run reports for him.