We need young programmers; We need old programmers(blog.ploeh.dk)
blog.ploeh.dk
We need young programmers; We need old programmers
https://blog.ploeh.dk/2020/09/14/we-need-young-programmers-we-need-old-programmers/
263 comments
This is a good observation. I'm in my late 50s and more and more I keep getting the feeling "I've seen this (or something very similar) before" whether having to do with software development trends, politics, fashions etc. That old adage about there being nothing new under the sun didn't make much sense to me when I was younger, but now it seems to often ring true.
One of the things that I like about this analogy is that it also points out one of the pitfalls as we age. As our string gets longer, we aren't as good as picking up the higher frequency vibrations, so we risk assuming they aren't there at all.
A failure mode I see of some older developers is assuming there's nothing new under the sun and nothing worth learning, which I don't think is the case. I think it just gets harder for us to see those short term trends.
A failure mode I see of some older developers is assuming there's nothing new under the sun and nothing worth learning, which I don't think is the case. I think it just gets harder for us to see those short term trends.
The analogy might be a bit weak on the short side: Higher frequency means that the thing comes and goes within a short amount of time. Did I really need to learn a technology that was only in vogue for a few years?
Another analogy I've heard (I think it was from Ward Cunningham) is that technology comes in waves. You don't need to catch every wave - trying to do so will tire you out. A good surfer learns to be choosy about the waves they catch and that comes with experience.
Another analogy I've heard (I think it was from Ward Cunningham) is that technology comes in waves. You don't need to catch every wave - trying to do so will tire you out. A good surfer learns to be choosy about the waves they catch and that comes with experience.
> Higher frequency means that the thing comes and goes within a short amount of time.
Not every change is cyclic, so you risk being unable to respond quickly to fast permanent changes if you don't acknowledge a change until a sufficient amount of time has passed.
Not every change is cyclic, so you risk being unable to respond quickly to fast permanent changes if you don't acknowledge a change until a sufficient amount of time has passed.
Great analogy! I'll be mulling this one over for sure in the coming weeks/months.
I've got a couple of similar aging analogies/models (also in my forties) that tend to come to mind when I'm confronted with these sorts of topics, namely physical speed.
When we're young, we move slowly, crawling, then walking and running. The things we notice and care about tend to be smaller and more detailed. Walking home in elementary school, I knew every crack in the sidewalk, every brick in the retaining wall, every tree limb, every slope of every yard.
Then came the bike, and greater speed, then the car. More frequently in adulthood are the planes. Now I barely notice the fine details of what I pass by, but my awareness of city-scale things, both at home and abroad, has filled in...the streets, rivers, buildings, and the development that spans miles and miles that were far beyond my grasp when I moved slower. It's a bigger, more complete picture, but I can't zoom into it.
I often miss the slowness of my youth. I remember vividly being enraptured by the mundane details of my backyard, the roots of big pine trees, lush grassy spots, the cracked patio. So many tiny, "up close" details that were so interesting to look at, and run GI Joes and matchbox cars over for hours.
Building software is the same. Most of my giddy memories of discovery and productivity were in the "slow" phase of my career, when my tasks and responsibilities were fewer and closer to the ground, so to speak. The code itself. Now that I can travel faster, I have a larger number of more impactful responsibilities, but I don't feel that closeness or giddiness. I'm rarely enamored by the solutions that I churn out.
I've got a couple of similar aging analogies/models (also in my forties) that tend to come to mind when I'm confronted with these sorts of topics, namely physical speed.
When we're young, we move slowly, crawling, then walking and running. The things we notice and care about tend to be smaller and more detailed. Walking home in elementary school, I knew every crack in the sidewalk, every brick in the retaining wall, every tree limb, every slope of every yard.
Then came the bike, and greater speed, then the car. More frequently in adulthood are the planes. Now I barely notice the fine details of what I pass by, but my awareness of city-scale things, both at home and abroad, has filled in...the streets, rivers, buildings, and the development that spans miles and miles that were far beyond my grasp when I moved slower. It's a bigger, more complete picture, but I can't zoom into it.
I often miss the slowness of my youth. I remember vividly being enraptured by the mundane details of my backyard, the roots of big pine trees, lush grassy spots, the cracked patio. So many tiny, "up close" details that were so interesting to look at, and run GI Joes and matchbox cars over for hours.
Building software is the same. Most of my giddy memories of discovery and productivity were in the "slow" phase of my career, when my tasks and responsibilities were fewer and closer to the ground, so to speak. The code itself. Now that I can travel faster, I have a larger number of more impactful responsibilities, but I don't feel that closeness or giddiness. I'm rarely enamored by the solutions that I churn out.
It's interesting that you pretty much described a physical "discrete Fourier transform". Our cochlea works this way with different length hairs attached to nerves to hear different frequency ranges and old harmonic analyzers were build with this principle.
It's not a coincidence. :) My quarantine hobby has been getting into music, audio programming, and electronics, so I very much have Fourier analysis on the mind.
When I was a young engineer, I would be aware of the project I was working on, and the technical details. But nowadays I work on the level where I have to be aware of macro economics trends: I am tracking how different countries will be recovering from Covid19, how adjacent industries are doing, how the US-China trade war is affecting technology exports. My understanding of technology goes as far as performance metrics, value prop, schedule. I no longer have the time or inclination to dig into technical details, I leave that to the youngsters.
Fantastic analogy. I leaving this comment so I can find it later.
You can click on the timestamp and then favorite it. In your profile you can access favorites as well as even stories (and comments) you have upvoted.
I won't downvote you but based on observations over the last decade it wouldn't surprise me at all if someone else does.
I won't downvote you but based on observations over the last decade it wouldn't surprise me at all if someone else does.
Thank you for letting me know; I have done that. I'll leave my comment up so maybe others will learn as well.
yeah, definitely feels like people of different ages tuned/trained their pattern recognition engine biases at certain interest/point/threshold based on their experience/reward
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)
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.
Actually, they should be judged by what they can and do contribute to the team, whatever that is. Skills is a subset of that.
This (and original) statement(s) are all good and nice, but meaningless (in the same way as "there should be no hunger in the world because we have enough food").
Ok, we should judge people by what they can and do contribute to the team. The billion-dollar question is, HOW? Humans are extremely skilled optimizers - give them an objective metric and they'll game it for maximum benefit; make it subjective and it can be better or worse - but in either case, you'll no longer have any agreement on "what they contribute to the team".
Ok, we should judge people by what they can and do contribute to the team. The billion-dollar question is, HOW? Humans are extremely skilled optimizers - give them an objective metric and they'll game it for maximum benefit; make it subjective and it can be better or worse - but in either case, you'll no longer have any agreement on "what they contribute to the team".
How? Work with them. Pay them enough as they don't have to think about it.
Objective metrics are good if you think you can measure accurately for all individuals at the macro level. You may not need that (I mean, really _need_ it for your business to function, unless you're in the metric-tracking business).
If your teams have distinct and articulate enough outputs, you can retribute each team according to its specific outputs. At the macro level, you don't need to have more details (but you still may ask).
Let the team manage its own distribution of the retribution - and so on (so you do need trained managers to do it appropriately at each level).
Objective metrics are good if you think you can measure accurately for all individuals at the macro level. You may not need that (I mean, really _need_ it for your business to function, unless you're in the metric-tracking business).
If your teams have distinct and articulate enough outputs, you can retribute each team according to its specific outputs. At the macro level, you don't need to have more details (but you still may ask).
Let the team manage its own distribution of the retribution - and so on (so you do need trained managers to do it appropriately at each level).
> HOW?
* Documentation - Can they write?
* Potential - Can they provide original solutions to problems? Do they need hand holding?
* Initiative - Do they need a signal from a starting gun or are they self-entertained with word products for the team?
These are all identifiable maxims.
* Documentation - Can they write?
* Potential - Can they provide original solutions to problems? Do they need hand holding?
* Initiative - Do they need a signal from a starting gun or are they self-entertained with word products for the team?
These are all identifiable maxims.
I'm not saying "people can't be managed" and "one can't evaluate the performance of a programmer" - that'd be obviously false.
What I _am_ saying is that it's an art not a science - very hard to teach, impossible to scale.
Take your example with "Documentation" - if you measure anything objective (words written, number of functions/features that have associated documentation) and tie it with the performance evaluation, those metrics will soon become meaningless.
What I _am_ saying is that it's an art not a science - very hard to teach, impossible to scale.
Take your example with "Documentation" - if you measure anything objective (words written, number of functions/features that have associated documentation) and tie it with the performance evaluation, those metrics will soon become meaningless.
If it's true that one can evaluate the performance of a programmer, what does that mean? Can it be reduced to a vector of scalar values?
I hate doing performance reviews, and I especially didn't like when at a former employer I was asked to stack rank programmers. I feel like it's a task that's so difficult to get right, I can't even think of a wrong way to do it that's useful.
I hate doing performance reviews, and I especially didn't like when at a former employer I was asked to stack rank programmers. I feel like it's a task that's so difficult to get right, I can't even think of a wrong way to do it that's useful.
> what does that mean? Can it be reduced to a vector of scalar values?
No, it certainly doesn't mean that "your performance was [7.23541 8.1241 34.412515 .52632 995.154]". It means "you did good/ you did very good/ you need improvement", with some details like "<these things> you really handled well and I appreciate it; maybe you can work a bit on <this area> though". I definitely agree one shouldn't stack-rank people - especially in a good team (it's entirely possible, desirable even, that everybody did a great job)
No, it certainly doesn't mean that "your performance was [7.23541 8.1241 34.412515 .52632 995.154]". It means "you did good/ you did very good/ you need improvement", with some details like "<these things> you really handled well and I appreciate it; maybe you can work a bit on <this area> though". I definitely agree one shouldn't stack-rank people - especially in a good team (it's entirely possible, desirable even, that everybody did a great job)
Poor metrics are meaningless regardless of what you try to measure.
In the example of documentation a better metric might be a composite value of
(i) how many wiki articles a developer has written, weighed 0.33 and
(ii) how useful on a numerical scale his/her peers rate the documentation produced, weighed 0.67.
This is just an example but it's a composite of perceptual and objective, with the perceptual being a lot more important (and to prevent gaming the system by writting lots of useless articles).
In the example of documentation a better metric might be a composite value of
(i) how many wiki articles a developer has written, weighed 0.33 and
(ii) how useful on a numerical scale his/her peers rate the documentation produced, weighed 0.67.
This is just an example but it's a composite of perceptual and objective, with the perceptual being a lot more important (and to prevent gaming the system by writting lots of useless articles).
The way I've experienced it is that when a measurement becomes a metric, it ceases to be a good measurement. When people's bonus is tied to a measurement, they will find creative ways to influence that measurement which, in many cases, defeats the purpose of what it was trying to measure in the first place. It's not simply a matter of choosing the right measurements. It's also a matter of how you incentivize those measurements.
When I worked at Microsoft one of the teams I was adjacent to had a metric on number of new apps in the Windows Phone app store. So the teams went out and got a bunch of college students to build shitty apps in bootcamp style working groups. Suddenly the number of apps isn't good enough, so they added review metrics. Now those teams add a "let's all rate each other's apps" portion to the bootcamp taking you even further away from the results you're trying to obtain.
When I worked at Microsoft one of the teams I was adjacent to had a metric on number of new apps in the Windows Phone app store. So the teams went out and got a bunch of college students to build shitty apps in bootcamp style working groups. Suddenly the number of apps isn't good enough, so they added review metrics. Now those teams add a "let's all rate each other's apps" portion to the bootcamp taking you even further away from the results you're trying to obtain.
It's all in the details. If I get to pick who rates "how useful", this translates into a general "how well liked by my colleagues am I" (general problem with 360* feedback; I'm not saying it's useless, but it does have its limitations)
Re initiative. I've had jobs which did not want initiative on a macro level - my manager would tell me what was wanted, I'd go away and make it happen. Those managers loved me. My current role, bullshitted into a "devops" role, I'm expected to spend my days showing initiative - building things that I think will be useful - and which never get used. I'll take the former jobs. What I have now sounds like freedom, it feels pointless and torturously demotivating. Do my managers know what they're doing? Do they have any roadmap? Can they see shortcomings in our systems? Is it mushroom management or cluelessness? I think these positive sounding words eg "initiative" are not positive - they are context dependent. "Potential" - if you need someone writing endless crud, if they have potential are they going to stick around? Do you really want/need Achilles? Are you really leading the Trojan army? Maybe you just need sticky tape, not a welding torch.
You touch on two issues here: one, that there's an entire gamut and not a binary "senior/junior"... and management just LOVE to present requirements like "Can walk on liquid water; God asks him for advice on how to run the world" when you ask "what do I need to do in order to get to next level", especially in big corporations [1].
The second is that different types of people prefer different styles of working and sometimes forget there is another side (multiple "other sides", really). A team needs to be a mix of capabilities and personalities to be successful - a team of 100 identical individuals would likely fail, even if all them are Peter Norvig). So, you need people that are "senior" in the sense that "knows the business well enough to provide different perspectives" (and for those "shows initiative" is critical) but you also need specialists where "senior" means "knows technology X really really well". Say, a DBA - can keep your database up, can write efficient queries to retrieve information that you want; but doesn't know sh*t about what information would be interesting to retrieve. Or whether it's a good idea to keep some information X in the database, considering the various business, legal, social, cost perspectives.
> Do my managers know what they're doing?
Here's the thing: I believe nobody _really_ does. Sure, some know more than others, but in absolute terms, we're all basically guessing. That's why people insist on engineers that "show initiative" - not because they're always right, but in an environment where we don't _really_ know what we're doing, people yelling different perspectives are valuable.
However, as mentioned above - not all senior engineers want or are inclined to show this kind of initiative; and it's unfair to penalize those kinds of engineers, because we _need_ the different types of personalities.
[1] FWIW I believe the reality is , always, that you need to (A) work on a successful project; and (B) be generally liked by your colleagues and maybe managers. For very senior titles, also (C) have a large network of connections within the company - i.e. work on many things, or on one thing but a thing that is used by many teams/ really popular)
The second is that different types of people prefer different styles of working and sometimes forget there is another side (multiple "other sides", really). A team needs to be a mix of capabilities and personalities to be successful - a team of 100 identical individuals would likely fail, even if all them are Peter Norvig). So, you need people that are "senior" in the sense that "knows the business well enough to provide different perspectives" (and for those "shows initiative" is critical) but you also need specialists where "senior" means "knows technology X really really well". Say, a DBA - can keep your database up, can write efficient queries to retrieve information that you want; but doesn't know sh*t about what information would be interesting to retrieve. Or whether it's a good idea to keep some information X in the database, considering the various business, legal, social, cost perspectives.
> Do my managers know what they're doing?
Here's the thing: I believe nobody _really_ does. Sure, some know more than others, but in absolute terms, we're all basically guessing. That's why people insist on engineers that "show initiative" - not because they're always right, but in an environment where we don't _really_ know what we're doing, people yelling different perspectives are valuable.
However, as mentioned above - not all senior engineers want or are inclined to show this kind of initiative; and it's unfair to penalize those kinds of engineers, because we _need_ the different types of personalities.
[1] FWIW I believe the reality is , always, that you need to (A) work on a successful project; and (B) be generally liked by your colleagues and maybe managers. For very senior titles, also (C) have a large network of connections within the company - i.e. work on many things, or on one thing but a thing that is used by many teams/ really popular)
That is why it is so empowering to have options. I have two employers: one is among the largest and most profitable companies in the US and the other is US Army. In one of those initiative and leadership are rewarded at every level. That makes things interesting because it provides the freedom to rapidly experiment and prototype leadership to empower people the way I experiment with a side code project. In this environment the people you are leading are more eager to learn new things and be creative than my corporate coworkers that need a framework to do anything and panic at the slightest hint of originality.
That's a better way of putting it.
> There is an assumption that "old" means "experienced" which is not necessarily true.
Agreed
> They should be judged by their skills, the same way the young ones are being judged.
Disagree, but this is my subjective opinion. Old people in general are not able to keep up with young people for many reasons. My personal stance is we shouldn't compare them as equals, but rather try to get the most out of everyone. The baseline for judging someone (to be hired or to stay in a job) should depend on the effort they put in. Actual performance should be taken into account when deciding on promotions and bonuses. This would create an environment safe for old people to keep their jobs until they retire, but also fair to people of any age to get higher salaries and roles based on their skills.
Agreed
> They should be judged by their skills, the same way the young ones are being judged.
Disagree, but this is my subjective opinion. Old people in general are not able to keep up with young people for many reasons. My personal stance is we shouldn't compare them as equals, but rather try to get the most out of everyone. The baseline for judging someone (to be hired or to stay in a job) should depend on the effort they put in. Actual performance should be taken into account when deciding on promotions and bonuses. This would create an environment safe for old people to keep their jobs until they retire, but also fair to people of any age to get higher salaries and roles based on their skills.
Treating people differently based on the class they belong in, in this case age, is the definition of discrimination.
Firstly I am all in for discrimination that results in positive effects for people in need (as long as it is reasonable and not blind benefits for the sake of suposedly helping minorities)
However, my solution does not judge people differently based on age. It judges everyone in a way that allows old people to fairly compete with young people on the basis of effort put in rather than pure skills/performance output.
However, my solution does not judge people differently based on age. It judges everyone in a way that allows old people to fairly compete with young people on the basis of effort put in rather than pure skills/performance output.
We are talking about technical abilities...if you discriminate outside of that, including age, I would whole heartedly call that the bad kind of discrimination.
I am really not sure why my point isn't clear. I am not judging people differently based on age. I observe that skills/performance is not a fair metric for old people to compare against young ones. Thus, in order to create a field of fair competition I argue that for the baseline desicisons (getting and keeping a job) people of all ages should be judged on the effort they put in, a fair metric for all ages. Then comes the second layer of judgement based on skills which decides who gets promoted or gets performance bonuses. Old people would have less chances to win in this layer of judgement but at least they can keep their jobs safe as long as they put in effort.
There's a common trope about an established worker who works really, really hard at tasks - evenings, weekends, the whole deal.
Then they retire. Someone else takes over, and they do exactly the same work in $small_percentage of the time.
So no - effort is not a good metric. Why would you be paying someone who can't do the job - or at least can't do the job well, with enough spare capacity to deal with more complex work requirements?
Of course this is a parable, but I suspect a lot of people have seen something similar happen at work at least once.
Then they retire. Someone else takes over, and they do exactly the same work in $small_percentage of the time.
So no - effort is not a good metric. Why would you be paying someone who can't do the job - or at least can't do the job well, with enough spare capacity to deal with more complex work requirements?
Of course this is a parable, but I suspect a lot of people have seen something similar happen at work at least once.
By doing that you are hurting your business by not putting the best person in that position. Also, that better person can help bring up your younger less experienced staff.
Blindly saying 'ok you are technically better, but your also old and I want young people' is what you are arguing.
That is bad discrimination.
Blindly saying 'ok you are technically better, but your also old and I want young people' is what you are arguing.
That is bad discrimination.
Positive discrimination is just discrimination, in all contexts. Older engineers don't need your charity.
Who said anything about charity? Why would you think I am charitable in this situation?
[deleted]
> However, my solution does not judge people differently based on age. It judges everyone in a way that allows old people to fairly compete with young people on the basis of effort put in rather than pure skills/performance output.
Fairly compete in...making an effort? Would you like to get operated on by a surgeon that lacks the skill necessary to perform his job but tries damn hard? Would you want to go to a concert where the string section has been working real hard on learning the material but can't read sheet music and are tone deaf? Would you want to ride the bus where the driver has been practicing all his life but can't quite drive well enough to meet a reasonable standard based on skill? Do you want to follow a basketball tournament where the winner is determined by their effort rather than their score? Why should anyone respect a workplace that is effectively a daycare for try-hards? How can such a workplace result in a good product or service?
My most favorable take on your idea is that you simply can't have thought it through.
Frankly, the whole premise that old people need to be "allowed to compete fairly" by arbitrarily judging workers on some other merit than the quality of their work strikes me as incredibly patronizing. It's this attitude that leads to age discrimination in the first place, not that old people somehow can't produce quality work.
Instead of fucking up the workplace by introducing perverse incentives, consider socialized efforts that can maintain a sense of security for people that for one reason or another can't perform the work available to them to a reasonable standard. Pensions, unemployment insurance, disability insurance...that kind of thing.
Fairly compete in...making an effort? Would you like to get operated on by a surgeon that lacks the skill necessary to perform his job but tries damn hard? Would you want to go to a concert where the string section has been working real hard on learning the material but can't read sheet music and are tone deaf? Would you want to ride the bus where the driver has been practicing all his life but can't quite drive well enough to meet a reasonable standard based on skill? Do you want to follow a basketball tournament where the winner is determined by their effort rather than their score? Why should anyone respect a workplace that is effectively a daycare for try-hards? How can such a workplace result in a good product or service?
My most favorable take on your idea is that you simply can't have thought it through.
Frankly, the whole premise that old people need to be "allowed to compete fairly" by arbitrarily judging workers on some other merit than the quality of their work strikes me as incredibly patronizing. It's this attitude that leads to age discrimination in the first place, not that old people somehow can't produce quality work.
Instead of fucking up the workplace by introducing perverse incentives, consider socialized efforts that can maintain a sense of security for people that for one reason or another can't perform the work available to them to a reasonable standard. Pensions, unemployment insurance, disability insurance...that kind of thing.
> Would you like to get operated on by a surgeon that lacks the skill necessary to perform his job but tries damn hard? [...] Would you want to ride the bus where the driver has been practicing all his life but can't quite drive well enough to meet a reasonable standard based on skill?
Breaking news, this is already happening. Actually, pure performance-based judgement drives incapable people to hide their inability to perform the task at hand leading to bad results (instead of facing the reality in a safe environment that would help them get better at what they do).
> Why should anyone respect a workplace that is effectively a daycare for try-hards? How can such a workplace result in a good product or service?
This sentence assumes the majority of workers are incapable try-hards which is plain false. A few less-skilled try-hards aren't going to ruin any service. Again, this is already the case in the world we live in.
> Frankly, the whole premise that old people need to be "allowed to compete fairly" by arbitrarily judging workers on some other merit than the quality of their work strikes me as incredibly patronizing.
I clearly stated two layers of judgement. A baseline for effort and a second layer for career progression based on lerformance, both age-agnostic. Never proposed a system discriminating against age. Get over it please.
> consider socialized efforts that can maintain a sense of security for people that for one reason or another can't perform the work available to them to a reasonable standard. Pensions, unemployment insurance, disability insurance...that kind of thing.
Ok so I proposed a system that would ensure someone has a job as long as they are not a lazy-a$$ (but probably wouldn't be able to climb up the career ladder if they don't have the skills), always age-agnostic, but that is somehow not a socialized effort to provide security? Ok.
Breaking news, this is already happening. Actually, pure performance-based judgement drives incapable people to hide their inability to perform the task at hand leading to bad results (instead of facing the reality in a safe environment that would help them get better at what they do).
> Why should anyone respect a workplace that is effectively a daycare for try-hards? How can such a workplace result in a good product or service?
This sentence assumes the majority of workers are incapable try-hards which is plain false. A few less-skilled try-hards aren't going to ruin any service. Again, this is already the case in the world we live in.
> Frankly, the whole premise that old people need to be "allowed to compete fairly" by arbitrarily judging workers on some other merit than the quality of their work strikes me as incredibly patronizing.
I clearly stated two layers of judgement. A baseline for effort and a second layer for career progression based on lerformance, both age-agnostic. Never proposed a system discriminating against age. Get over it please.
> consider socialized efforts that can maintain a sense of security for people that for one reason or another can't perform the work available to them to a reasonable standard. Pensions, unemployment insurance, disability insurance...that kind of thing.
Ok so I proposed a system that would ensure someone has a job as long as they are not a lazy-a$$ (but probably wouldn't be able to climb up the career ladder if they don't have the skills), always age-agnostic, but that is somehow not a socialized effort to provide security? Ok.
So if I make a huge effort yet manage to remain incompetent and underperforming for my role, I should be kept on the payroll as a sort of charity?
It makes me happy to see folks not dogpiling on you. I'll try to be similarly gentle.
It seems to me maybe you've got the hero mentality. That sacrifice == hours spent grinding == commitment to the job. "Effort" to you is a measurement of love.
That totally described me in my 20's and 30's. One day, after acquiring the necessary skills, I woke up and learned that it didn't make sense to grind like that anymore. Also, long hours is bad for the mental health.
I switched to "work smarter, not harder" mode and learned about TDD and Agile. I got better at my craft and earned respect from my peers for encouraging them to get better too.
Finally, I had a really eye-opening experience with an older developer a few years ago. He was a contractor and owned a gym. He always took off at 3pm to go train his folks and work his other business without asking/telling anyone. He was gruff and a little bit intimidating physically. He even had terrible typing skills: he typed with two fingers like a kid! Not sure if that was a dexterity handicap or if he just never learned to type, probably the former, but it still pissed me off because he was SOOO SLOW!
It surprised me a bit when he rolled off that he lasted his whole contract and didn't wash out sooner. It surprised me at the time he had such deep networks in the company: VP's knew him and worked with him years earlier and they had lively random conversations. It surprises me now that his contributions to the codebase have endured - he just got a lot done in less lines of code. I think fondly now at the conversations we had, not just on coding, but on parenting, politics, physical health and strength training, military service, and just ... diverse, weird thoughts from my parent's generation.
Think of yourself and your beloved company as The Borg. Your job is to incorporate the technical distinctiveness of aliens into your collective. If people you run across are turds, and you have a culture of hard-charging success, they'll wash out pretty quickly. Just let go of effort and efficiency as metrics - beancounters can concern themselves with that. Focus on winning over the long term.
It seems to me maybe you've got the hero mentality. That sacrifice == hours spent grinding == commitment to the job. "Effort" to you is a measurement of love.
That totally described me in my 20's and 30's. One day, after acquiring the necessary skills, I woke up and learned that it didn't make sense to grind like that anymore. Also, long hours is bad for the mental health.
I switched to "work smarter, not harder" mode and learned about TDD and Agile. I got better at my craft and earned respect from my peers for encouraging them to get better too.
Finally, I had a really eye-opening experience with an older developer a few years ago. He was a contractor and owned a gym. He always took off at 3pm to go train his folks and work his other business without asking/telling anyone. He was gruff and a little bit intimidating physically. He even had terrible typing skills: he typed with two fingers like a kid! Not sure if that was a dexterity handicap or if he just never learned to type, probably the former, but it still pissed me off because he was SOOO SLOW!
It surprised me a bit when he rolled off that he lasted his whole contract and didn't wash out sooner. It surprised me at the time he had such deep networks in the company: VP's knew him and worked with him years earlier and they had lively random conversations. It surprises me now that his contributions to the codebase have endured - he just got a lot done in less lines of code. I think fondly now at the conversations we had, not just on coding, but on parenting, politics, physical health and strength training, military service, and just ... diverse, weird thoughts from my parent's generation.
Think of yourself and your beloved company as The Borg. Your job is to incorporate the technical distinctiveness of aliens into your collective. If people you run across are turds, and you have a culture of hard-charging success, they'll wash out pretty quickly. Just let go of effort and efficiency as metrics - beancounters can concern themselves with that. Focus on winning over the long term.
Hey mate. Sorry for the missunderstanding. When I said effort I meant just ensuring we're not dealing with a lazy person who slacks having the safety of a job. By no means do I want people competing by putting in more hours.
I have learned that putting in more hours does not result in the benefits one would hope for very early on.
Thanks for your comment though, it made me understand why everyone is super freaking pissed about my comment. Have I understood that earlier I would have edited it to avoid all this mess
I have learned that putting in more hours does not result in the benefits one would hope for very early on.
Thanks for your comment though, it made me understand why everyone is super freaking pissed about my comment. Have I understood that earlier I would have edited it to avoid all this mess
Judge by effort? You gotta be kidding.
I agree that age doesn't mean experience. I work in a company with a small development team and we're all around the same age group with no young programmers.
In thios group we have a programmer in his early 40s, who has been programming for years, that I would still consider a "junior" programmer. He can usually perform a task but needs more guidance and checking than the other members if the team, most of which have been there time.
On the other side we also had a developer work there a few years back that was in his late 50s and wrote some of the worse looking code I've ever seen. Fortunatly he didn't last long and none of his code is running in production.
In thios group we have a programmer in his early 40s, who has been programming for years, that I would still consider a "junior" programmer. He can usually perform a task but needs more guidance and checking than the other members if the team, most of which have been there time.
On the other side we also had a developer work there a few years back that was in his late 50s and wrote some of the worse looking code I've ever seen. Fortunatly he didn't last long and none of his code is running in production.
What exactly is the meaning of "On the other side" here?
I believe the best equivalent phrase would be "on the other hand" or "in contrast"
I've met those guys.
The 50-something who had been in the same role 37 years, who was laid off and when hired into a new company, just couldn't adapt. The 40-something who's fine to do maintenance and the odd enhancement, but you wouldn't trust to do a major refactor or a large chunk of green-field.
Some people just aren't as able, find themselves a comfort zone and stick to it.
So even experience doesn't necessarily mean experience :)
(This isn't to say such people aren't useful, that's a different measure.)
The 50-something who had been in the same role 37 years, who was laid off and when hired into a new company, just couldn't adapt. The 40-something who's fine to do maintenance and the odd enhancement, but you wouldn't trust to do a major refactor or a large chunk of green-field.
Some people just aren't as able, find themselves a comfort zone and stick to it.
So even experience doesn't necessarily mean experience :)
(This isn't to say such people aren't useful, that's a different measure.)
Yes it's not about valuing age, but it is about valuing experience. Sometimes raw talent and problem solving ability is the most important quality to look for, but sometimes experience in the field is incredibly relevant and valuable, and can't be replaced by raw talent.
If you're young, you fit in a narrow spectrum of experience with a relatively low upper bound.
If you're old, then the spectrum of possible experience is much broader. You could range from being totally inexperienced to being extremely experienced.
Also, as I get older, I realize that talent plays a significant part (which is independent of age). But there is a huge problem that almost all companies don't know how to identify technical talent; they focus on the wrong attributes like ability to perform under pressure and ability to recall details. Companies should be focusing on a candidate's ability to synthesize information, to rank problems based on their importance and to communicate simply and clearly; that is the real valuable talent.
If you're old, then the spectrum of possible experience is much broader. You could range from being totally inexperienced to being extremely experienced.
Also, as I get older, I realize that talent plays a significant part (which is independent of age). But there is a huge problem that almost all companies don't know how to identify technical talent; they focus on the wrong attributes like ability to perform under pressure and ability to recall details. Companies should be focusing on a candidate's ability to synthesize information, to rank problems based on their importance and to communicate simply and clearly; that is the real valuable talent.
>Companies should be focusing on a candidate's ability to synthesize information, to rank problems based on their importance and to communicate simply and clearly
So, from my non-tech perspective, that's just every single job at every single employer. Any position I've had that has been in charge of hiring people - I am acutely aware that I can teach the position. I can teach the technical aspects and detail knowledge of how to do a job. What I can't teach is the ability to prioritize, critically think, and communicate appropriately. Those are real talents.
I guess what I'm saying is - tech companies are garbage at evaluating for those things, because (I would argue) all/nearly all companies are garbage at evaluating for those things. It doesn't matter if it's a tech company, garbage company, or insurance company - they're all (again, my experience) equally garbage at finding those skills in people through their standard interview processes.
If you figure out how to implement a standard interview process to evaluate for the three things you list, you will be the world's first trillionaire.
So, from my non-tech perspective, that's just every single job at every single employer. Any position I've had that has been in charge of hiring people - I am acutely aware that I can teach the position. I can teach the technical aspects and detail knowledge of how to do a job. What I can't teach is the ability to prioritize, critically think, and communicate appropriately. Those are real talents.
I guess what I'm saying is - tech companies are garbage at evaluating for those things, because (I would argue) all/nearly all companies are garbage at evaluating for those things. It doesn't matter if it's a tech company, garbage company, or insurance company - they're all (again, my experience) equally garbage at finding those skills in people through their standard interview processes.
If you figure out how to implement a standard interview process to evaluate for the three things you list, you will be the world's first trillionaire.
I agree with you as far as these general skills, but I think that the value of applicable experience should not be discounted.
For example, I work with a firmware developer in his 50’s, and he is so efficient it is scary. He’s basically seen it all by now, and he has deeply ingrained work habits which let him solve problems extremely quickly.
That’s not to say that every developer with X years of experience will automatically be great in that way, but if you can find someone who has years of experience producing exactly the type of work you need, this should be viewed as a huge advantage.
It’s like if you are looking to hire a carpenter to built a piece of custom furniture: you can and should consider general qualities like strength, manual dexterity and attention to detail. But if you can find someone with years of muscle memory building exactly that type of furniture, they are almost guaranteed to get the best result.
For example, I work with a firmware developer in his 50’s, and he is so efficient it is scary. He’s basically seen it all by now, and he has deeply ingrained work habits which let him solve problems extremely quickly.
That’s not to say that every developer with X years of experience will automatically be great in that way, but if you can find someone who has years of experience producing exactly the type of work you need, this should be viewed as a huge advantage.
It’s like if you are looking to hire a carpenter to built a piece of custom furniture: you can and should consider general qualities like strength, manual dexterity and attention to detail. But if you can find someone with years of muscle memory building exactly that type of furniture, they are almost guaranteed to get the best result.
I think that on average, an older experienced developer will be more skilled than a younger one, even with less natural talent. Experience is really important.
Some people have 10 years of experience. Other people have 1 year of experience 10 times.
Ten years of experience in one tech stack will give you mastery. 1 year changes with a new language / framework / tools every time will mean you are forever a novice.
If you know 10 different tech stacks you probably have immense breadth and can learn/do new things easily. That’s is incredibly valuable. There is a massive difference when you are learning a new stack for 11th time vs 2nd or 3rd time. Sometimes you need people with deep mastery of some specific, sometimes you need people who have seen everything, can learn anything, and synthesize a broad view.
That is not entirely true. After learning the n-th stack and knowing the knowledge will likely sputter out in a couple of years cycles, one is likely to learn enough to get done what needs to be done. As someone points out, few out there are true experts if they're constantly learning a new stack. And also people who want to learn all the time do get bored of learning the same thing, a lot of them branch out in different directions that are a lot less shapeshifting.
Ideally I preferred learning the technology for a few years then steeping back and reaping the benefits and do stuff with it. But, there is a fear that not keeping up leads to obsolescence on the job market so we're in this constant cycle of learning new things with diminishing returns
Ideally I preferred learning the technology for a few years then steeping back and reaping the benefits and do stuff with it. But, there is a fear that not keeping up leads to obsolescence on the job market so we're in this constant cycle of learning new things with diminishing returns
First, I accept that there are cases where extreme specialization is important. I just think these cases are few and far between.
The main skill for senior/staff swe is not in knowing or not knowing some technology, but rather
1. Picking things up quickly
2. Understanding/recognizing generalizable patterns and best practices in any tech.
Almost no job requires some extreme expert level knowledge of language/framework minutiae (obviously you do need some experience in particular tech). Almost every non-greenfield job has a ton of custom tech that has to be learned. Almost every green-field job needs someone with immense breadth.
Having been exposed to very many things people get to naturally see recurring patterns/best practices. When they see a new tech they are able to understand why choices were made. When new tech needs to be made they can draw from broad experience in what others did best. I really think this is most of the eng value of staff swe.
The main skill for senior/staff swe is not in knowing or not knowing some technology, but rather
1. Picking things up quickly
2. Understanding/recognizing generalizable patterns and best practices in any tech.
Almost no job requires some extreme expert level knowledge of language/framework minutiae (obviously you do need some experience in particular tech). Almost every non-greenfield job has a ton of custom tech that has to be learned. Almost every green-field job needs someone with immense breadth.
Having been exposed to very many things people get to naturally see recurring patterns/best practices. When they see a new tech they are able to understand why choices were made. When new tech needs to be made they can draw from broad experience in what others did best. I really think this is most of the eng value of staff swe.
Ten years of experience in one tech stack that has fallen by the wayside means you're outclassed by the developer with 2 years of relevant experience.
And some people have 10 years of just not very useful experience.
Not the same year 10 times but 10 discrete, non-overlapping years.
Not the same year 10 times but 10 discrete, non-overlapping years.
Most people have 1 month of experience repeated 120 times. This is the only way to be employed and not starve.
I agree with this. I've known some people who've been coding for 15-20 years who just coast, and end up in senior positions because of how long they've been employed when their skills are really at the level of a 2 year junior.
It's even worse in front-end, because that means their skills are that of a 2 year junior 10 years ago, they don't have any of the skills with new frameworks and techniques. If you want sloppy bootstrap laden html/css and jQuery, they're your person though.
It's even worse in front-end, because that means their skills are that of a 2 year junior 10 years ago, they don't have any of the skills with new frameworks and techniques. If you want sloppy bootstrap laden html/css and jQuery, they're your person though.
Out of interest what skills are you talking about? I am an old fart by IT standards and i have come to realise that being able to come up with an algorithm randomly is not such a useful skill considering how infrequently we actually have to do it. Being able to say "no" and getting on with other developers are far more valuable than being able to solve a soduku puzzle once you have acquired a certain level of knowledge. After that it should be about managing complexity.
>i have come to realise that being able to come up with an algorithm randomly is not such a useful skill considering how infrequently we actually have to do it.
This isn't what I'm talking about - I'm talking domain specific skill. If you're a frontend developer for instance, you should understand the new language features of JavaScript that came out in 2015-2016 and be able to use them. You should know how to use flexbox for CSS instead of floats for layout (IMO)
If you're a senior developer still writing code every day, you have to keep up with that stuff. You're ultimately responsible for the codebase in a way that junior/mid devs are not and if you don't understand large aspects of how it works you can't be effective.
It doesn't help that people who stagnate like this usually weren't very good at/engaged with their jobs to begin with. They're usually senior in name only, where their managers know not to actually assign them stuff that matters.
This isn't what I'm talking about - I'm talking domain specific skill. If you're a frontend developer for instance, you should understand the new language features of JavaScript that came out in 2015-2016 and be able to use them. You should know how to use flexbox for CSS instead of floats for layout (IMO)
If you're a senior developer still writing code every day, you have to keep up with that stuff. You're ultimately responsible for the codebase in a way that junior/mid devs are not and if you don't understand large aspects of how it works you can't be effective.
It doesn't help that people who stagnate like this usually weren't very good at/engaged with their jobs to begin with. They're usually senior in name only, where their managers know not to actually assign them stuff that matters.
But why?
Do new languages, new language features, new frameworks, new methodologies necessarily add business value? Or are they sometimes just being used because they are new and shiny? Requiring people to learn new tools simply because they are new (to keep up, in your words) just puts everyone on a treadmill. One distinguishing attribute I'd expect from a "senior" developer is the ability to quickly evaluate new technologies, choose and focus on what actually provides business value and have the discipline to ignore the rest. It is possible to be a top performing, highly productive developer today by very effectively using 10 year old technologies.
Do new languages, new language features, new frameworks, new methodologies necessarily add business value? Or are they sometimes just being used because they are new and shiny? Requiring people to learn new tools simply because they are new (to keep up, in your words) just puts everyone on a treadmill. One distinguishing attribute I'd expect from a "senior" developer is the ability to quickly evaluate new technologies, choose and focus on what actually provides business value and have the discipline to ignore the rest. It is possible to be a top performing, highly productive developer today by very effectively using 10 year old technologies.
>Do new languages, new language features, new frameworks, new methodologies necessarily add business value?
Sometimes they do, sometimes they don't. But the tech stack will eventually come to include these new things whether you like it or not. And even if somehow you're able to stop that from happening, eventually it will become very difficult to hire junior developers with experience in old frameworks and eventually those frameworks stop getting supported and community contributions since so many other shops drop it.
The two things I listed specifically are actual fundamental changes to CSS and JavaScript, not fly by night frameworks and they both do add a lot of value.
>Requiring people to learn new tools simply because they are new (to keep up, in your words) just puts everyone on a treadmill.
I actually do sympathize with this way of thinking, and I used to agree with it. But I've come to understand how misguided it really is. Every well paying knowledge worker profession requires updating your skills from time to time. Doctors have to learn new guidelines for treatment and different ways to do surgeries/procedures. Lawyers have to brush up on developments in case law etc...
Programming already has an extreme advantage over a lot of these professions. There's no licensing board, you don't even need a degree if you can pass the interview. It's silly to think that we should also be immune to honing our craft and changing with the times.
If you're a software engineer, you should have the expectation that you're going to need to do a little bit of career development every year. I don't mean spending 10+ hours a week on it, but to use the examples above... I realized in like 2016 that I didn't know Flexbox and that was pretty much the new standard for how layout was going to happen in CSS. So I made myself learn it. And not only does that update my skills, Flexbox is actually way better to lay elements out on a page with than the old way. It's made building html/css views out much quicker.
Sometimes they do, sometimes they don't. But the tech stack will eventually come to include these new things whether you like it or not. And even if somehow you're able to stop that from happening, eventually it will become very difficult to hire junior developers with experience in old frameworks and eventually those frameworks stop getting supported and community contributions since so many other shops drop it.
The two things I listed specifically are actual fundamental changes to CSS and JavaScript, not fly by night frameworks and they both do add a lot of value.
>Requiring people to learn new tools simply because they are new (to keep up, in your words) just puts everyone on a treadmill.
I actually do sympathize with this way of thinking, and I used to agree with it. But I've come to understand how misguided it really is. Every well paying knowledge worker profession requires updating your skills from time to time. Doctors have to learn new guidelines for treatment and different ways to do surgeries/procedures. Lawyers have to brush up on developments in case law etc...
Programming already has an extreme advantage over a lot of these professions. There's no licensing board, you don't even need a degree if you can pass the interview. It's silly to think that we should also be immune to honing our craft and changing with the times.
If you're a software engineer, you should have the expectation that you're going to need to do a little bit of career development every year. I don't mean spending 10+ hours a week on it, but to use the examples above... I realized in like 2016 that I didn't know Flexbox and that was pretty much the new standard for how layout was going to happen in CSS. So I made myself learn it. And not only does that update my skills, Flexbox is actually way better to lay elements out on a page with than the old way. It's made building html/css views out much quicker.
But there are other considerations. The constraint solver in flexbox used to be a lot slower to render than other layout methods. And if you have experience in non-web UI frameworks, you can see that flexbox isn't that different from things you can find in Swing and Qt, so you can just wait a while and learn it in a day when you need it.
I've seen nigh unmaintainable web apps that were entirely laid out in really overwrought nested flexboxes, when using utterly basic HTML elements like <p> and <h3> and <dl> with a bit of CSS would have rendered faster, been developed faster, worked in older browsers, and worked better with accessibility tech.
So really, flexbox is just another new old thing, and what matters is the concept of constraint-based layout as one tool out of many. If it's the first new thing you encounter in your career, it's worth learning it because it's there, but remember that it's just another spoke on an ever-turning wheel.
I've seen nigh unmaintainable web apps that were entirely laid out in really overwrought nested flexboxes, when using utterly basic HTML elements like <p> and <h3> and <dl> with a bit of CSS would have rendered faster, been developed faster, worked in older browsers, and worked better with accessibility tech.
So really, flexbox is just another new old thing, and what matters is the concept of constraint-based layout as one tool out of many. If it's the first new thing you encounter in your career, it's worth learning it because it's there, but remember that it's just another spoke on an ever-turning wheel.
Often times none of that is tested during the interview though, so you don't know whether the person is knowledgable on any of those or other frontend specifics until you've hired them because they were able to pass an leetcode DS&A phonescreen and 3-4 leetcode DS&A onsite rounds.
I've noticed this is changing (spearheaded by FAANG & other top tech companies it seems) - there are frontend specific tracks that test more JavaScript knowledge than leetcode puzzles.
But as usual, if there is a cutting edge, there are many more laggards, and I'd say many companies are still doing leetcode DS&A for frontend too.
I've noticed this is changing (spearheaded by FAANG & other top tech companies it seems) - there are frontend specific tracks that test more JavaScript knowledge than leetcode puzzles.
But as usual, if there is a cutting edge, there are many more laggards, and I'd say many companies are still doing leetcode DS&A for frontend too.
It really just depends on where you're interviewing. A lot of places that hire software engineers don't ask algorithmic questions at all.
It's really impossible to generalize about most aspects of this career in my opinion. There are no hard rules about anything, even hiring.
I think about this in relation to the "skill gap" in programming a lot. There are people who work in very senior positions in software development who couldn't do a LeetCode easy or a FizzBuzz. They don't read articles about how to get better at programming or about concepts like DRY etc... but maybe they do the very specific thing their employer wants well enough, that combined with their long tenure and relationships with other people they are pretty much lifers.
That's why I laugh when I see articles on Hacker News articles where it says if you don't do X Y or Z you're not a "real" programmer. Meanwhile a huge swath of people employed as programmers haven't even heard of a lot of this stuff, much less actually used it.
It's really impossible to generalize about most aspects of this career in my opinion. There are no hard rules about anything, even hiring.
I think about this in relation to the "skill gap" in programming a lot. There are people who work in very senior positions in software development who couldn't do a LeetCode easy or a FizzBuzz. They don't read articles about how to get better at programming or about concepts like DRY etc... but maybe they do the very specific thing their employer wants well enough, that combined with their long tenure and relationships with other people they are pretty much lifers.
That's why I laugh when I see articles on Hacker News articles where it says if you don't do X Y or Z you're not a "real" programmer. Meanwhile a huge swath of people employed as programmers haven't even heard of a lot of this stuff, much less actually used it.
"where" is the key word here I think. But at least in the vicinity of the major US coastal cities (SFBA, Seattle, NYC, probably LA and a few others) where a lot of tech jobs are concentrated, I would say most companies are in fact, leetcoding candidates to some degree.
Half my team is in London (big bank), as is my manager, and I know they leetcode candidates there too - and we're not even a tech company or elite financial firm, just a boring big conservative bank.
If you're looking for a job in this day and age, I think it's safer to assume you're going to get leetcoded and be prepared. Rather than try to find the rarer and rarer company that doesn't leetcode you.
Half my team is in London (big bank), as is my manager, and I know they leetcode candidates there too - and we're not even a tech company or elite financial firm, just a boring big conservative bank.
If you're looking for a job in this day and age, I think it's safer to assume you're going to get leetcoded and be prepared. Rather than try to find the rarer and rarer company that doesn't leetcode you.
> If you're a senior developer still writing code every day, you have to keep up with that stuff.
Can you give me an example of a task that I couldn't have done with ten year old tech?
Will it automatically be better because I am using this years chosen framework (or will it be more likely that there are unforeseen problems because of not using a mature technology).
Can you give me an example of a task that I couldn't have done with ten year old tech?
Will it automatically be better because I am using this years chosen framework (or will it be more likely that there are unforeseen problems because of not using a mature technology).
Not the OP but I largely look for experience with CI/CD workflows and release management, unit/integration/systems testing that doesn't cripple R&D, QA, distributed systems beyond a webserver & DB, and just general "philosophy of software engineering" type stuff like an understanding of the factors that led to the evolution from monolith to microservice, agile/scrum/management fad of the week, and how to make tech tradeoffs based on business goals. These are largely soft skills, not algorithmic trivia.
Unfortunately, there's no one size fits all worksheet for those soft skills that HR can hand out to interviewers, so everyone gets lazy and falls back to the whiteboard BS.
Unfortunately, there's no one size fits all worksheet for those soft skills that HR can hand out to interviewers, so everyone gets lazy and falls back to the whiteboard BS.
Frontend dev is a really good example of a field that is all short strings and missing the longer trends. It doesn't matter what framework you use, or no framework at all, if the site can be maintained, the site is fast, and it looks good in all the browsers you are targeting. Bootstrap, jQuery, React, Vue, etc can all be sloppy, or they can be used incisively.
For sake of argument though, can we assume all “old” programmers in this case are ones that have been doing this a long time and are actually competent? I’m not disagreeing with you, but I know those are in the minority of us “old” programmers. “Old” vs “Young” can be a measure of experience.
There's also old with lots of experience but it's 20 years of doing the same thing, or 10 x 2 years experience vs. 20 years of xp
If the current trend in the software engineering market continues, in 2040 we'll most likely have much more profiles with 10x2 years or 20x1 year than 1x20 years. I have the impression that really few companies value the latter nowadays.
I've also seen seniors having 10 times one year of experience as opposed to having 10 years of experience!
We should distinguish age from experience from skill.
That said, want to call out that experience in other fields can sometimes be tremendously valuable! (... but isn't guaranteed to be)
That said, want to call out that experience in other fields can sometimes be tremendously valuable! (... but isn't guaranteed to be)
> one day I'll be in their place. I want them to be treated the same way I will be treated.
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... :)
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... :)
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!
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!
If you bail every three or whatever year you kinda never get to see a big project start to finnish.
And if you don't, you kinda never get to work on more than one thing, and therefore grow and cross-pollinate ideas from different domains.
It's one of the toughest things about working as an employee if you're interested in more than one area. That's why I switched to freelance consulting, where I found the variety far more enjoyable.
It looks very likely I'm moving back to "permanent" employment soon for stability and access to more interesting "big" corporate projects that I found as an independent. (My valiant initiatives to struggle on intermittent income and use the free time to transform the hardware world into an open source hardware world don't seem to be needed any more; better people than me are doing a great job!)
But I have mixed feelings from a nagging doubt that I'll be stuck doing one thing all the time, until I have the temerity to leave the employer. We'll see, I do have an open mind and I'll give it enough time to find out, but it's at the back of my mind.
It's one of the toughest things about working as an employee if you're interested in more than one area. That's why I switched to freelance consulting, where I found the variety far more enjoyable.
It looks very likely I'm moving back to "permanent" employment soon for stability and access to more interesting "big" corporate projects that I found as an independent. (My valiant initiatives to struggle on intermittent income and use the free time to transform the hardware world into an open source hardware world don't seem to be needed any more; better people than me are doing a great job!)
But I have mixed feelings from a nagging doubt that I'll be stuck doing one thing all the time, until I have the temerity to leave the employer. We'll see, I do have an open mind and I'll give it enough time to find out, but it's at the back of my mind.
While you are right in that you shouldn't stay on the same place forever, there is definitely very huge and important lessons in staying at a place long enough that you don't only have to deliver something, but also get to maintain it over time.
I've found I actually got to stay "long enough" to maintain delivered projects much more an independent than as an employee.
As an employee I wasn't able to maintain projects longer than 2-3 years even when I wanted, due to fixed term (academic) employment contracts, redundancy, projects getting terminated due to business decisions, and reassignment to different projects.
As an independent I found I've had very long term ongoing client relationships (7+ years for one, 5 years for another so far), where they call me back to maintain their products for years after shipping.
During that, it's fine and even expected that I have overlapping newer work with other clients.
So I'm expected to maintain a number of things long after shipping, and that's what I expect to be called to do if I did a good job of delivering the project in the first place.
I think my experience of maintenance and dogfooding may be the opposite of what people think of, when they think about employees vs. independents.
As an employee I wasn't able to maintain projects longer than 2-3 years even when I wanted, due to fixed term (academic) employment contracts, redundancy, projects getting terminated due to business decisions, and reassignment to different projects.
As an independent I found I've had very long term ongoing client relationships (7+ years for one, 5 years for another so far), where they call me back to maintain their products for years after shipping.
During that, it's fine and even expected that I have overlapping newer work with other clients.
So I'm expected to maintain a number of things long after shipping, and that's what I expect to be called to do if I did a good job of delivering the project in the first place.
I think my experience of maintenance and dogfooding may be the opposite of what people think of, when they think about employees vs. independents.
While I won't ask why the multiple downvotes, because that's discouraged here on HN, I will express considerable surprise. Reading over it again, it doesn't strike me as a disagreeable comment, just another point of view about one type of working relationship over another.
When is a big project ever "finished" ?
If you're not delivering useful, production level stuff in under 5 years, even if it's not a 'complete' big project, then something's probably very wrong, IMHO.
If you're not delivering useful, production level stuff in under 5 years, even if it's not a 'complete' big project, then something's probably very wrong, IMHO.
That depends on what space you are in. In an embedded space 5 years can be half way through a products lifetime. You usually have something fairly close and mostly done in 1-2 years. But the next 2-3 years is finding out all sorts of quirks in a real world physical environment.
I stayed at one company for about 20 years. Every 2-3 years the job would radically change into something else. So I stayed for awhile. It was good for them as they could come back to me for odd decisions made and how to work around them, and for me I could work on new tech every few years. But for me on ye-ol-resume it looks like 20. My current job things are not changing like that so I will need to move on to get diff exp in something else now. The org is just not designed in the same way and it would be easy to silo yourself into a niche that melts in 10 years. You can argue with your boss to you are blue in the face about moving on and getting more challenging/different jobs. But at the end of the day they need to ship their product and they will usually not look out for you.
I stayed at one company for about 20 years. Every 2-3 years the job would radically change into something else. So I stayed for awhile. It was good for them as they could come back to me for odd decisions made and how to work around them, and for me I could work on new tech every few years. But for me on ye-ol-resume it looks like 20. My current job things are not changing like that so I will need to move on to get diff exp in something else now. The org is just not designed in the same way and it would be easy to silo yourself into a niche that melts in 10 years. You can argue with your boss to you are blue in the face about moving on and getting more challenging/different jobs. But at the end of the day they need to ship their product and they will usually not look out for you.
Three years should be enough for a decent project to go from inception to production. Realistically you will join a big project in mid-progress so three years is def enough.
I agree with grandop that 5 years is prob the time limit before moving becomes very important unless (1) you are in organizational leadership (you drive vision and with success get fu money) (2) you are being continuously rapidly promoted in a large company.
I agree with grandop that 5 years is prob the time limit before moving becomes very important unless (1) you are in organizational leadership (you drive vision and with success get fu money) (2) you are being continuously rapidly promoted in a large company.
What makes you think, that new ideas, techniques, skills, etc. do not reach old places?
I've seen a number of examples in my time, smart people who found a niche and then let the world pass them by.
Senior engineers, heads of engineering, architects, generally people who've been in one place for 20+ years, often who have been in charge of technical direction that whole time. Some of them even asked me for advice on getting out... These people tend to be respected within their organisation and have a lot of very narrow-focused domain knowledge, but because they don't move around they haven't had to think their way through any brand new challenges, or learn new techniques and systems.
It's not inevitable, but it is a pattern I've observed.
Senior engineers, heads of engineering, architects, generally people who've been in one place for 20+ years, often who have been in charge of technical direction that whole time. Some of them even asked me for advice on getting out... These people tend to be respected within their organisation and have a lot of very narrow-focused domain knowledge, but because they don't move around they haven't had to think their way through any brand new challenges, or learn new techniques and systems.
It's not inevitable, but it is a pattern I've observed.
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.
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.
There is no old grizzled sarge because personal computers have been out for less than 20 years.
PCs came out in the early 2000s?
Sounds about right. Could say late 1990s if you were in the right location in an affluent family.
I started college in 1982, majoring in math and physics. The professors all had personal computers on their desks. I bought myself one for under $1000 the next year. By the time I graduated, even the computer science professors were using personal computers, though student assignments were still done on the mainframe.
Where were you living?
I grew up in Michigan and went to one of the many small liberal arts colleges in the state.
You’re off by a couple of decades: https://en.wikipedia.org/wiki/History_of_personal_computers
You could be thinking of “personal computer with Internet access”? That’s closer timing as long as you want something more open / capable than the various dialup services which were popular with personal computer users starting in the 1980s.
You could be thinking of “personal computer with Internet access”? That’s closer timing as long as you want something more open / capable than the various dialup services which were popular with personal computer users starting in the 1980s.
I did some searching. Most stats suggest that by 1985, more than 10% of American households, and a slight majority of small businesses, had a personal computer.
By 2001, it's 60% and nearly 100%. I agree with the others. You're about two decades too late in your estimate.
By 2001, it's 60% and nearly 100%. I agree with the others. You're about two decades too late in your estimate.
In San Diego, in 1987, I attended college using Pell grants from the US government because my family was considered below the poverty line. They provided enough money to cover tuition, books, and room and board, but I lived at home and used the room-and-board money to buy an IBM PC AT clone.
This was not my first personal computer, but it was the first that literally has "Personal Computer" in the name, and is more than ten years prior to your claim.
This was not my first personal computer, but it was the first that literally has "Personal Computer" in the name, and is more than ten years prior to your claim.
The TRS-80 was $600 in 1980. That's still less than $2000 in today's dollars, in the same ballpark as a macbook, and around the same price as a VCR.
Around ‘93 or ‘94 is when we got our first home PC. We were no where close to affluent.
MS DOS was 1981. I got my vic-20 in 1984. But fair point, the actual numbers employed were tiny compared to current needs. Average experience is thin out there. The old timers clump, both in firms and geographically.
Is this an attempt at humour I’m not understanding? The eponymous Personal Computer came out in 1981, and it came in an already thriving market with the likes of the Apple ][, Commodore Pet, TI-99, etc.
Heck some of the essays from Paul Graham date from the 90s.
Heck some of the essays from Paul Graham date from the 90s.
It's hyperbole to illustrate that looking for people with 40 years of experience in personal computer is like looking for people with 10 years of kubernetes experience. You don't see any because they don't exist.
Well, there might be a handful stacked in the place the thing was initially created (they've probably long moved on though).
HN happens to be heavily centered around the valley and Apple/Microsoft, bad luck. Consider that the rest of the world can easily be a decade behind the valley.
Well, there might be a handful stacked in the place the thing was initially created (they've probably long moved on though).
HN happens to be heavily centered around the valley and Apple/Microsoft, bad luck. Consider that the rest of the world can easily be a decade behind the valley.
There are many, many, many people with close to 40 years of PC experience. The k8s example is not analogous because the set of people with adequate experience is 0, while the set for PC experience is much much much higher than 0.
20 years? You are literally MULTIPLE decades off.
20 years? You are literally MULTIPLE decades off.
I'm not sure what experience in "personal computing" would entail as opposed to specific systems like Kubernetes. You could find someone with 40+ years of experience in Unix, C, or writing 6502 assembly code, with varying degrees of relevance to modern day work. Someone who has 40 years of experience with the 8051 or PIC microcontroller could conceivably be useful today, so if you wanted your grizzled old sarge, you could have them, assuming you were willing to pay enough money or had an interesting enough project.
That's...a little off. I started out writing programs on my school's Commodore PET around 40 years ago.
Some people might regard me as grizzled, I guess.
Some people might regard me as grizzled, I guess.
TIL that my IBM PC AT clone in 1987 was not a personal computer.
Better still. Your modern PC retains backwards compatibility and emulates hardware quirks of this "not a PC".
Yeah. I started out in 1969 as an intern doing electrocardiogram analysis on a CDC 8090. It had four banks of sixteen KiB of twelve-bit core memory (yeah, little magnetic washers threaded onto a square screen of wires). Obvs 8090 assembler is now useless as a skill. But the thinking and troubleshooting skills needed to make that stuff work? Still use them every day.
Lolwut? Personal computers have definitely been around _longer_ than just 20 years. Maybe not 40, but it is ludicrous to suggest _less_ than 20 years.
You should take a look at how personal computers were affecting the economy in the 1980s.
Maybe the wikipedia article on the Digital Revolution [0], starting on the section "1969–1989: Invention of the Internet, rise of home computers" [1], or the section "Rise in digital technology use of computers, 1980–2020" [2].
> In developed nations, computers achieved semi-ubiquity during the 1980s as they made their way into schools, homes, business, and industry.
[0] https://en.wikipedia.org/wiki/Digital_Revolution
[1] https://en.wikipedia.org/wiki/Digital_Revolution#1969%E2%80%...
[2] Rise in digital technology use of computers, 1980–2020
Maybe the wikipedia article on the Digital Revolution [0], starting on the section "1969–1989: Invention of the Internet, rise of home computers" [1], or the section "Rise in digital technology use of computers, 1980–2020" [2].
> In developed nations, computers achieved semi-ubiquity during the 1980s as they made their way into schools, homes, business, and industry.
[0] https://en.wikipedia.org/wiki/Digital_Revolution
[1] https://en.wikipedia.org/wiki/Digital_Revolution#1969%E2%80%...
[2] Rise in digital technology use of computers, 1980–2020
May I ask when the place you grew up in acquired indoor plumbing?
Apple was incorporated in 1976. What do you think they did for the first 25 years of their existence?
Apple was incorporated in 1976. What do you think they did for the first 25 years of their existence?
He he he.
I'm much closer to 60 than to 50, and I played with my first "personal computer" (original Apple ][) in the late 1970s. I have over 40 years of experience with personal computers, servers, and embedded. I've been through bubbles, I've seen the pendulum swing from centralization to distributed several times. I've seen industry behemoths rise and fall.
I work hard to maintain a grizzled appearance, and I am an industry veteran. I have encountered ageism (and sexism, and racism) in the industry: it's like mould in blue cheese. It all comes down to the biggest problem in the industry, and probably outside the industry: arrogance.
I'm much closer to 60 than to 50, and I played with my first "personal computer" (original Apple ][) in the late 1970s. I have over 40 years of experience with personal computers, servers, and embedded. I've been through bubbles, I've seen the pendulum swing from centralization to distributed several times. I've seen industry behemoths rise and fall.
I work hard to maintain a grizzled appearance, and I am an industry veteran. I have encountered ageism (and sexism, and racism) in the industry: it's like mould in blue cheese. It all comes down to the biggest problem in the industry, and probably outside the industry: arrogance.
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.
Lack of development time and or skill is more likely to result in a buggy mess than failure to uphold best practices. What’s confusing the issue is skilled people given sufficient time and support generally use best practices.
The best example I can give is one developer given very little time sends something to QA their unsure about. QA lets it though because they stopped testing his code.
The best example I can give is one developer given very little time sends something to QA their unsure about. QA lets it though because they stopped testing his code.
>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.
This is where communication skills come in. The more one levels up their communication skills the easier situations like this are to overcome.
This is where communication skills come in. The more one levels up their communication skills the easier situations like this are to overcome.
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.
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.
> The “old ones” brought a lot of maturity, practices (TDD, tests, even XP at times) and loved mentoring the super enthusiastic grads.
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.
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.
Imagine how much more even more experienced developers can bring to the table, especially if they've been keeping up and growing :)
The few who continues to grow after 10 years gets into extremely well paid positions and have no problems getting jobs. We aren't talking about them here, we are talking about the majority who never grow out of their senior engineer position. They aren't more valuable after 20 or 30 years than they were at 10 since they stopped growing, and this is the majority of people in every field.
You don't fix age discrimination by saying that old people are better, because in most cases they aren't, instead you fix it by saying that if you have 2 persons with similar skills then you shouldn't automatically pick the less experienced younger person. If you only hire old developers when they have all of the awesome skills people tout in these threads then you will mostly hire young developers since so few developers have those skills no matter what age they are.
You don't fix age discrimination by saying that old people are better, because in most cases they aren't, instead you fix it by saying that if you have 2 persons with similar skills then you shouldn't automatically pick the less experienced younger person. If you only hire old developers when they have all of the awesome skills people tout in these threads then you will mostly hire young developers since so few developers have those skills no matter what age they are.
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.
>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. :-)
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.
We're funny creatures :D
Just did a quick Google, here's the video: https://www.youtube.com/watch?v=MEhSk71gUCQ
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
That experiment makes me uncomfortable.
Perhaps it'll make you feel better that there's a good reason we do it: when everyone else is doing something, it's often a good idea to follow them. We all love to hear the one time someone does something contrarian and it turns out well, but in general if you have no prior knowledge picking the thing that other people is doing is a good strategy because they may know a reason you don't.
A slightly better thing to do, of course, is ask why they're doing something.
A slightly better thing to do, of course, is ask why they're doing something.
I mean a little bit yeah. But problem solving through peer pressure is a real thing and it's totally legitimate. You do get some weird artifacts (because it functions via a weird distributed statistical function) and it can be exploited.
Some countries that get low amounts of sunlight due to latitude eat fish for breakfast. Apparently the nutrients in fish help you biologically deal with not having enough sunlight. And this results in statistically better health outcome vs other countries at the same latitude that don't eat fish as much.
Did eating fish start because people were running double blind 30 year dietician studies? Nope, it's just what other people were doing.
Think about it this way. Some problems are really hard to actually understand. And if you screw up you'll die (so you can't exactly learn the lesson even if the lesson was obvious). Culture and social cohesion is important because other people have learned (maybe unconsciously) a fatal lesson by watching others fail to learn that lesson. It can be life or death for you to pick up on that lesson.
It's also important that people question why we do things. Because otherwise we can end up all standing up when a bell rings for no reason. But both methods are necessary. Even if we end up doing some stupid things for a while as we sort out reality.
EDIT: I'm actually mostly unaffected by peer pressure. It sounds impressive because I'm extremely unlikely to do something stupid like stand up when a bell rings. Additionally, I can go off and learn things like type theory, lambda calculus, most programming languages like it's easy.
But the catch is that type theory is only easy compared to trying to understand social interaction logically. People often all agree about something that makes absolutely no sense to me ... and they're right (well, I've looked into this a lot and technically they're not right, but it works out and they get good outcomes, which is almost always close enough ... I think what happens is when their wrongness catches up to them they switch strategies or something, but I'm not sure). It often feels like living with a bunch of aliens who have psychic powers.
So, while it's easy to setup social experiments that make peer pressure look stupid, I'm not about to discount it's incredible usefulness.
Some countries that get low amounts of sunlight due to latitude eat fish for breakfast. Apparently the nutrients in fish help you biologically deal with not having enough sunlight. And this results in statistically better health outcome vs other countries at the same latitude that don't eat fish as much.
Did eating fish start because people were running double blind 30 year dietician studies? Nope, it's just what other people were doing.
Think about it this way. Some problems are really hard to actually understand. And if you screw up you'll die (so you can't exactly learn the lesson even if the lesson was obvious). Culture and social cohesion is important because other people have learned (maybe unconsciously) a fatal lesson by watching others fail to learn that lesson. It can be life or death for you to pick up on that lesson.
It's also important that people question why we do things. Because otherwise we can end up all standing up when a bell rings for no reason. But both methods are necessary. Even if we end up doing some stupid things for a while as we sort out reality.
EDIT: I'm actually mostly unaffected by peer pressure. It sounds impressive because I'm extremely unlikely to do something stupid like stand up when a bell rings. Additionally, I can go off and learn things like type theory, lambda calculus, most programming languages like it's easy.
But the catch is that type theory is only easy compared to trying to understand social interaction logically. People often all agree about something that makes absolutely no sense to me ... and they're right (well, I've looked into this a lot and technically they're not right, but it works out and they get good outcomes, which is almost always close enough ... I think what happens is when their wrongness catches up to them they switch strategies or something, but I'm not sure). It often feels like living with a bunch of aliens who have psychic powers.
So, while it's easy to setup social experiments that make peer pressure look stupid, I'm not about to discount it's incredible usefulness.
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.
Nowadays claiming loudly 'fake' seems to be the argument used for most things we can't readily understand, or simply as a default noise maker.
In the past the default argument was 'sorcery' or 'anathema'.
That's why we need the scientific method. Our primary impressions can be often wrong. We should not rely only on 'gut feelings' to reach our conclusions.
In the past the default argument was 'sorcery' or 'anathema'.
That's why we need the scientific method. Our primary impressions can be often wrong. We should not rely only on 'gut feelings' to reach our conclusions.
> Nowadays claiming loudly 'fake' seems to be the argument used for most things we can't readily understand, or simply as a default noise maker.
> In the past the default argument was 'sorcery' or 'anathema'.
I really don't like this. It looks fake because it's full of edits, skips over important bits where you'd expect doubt, and doesn't feel like its supplying the full context.
Yes, the conformity effect is real. But no, it's not as strong as EVERYONE loves to portray it. In actual studies, a good chunk of people don't abide by the effect, and it's probable that, contrary to the video, they do suspect they're being observed (by a study or more likely just some sort of process with a consequence). It's a stretch to assume that people copy things because that's what the group does, rather than thinking the group has a good reason to be doing something. The latter sounds the same, but when you think about it is a lot less interesting.
Most people, if they're the Asian girl, are just going to ask the group what they're doing.
> In the past the default argument was 'sorcery' or 'anathema'.
I really don't like this. It looks fake because it's full of edits, skips over important bits where you'd expect doubt, and doesn't feel like its supplying the full context.
Yes, the conformity effect is real. But no, it's not as strong as EVERYONE loves to portray it. In actual studies, a good chunk of people don't abide by the effect, and it's probable that, contrary to the video, they do suspect they're being observed (by a study or more likely just some sort of process with a consequence). It's a stretch to assume that people copy things because that's what the group does, rather than thinking the group has a good reason to be doing something. The latter sounds the same, but when you think about it is a lot less interesting.
Most people, if they're the Asian girl, are just going to ask the group what they're doing.
I really like your answer to my comment here.
It's on a totally different level than just crying 'fake'.
I think it is quite possible that for some behaviours humans tend to prefer to always use their own judgement, while the opposite is true for other behaviours.
We see a massive parallel experiment about this with some things that happen on Twitter or TikTok. And this goes from putting a bucket of ice over your head to the reaction to some political statement.
To have a catalogue of the cognitive biases we have as humans and which behaviours are more susceptible to this effect would be a hugely useful dataset.
It's on a totally different level than just crying 'fake'.
I think it is quite possible that for some behaviours humans tend to prefer to always use their own judgement, while the opposite is true for other behaviours.
We see a massive parallel experiment about this with some things that happen on Twitter or TikTok. And this goes from putting a bucket of ice over your head to the reaction to some political statement.
To have a catalogue of the cognitive biases we have as humans and which behaviours are more susceptible to this effect would be a hugely useful dataset.
I have seen a video of the experience being reproduced in a trustworthy setting so I personally trust it.
If you don't think experience matters, try this:
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.
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.
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.
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.
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.
Age and experience are strongly correlated. Sure you can have zero experience and be old, you can have tons of experience and be young. But normally: Age and experience are strongly correlated.
I did not indicate otherwise.
> This has nothing to do with age, and little with experience.
It has to do with experience because skills can only be honed through experience. It has to do with age because honing skills via experience requires time.
It has to do with experience because skills can only be honed through experience. It has to do with age because honing skills via experience requires time.
> It has to do with experience because skills can only be honed through experience.
Yes, but it does not take a learner lots of experience to learn a skill (with some caveats, ofc). It takes the teacher experience to teach a skill, though.
> It has to do with age because honing skills via experience requires time.
I agree.
But it was not about honing skills or becoming perfect, it was about learning and "building a kitchen".
Yes, but it does not take a learner lots of experience to learn a skill (with some caveats, ofc). It takes the teacher experience to teach a skill, though.
> It has to do with age because honing skills via experience requires time.
I agree.
But it was not about honing skills or becoming perfect, it was about learning and "building a kitchen".
> it was not about honing skills or becoming perfect, it was about learning and "building a kitchen"
We must have different priors regarding OP's specific example. I think that "building a kitchen" would require a hell of a lot of skill, all of which needs to be honed over a decent period of time. I'm 100% confident that given an empty room, building materials, tools, and some appliances, I would do more harm than good.
We must have different priors regarding OP's specific example. I think that "building a kitchen" would require a hell of a lot of skill, all of which needs to be honed over a decent period of time. I'm 100% confident that given an empty room, building materials, tools, and some appliances, I would do more harm than good.
I'm 100% confident that given an empty room, building materials, tools, and some appliances – and an infinite amount of time – I would make a masterpiece on the first try. (I attribute this skill to LEGO, of course...) ;) So guys like that do exist. Orson Wells is one such a guy, just to drop one name from the arts. I'm saying this because I have experience cleaning up after "professionals" who did a worse job then I did, despite purportedly having "experience". I sadly have more than one such examples. (Perhaps I'm in the wrong line of work?) On the other hand, since we're actually discussing a statistical problem here, it should be pretty clear that guys like Orson Wells inhabit the tail of the distribution.
No, I think we just have a different view on what knowledge, skills and proficiencies means.
I'm not saying experience is irrelevant, I'm saying you can teach somebody the skills to use tools and the proficiency to build a kitchen and he would afterwards be able to build a kitchen, even though his experience is very little.
I'm not saying it will be the best kitchen in the world, neither am I saying the teaching process will be super fast (it depends on teacher and pupil), but I am saying that it is first and foremost not about the age and experience of the trainee, who then later attempts to build the kitchen.
I'm not saying experience is irrelevant, I'm saying you can teach somebody the skills to use tools and the proficiency to build a kitchen and he would afterwards be able to build a kitchen, even though his experience is very little.
I'm not saying it will be the best kitchen in the world, neither am I saying the teaching process will be super fast (it depends on teacher and pupil), but I am saying that it is first and foremost not about the age and experience of the trainee, who then later attempts to build the kitchen.
I would say it is a prime example of the difference between "necessary" and "sufficient".
The time investment is necessary. It is by no means sufficient.
The time investment is necessary. It is by no means sufficient.
Except age and experience are not necessarily correlated.
I think this was precisely his point.
Also knowledge, skills and proficiencies are called just 'experience' when you don't want to go into great detail.
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?
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.
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).
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).
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.
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.
Surprises me how few people understand/mention the "programmers doubling"
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.
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.
> "Good judgment comes from experience. Experience comes from bad judgment."
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.
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.
> 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.
Don't get me wrong. I did let it get me down for a while. It was really pathetic; crying, screaming, rolling on the floor, pounding my little fists on the table.
That got me precisely nowhere, but I guess it was cathartic.
I am pretty disgusted how ageism in employment is every bit as illegal as racism and sexism, but is actually ignored, if not outright encouraged. Companies run ads all the time, pretty much saying "Boomers need not apply," and no one bats an eyelid. I've learned that when a company gives a binary tree test, I might as well just pack up and go home. They just want to tick off an "interviewed old fart, and he didn't even know basic college stuff" checkbox for HR. Younger folks spend every day, practicing for these tests. I spend every day, writing ship software (and I mean every day -seven days a week, usually ten or more hours straight. My GH Activity Graph is solid green).
But I really love designing and releasing software. I do this for love. I'm probably doing six figures' worth of coding for free, because I believe in what I'm doing, and I haven't written a social media app; which seems to be a modern rite of passage. I already wrote the backend, a couple of years ago[0]. I'm just writing a native frontend.
I'm working with younger folks. I'm very, very good at helping folks with ideas, make them real. The classic pattern is for experienced and younger folks to work together, with younger people driving the energy and creativity, and the older folks providing the infrastructure and quality. That pattern has been turned on its head; probably because people are becoming CEOs before they reach 30.
Once I accepted that no one wants to work with me, and that I won't end up destitute, it was OK for me to just work for free.
[0] https://riftvalleysoftware.com/work/open-source-projects/#ba...
Don't get me wrong. I did let it get me down for a while. It was really pathetic; crying, screaming, rolling on the floor, pounding my little fists on the table.
That got me precisely nowhere, but I guess it was cathartic.
I am pretty disgusted how ageism in employment is every bit as illegal as racism and sexism, but is actually ignored, if not outright encouraged. Companies run ads all the time, pretty much saying "Boomers need not apply," and no one bats an eyelid. I've learned that when a company gives a binary tree test, I might as well just pack up and go home. They just want to tick off an "interviewed old fart, and he didn't even know basic college stuff" checkbox for HR. Younger folks spend every day, practicing for these tests. I spend every day, writing ship software (and I mean every day -seven days a week, usually ten or more hours straight. My GH Activity Graph is solid green).
But I really love designing and releasing software. I do this for love. I'm probably doing six figures' worth of coding for free, because I believe in what I'm doing, and I haven't written a social media app; which seems to be a modern rite of passage. I already wrote the backend, a couple of years ago[0]. I'm just writing a native frontend.
I'm working with younger folks. I'm very, very good at helping folks with ideas, make them real. The classic pattern is for experienced and younger folks to work together, with younger people driving the energy and creativity, and the older folks providing the infrastructure and quality. That pattern has been turned on its head; probably because people are becoming CEOs before they reach 30.
Once I accepted that no one wants to work with me, and that I won't end up destitute, it was OK for me to just work for free.
[0] https://riftvalleysoftware.com/work/open-source-projects/#ba...
Boomers are retired now or soon to be, no? 1950 was 70 years ago. How about GenX? While we didn't invent computers, we grew up building them at home from kits and later Computer Shopper. Very few folks get that experience any longer, outside of connecting a USB device.
I'm 58, which is sort of "the last of the Boomers," maybe. I don't remember the year range.
In any case, it doesn't really matter. I'm planning to croak face-down on my keyboard. The mortician is gonna have to rub "QWERTY" off my cheek.
This was my first paid work: https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf
In any case, it doesn't really matter. I'm planning to croak face-down on my keyboard. The mortician is gonna have to rub "QWERTY" off my cheek.
This was my first paid work: https://littlegreenviper.com/TF30194/TF30194-Manual-1987.pdf
> 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.
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.
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)
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)
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.
On Rumsfeld, I would guess people who opposed the war and his party were ready to proclaim anything he said was dumb and wrong.
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.
> Rumsfeld: I'm not going to say which it is.
[0] https://archive.defense.gov/Transcripts/Transcript.aspx?Tran...
> 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...
> 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.)
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.)
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.
With experience comes wisdom. Wisdom is a manager's worst nightmare unless they were technical in the first place.
I think this is only true if you're working under bad managers or in a corporate culture that incentives bad management practices.
People who are good managers almost always try to solicit as much criticism and feedback as possible. Especially from the most experienced people, since they know where the bodies are buried.
People who are good managers almost always try to solicit as much criticism and feedback as possible. Especially from the most experienced people, since they know where the bodies are buried.
Good managers are like unicorns. I have yet to see one.
There are some great managers but they’re usually from a tech background and know not to micromanage. Non-tech managers are really glorified PMs.
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.
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.
Depending on what you make anther toolkit for fun C++ things is https://openframeworks.cc/.
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.
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.
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.
With that logic the whole point of interview is invalid. Because you can take anyone and teach them what to do :) Imho the idea of simple question is to check basic understanding of data structures. It is not about checking if someone can apply to some problem red-black tree... Queue and Stack are basic things every programmer imho will know no matter what time of the day or night it is.
> what is the difference between queue and stack
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.
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.
Isn’t the clue in the name? :) I feel like it’s almost a mind trick. Ask anyone off the street what the difference is between a queue of people and a stack of plates, and they’d get the right answer pretty quick - but ask a tech person in an interview and they’ll panic! (Which probably proves it’s not a very good example to judge applicants by on its own)
> 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.
How do you figure that as a good signal?
> 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?
It's not a good indicator of experience. But it's probably a decent indicator of a lack of experience.
Queue vs stack is an extremely basic concept. They're not even unique terms to CS. You can almost guess what they are just by their names.
Queue vs stack is an extremely basic concept. They're not even unique terms to CS. You can almost guess what they are just by their names.
Exactly this. You don't have to be 180 IQ to solve it. There is no trick in this question. Much better than asking for FizzBuzz implementation.
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?
I don't like the label "old".
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.
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.
I don't think that the full story. The bottom line is that as you age, you will inevitably start making different trade off's and choices.
As you grow older, you start to truly understand that life is finite, with everything that entails: loved ones growing older, and passing away, you noticing your own body changing as well as you enter middle age, noticing how your own perspective and experience of passing of time shifts (when saying "20 years ago" isn't an abstract phrase, but an experience you lived through), and also noticing how the expectations others have of you start shifting.
That doesn't mean you can't be inquisitive, energized or wanting to continue learning from your own mistakes. I do that all the time, as I understand the importance of learning throughout life ...
... but I'm far more conscious of the value of time and how I use that time shapes me as a person.
Being experienced also means being in control over your time and your life, knowing to set boundaries and keeping a healthy balance between your priorities, and the priorities of others, which also includes the priorities of clients and employers.
Let's not forget that the "tendency for some people to stop progressing" also tends to be used as a strawman argument in order to undercut the importance of the above and push people to change their priorities in ways that may fly against their own self interest.
That's why I've grown weary about generalizing arguments that one has to "progress" without stating exactly why, within which specific context, or within which specific boundaries.
As you grow older, you start to truly understand that life is finite, with everything that entails: loved ones growing older, and passing away, you noticing your own body changing as well as you enter middle age, noticing how your own perspective and experience of passing of time shifts (when saying "20 years ago" isn't an abstract phrase, but an experience you lived through), and also noticing how the expectations others have of you start shifting.
That doesn't mean you can't be inquisitive, energized or wanting to continue learning from your own mistakes. I do that all the time, as I understand the importance of learning throughout life ...
... but I'm far more conscious of the value of time and how I use that time shapes me as a person.
Being experienced also means being in control over your time and your life, knowing to set boundaries and keeping a healthy balance between your priorities, and the priorities of others, which also includes the priorities of clients and employers.
Let's not forget that the "tendency for some people to stop progressing" also tends to be used as a strawman argument in order to undercut the importance of the above and push people to change their priorities in ways that may fly against their own self interest.
That's why I've grown weary about generalizing arguments that one has to "progress" without stating exactly why, within which specific context, or within which specific boundaries.
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.
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)."
> 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)."
As a personal analogy, we're currently redecorating our home. We've just spent about 4 days planning the layout of the electrical boxes and wiring pipes for a small hallway. Once it gets covered by the rock sheets and all that it's a PITA to make a change.
Once we had rechecked everything for the n-th time, the job of mounting it all took about half an hour.
This is in stark contrast to software development with git or similar, where there's little to no fear when making radical changes, as it's easy to undo, have multiple versions in different branches for comparison etc.
Once we had rechecked everything for the n-th time, the job of mounting it all took about half an hour.
This is in stark contrast to software development with git or similar, where there's little to no fear when making radical changes, as it's easy to undo, have multiple versions in different branches for comparison etc.
Right, but the correct analogy for putting up the drywall is deploying to production...
At work we have a launcher that lets our users select one of the five previous minor versions of potentially multiple major versions they have installed. A local service checks for new versions every hour and downloads them automatically.
That way we can deploy to production quickly and with far less worry than before we had this system. If a user runs into a blocking issue they can just re-launch a previous version and continue working.
That way we can deploy to production quickly and with far less worry than before we had this system. If a user runs into a blocking issue they can just re-launch a previous version and continue working.
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 don't think normalization was ever about storage space.
> "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.
> 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.
The question isn't whether you'd hire a new grad or a guy in his 50's as many here seems to think. The young option is a guy in his 30's with 15 years of experience, they are much easier to find than older programmers (due to the number of programmers increasing exponentially over that time) so most senior hiring will be targeted at them.
[deleted]
Part of this could also be attributed to the way older generations approach work. You find a company, put in your 30 years, then retire. That makes you a terrible prospect in the tech industry. 10+ years of doing repetitive tasks or exploiting domain knowledge to maintain some legacy system means you are far behind in both knowledge and motivation.
I just think you just need a good mix. This is not just true for programmer but so many other jobs too. The young guys often have fresh ideas and work a lot, but yes, they fail sometimes. The older guys say maybe more "no" to a bs idea from managment/top. There are many things more .. and thats also not something new.
While this discussion seems to lean heavily on the technical parts, there are many aspects of a business that can only be learned through experience.
Project work. Client relations. Lots of "general" business / work skills.
If I meet some 50 year old dev, that's been at it professionally for 25-30 years, I will at least assume that he / she are somewhat knowledgeable in some of those areas.
If you've worked on, from start to finish, on tens of projects - you've probably seen and experienced a wide variety of things.
So, yeah, while younger and more inexperienced devs can be technically astute, it's always good to have experienced mentors that can guide you through the other stuff, not only the nitty-gritty technical details. After all, software development is much more than just punching out lines of code.
Project work. Client relations. Lots of "general" business / work skills.
If I meet some 50 year old dev, that's been at it professionally for 25-30 years, I will at least assume that he / she are somewhat knowledgeable in some of those areas.
If you've worked on, from start to finish, on tens of projects - you've probably seen and experienced a wide variety of things.
So, yeah, while younger and more inexperienced devs can be technically astute, it's always good to have experienced mentors that can guide you through the other stuff, not only the nitty-gritty technical details. After all, software development is much more than just punching out lines of code.
The older I get, the less I know. When I was in my 20s I thought I knew a whole lot about embedded software development. Now in my late 50s I seem to be painfully aware of how little I actually know. Maybe this is part of the risk-taking mindset of being young: they don't yet know what they don't know so they're not encumbered by that realization. If I had felt this way in my 20s I would have been paralyzed by doubt. Now, with experience I realize that most everyone is essentially driving in the fog. Sometimes you can only see a few yards ahead and you have to just become comfortable with the uncertainty while doing what you can to mitigate it. When I was younger I either didn't see the fog or thought I needed to pretend it wasn't there.
[deleted]
Unrelated to the subject of the article, but this I find questionable:
> Once, if you had lots of data, you had to store it in fully normalised form, because storage was expensive.
First time I heard that NF's were considered to save space...
> Once, if you had lots of data, you had to store it in fully normalised form, because storage was expensive.
First time I heard that NF's were considered to save space...
If you only store a customer's address once, rather than having a separate copy everywhere you store the customer, then that saves a lot of space (as well as ensuring that different instances don't contradict each other).
Yes, that is surprising to hear the first time, but it's true.
Space saving is one of the primary advantages of relational databases, the other being tracking complex data relationships
Nowadays, it's not storage that is expensive, but CPU cycles, and RDBMS are processor expensive relative to NOSQLs
I advise clients to avoid RDBMS without a very specific need for complex data relationships
Space saving is one of the primary advantages of relational databases, the other being tracking complex data relationships
Nowadays, it's not storage that is expensive, but CPU cycles, and RDBMS are processor expensive relative to NOSQLs
I advise clients to avoid RDBMS without a very specific need for complex data relationships
I'd advise your clients to avoid your advise if I could.
Here is a good overview of other types of databases: https://youtu.be/W2Z7fbCLSTw
AFAIK, old hierarchical databases had a very similar space usage as relational ones.
I do think people adopt the modern theory because of its flexibility.
I do think people adopt the modern theory because of its flexibility.
There’s a cultural aspect.
If you have a team all within a certain range, they’re going to mesh. It’s less likely that someone significantly older will. I liken this to the old smokers problem. A lot of political machinations happened when people went outside to smoke together. If you didn’t smoke, you were left out of important conversations. I’m 56 and I’m already left out of a lot of discussions that younger coworkers have. There’s definitely a problem in the IT works in how it builds teams and excludes older workers.
We’re expected to be managers or executives. Not a part of implementation.
If you have a team all within a certain range, they’re going to mesh. It’s less likely that someone significantly older will. I liken this to the old smokers problem. A lot of political machinations happened when people went outside to smoke together. If you didn’t smoke, you were left out of important conversations. I’m 56 and I’m already left out of a lot of discussions that younger coworkers have. There’s definitely a problem in the IT works in how it builds teams and excludes older workers.
We’re expected to be managers or executives. Not a part of implementation.
One of my old professors where famous enough that cpu manufacturers sent him PCs to check against his open source library. We have been fed the “you won’t be better than the compiler focus on the algorithm” to death by the internet at that time.
Seeing him combine his assembly language/c knowhow AND algos made me realize that with FOCUSED experience you can do amazing things.
Then again when I told him my favorite language implementation , Haskell/GHC, was using his library he asked: what is Haskell?
Focused training is everything. You can’t be good at everything but you can be great at something.
Seeing him combine his assembly language/c knowhow AND algos made me realize that with FOCUSED experience you can do amazing things.
Then again when I told him my favorite language implementation , Haskell/GHC, was using his library he asked: what is Haskell?
Focused training is everything. You can’t be good at everything but you can be great at something.
Dropped onto a project this year that was put together by 15 or so juniors over 18 months. They're all gone, and there's now just 3 seniors (new team) trying to make sense of things and save it.
If the project had been tempered with some seniors, it could have been done in 6-9 months with 3 - 5 people. It's pretty straight forward work.
Having to excavate and rehabilitate all of the poor decisions and practices due to inexperience has taken time. It's nothing I haven't seen before, though.
If the project had been tempered with some seniors, it could have been done in 6-9 months with 3 - 5 people. It's pretty straight forward work.
Having to excavate and rehabilitate all of the poor decisions and practices due to inexperience has taken time. It's nothing I haven't seen before, though.
How can 15 people be gone? Contractors?
One interesting bit about American age discrimination law is that it only works one way. It protects those older than 40, but you can legally discriminate against young people.
If ageism in tech is real, then older programmers are being systemically undervalued by the market (probably in a huge way since I’d expect older good programmers to be be better than younger good programmers).
If I was doing a start up I might advertise roles that are for 40+ year old candidates only and see who I could attract.
If ageism in tech is real, then older programmers are being systemically undervalued by the market (probably in a huge way since I’d expect older good programmers to be be better than younger good programmers).
If I was doing a start up I might advertise roles that are for 40+ year old candidates only and see who I could attract.
How is the situation different from any other industry? Fields like civil engineering or accounting surely don’t have these conversations?
Focus on keeping your knowledge current. If you have sound grounding in modern stack from virtualization and up using containers and monitoring, I don't see why you should worry about anything. Always be ready to code and even be ready to get your hands dirty with RDBMS query plan troubleshooting.
>Technology changes rapidly in software development.
Nope. Not even close to being true. Unless you think taking old tech and rebranding it is "new tech". People are reinventing old tech every day thinking they are doing something new. It is evidence of lack of knowledge of history. Nothing else.
Nope. Not even close to being true. Unless you think taking old tech and rebranding it is "new tech". People are reinventing old tech every day thinking they are doing something new. It is evidence of lack of knowledge of history. Nothing else.
as a mediocre programmer who is now old let me tell you that you still do not need me.
Young programmers are only idolized because they are the only ones you can convince to build your sausage app for pennies.
Lower pay, longer hours, and technically, just as strong as the senior folks. In part because they don't know better, in part because they're looking to prove themselves, and in part because without a family they don't have much else to do on a weeknight. Speaking from my experience as a junior engineer, that is.
Speaking as a "senior" engineer today, I'm no better an engineer today than I was 10 years ago in terms of rote problem solving. What I provide as a senior engineer is if we're paddling across the lake, I'll keep us dry. Oh, and yeah, that'll cost you.
What I like about the article is they suggest the older folks have nothing to lose closer to retirement, and that makes them super valuable. I'd suggest that's true of the junior folks. It's the middling folks that have the most to lose, I suppose.
Speaking as a "senior" engineer today, I'm no better an engineer today than I was 10 years ago in terms of rote problem solving. What I provide as a senior engineer is if we're paddling across the lake, I'll keep us dry. Oh, and yeah, that'll cost you.
What I like about the article is they suggest the older folks have nothing to lose closer to retirement, and that makes them super valuable. I'd suggest that's true of the junior folks. It's the middling folks that have the most to lose, I suppose.
> technically, just as strong as the senior folks.
> Speaking as a "senior" engineer today, I'm no better an engineer today than I was 10 years ago in terms of rote problem solving. What I provide as a senior engineer is if we're paddling across the lake, I'll keep us dry.
This is an extremely narrow vision of the nature of engineering and engineers. It makes sense if the problems you're dealing with are whiteboard interview problems. Real world projects are much broader in nature and context.
At a very bare minimum, the experience on solving a broad spectrum of problems, and dealing with the related context, brings:
I think there was talk, some time ago, on HN on this subject - if the only difference in 10 years of experience is "keeping dry across the lake", then one is a junior engineer with 10 year of experience, not a senior engineer (and/or somebody who doesn't see the difference).
> Speaking as a "senior" engineer today, I'm no better an engineer today than I was 10 years ago in terms of rote problem solving. What I provide as a senior engineer is if we're paddling across the lake, I'll keep us dry.
This is an extremely narrow vision of the nature of engineering and engineers. It makes sense if the problems you're dealing with are whiteboard interview problems. Real world projects are much broader in nature and context.
At a very bare minimum, the experience on solving a broad spectrum of problems, and dealing with the related context, brings:
- more solid solutions
- simpler solutions
- more fitting models
- anticipation of dead ends
- stability in the long term
- etc. etc.
I think there was talk, some time ago, on HN on this subject - if the only difference in 10 years of experience is "keeping dry across the lake", then one is a junior engineer with 10 year of experience, not a senior engineer (and/or somebody who doesn't see the difference).
Just to clarify I said "in terms of rote problem solving" which is what you referred to as "whiteboard interview problems." When I said "I'll keep us dry" I meant exactly the items you listed, with a particular focus on anticipating and avoiding problems and ensuring long-term stability over near-term thinking when appropriate.
That is what they meant by "I'll keep us dry."
> Speaking as a "senior" engineer today, I'm no better an engineer today than I was 10 years ago in terms of rote problem solving.
See I'm waaay better at it. Not in terms of raw problem solving ability, but because I've solved so many unique problems by now that I can start a new one half way through.
That and my skills are a lot more refined, so there are a lot of things I will do the right way out of habit which I would have had to discover through iteration 5-10 years ago.
If you're not better at what you do than you were 10 years ago, it makes me wonder what you've been doing with your time.
See I'm waaay better at it. Not in terms of raw problem solving ability, but because I've solved so many unique problems by now that I can start a new one half way through.
That and my skills are a lot more refined, so there are a lot of things I will do the right way out of habit which I would have had to discover through iteration 5-10 years ago.
If you're not better at what you do than you were 10 years ago, it makes me wonder what you've been doing with your time.
A good senior engineer makes sure that your app is still maintainable and scalable at the 1/2/5/10 year mark. If your never make it past the 1 year mark he or she will not provide any value.
If you're well funded (or if this is a new project in an existing company) I would make sure to allocate a reasonable portion of the budget for senior engineers or if I couldn't find any true senior engineers I would get the best motivated mediors and give them an enormous education budget.
If you're well funded (or if this is a new project in an existing company) I would make sure to allocate a reasonable portion of the budget for senior engineers or if I couldn't find any true senior engineers I would get the best motivated mediors and give them an enormous education budget.
I would go even further and say a senior engineer knows not just what to invest in, but what not to invest in. For instance, if you're solving zero-to-one problems, a senior engineer may caution you to avoid too much architecture and instead focus on development velocity at all costs. After all, what good is a well-crafted app in chapter 11?
A longer-term thinker will also have another idea about what can be considered "a well-crafted app" than somebody being interested to use one more hottest technology of the moment.
I'm not using "a senior engineer" because it's not a given that somebody has some expected perspective simply because of the title or the time worked or even the education they had.
I'm not using "a senior engineer" because it's not a given that somebody has some expected perspective simply because of the title or the time worked or even the education they had.
Very true.
Yeh this exactly for a start-up and new projects you really do need experienced developers in the initial stages.
My first couple of agile projects where like this - you can also bring in external consultants to help with getting up to speed.
My first couple of agile projects where like this - you can also bring in external consultants to help with getting up to speed.
> Speaking as a "senior" engineer today, I'm no better an engineer today than I was 10 years ago in terms of rote problem solving.
I am, at almost 20 years in. I'm not only better at doing things well and safely, I can do them faster than ever because I know what's a solved problem and what's not, where to look for pre-existing solutions and how to apply them, what the pitfalls might be etc.
some young software people are very technically adept, but far from all are.
I am, at almost 20 years in. I'm not only better at doing things well and safely, I can do them faster than ever because I know what's a solved problem and what's not, where to look for pre-existing solutions and how to apply them, what the pitfalls might be etc.
some young software people are very technically adept, but far from all are.
The younger developers are not out with friends going to the pub / cub on weeknights?
I'm not trying to be rude here but have you met the average developer?
When they go home they're just playing Fall Guys and rewatching Blade Runner, wishing Cyberpunk 2077 was out already.
When they go home they're just playing Fall Guys and rewatching Blade Runner, wishing Cyberpunk 2077 was out already.
>>When they go home they're just playing Fall Guys and rewatching Blade Runner, wishing Cyberpunk 2077 was out already.
I meet that description and reading this thread I was beginning to think I was much less motivated than my peers.
I meet that description and reading this thread I was beginning to think I was much less motivated than my peers.
I certainly drank my fair share haha, but it was often after working until 10pm. I'm referring more to the 4pm-10pm window you'd normally (I assume) be picking the kids up from school, making them dinner, berating them for not having completed their homework, and so on.
Why are you working till 10pm?
In my 20s, I was often doing that because I find programming inherently enjoyable. That it also pays extraordinarily well when done professionally is a convenient but unrelated fact.
Why would I pull an all-nighter playing a video game? Same reason except for the well-paid part.
Why would I pull an all-nighter playing a video game? Same reason except for the well-paid part.
That's what the weekend is for.
Yup. They're driven by dreams far more than responsibilities and that dreaded death timer. It makes me feel a bit old tbh.
You mean hack something out that doesn't actually work ?
Paying people even if it's below market is fine. We all have to start somewhere.
Paying people even if it's below market is fine. We all have to start somewhere.
[deleted]
We need young and experienced programmers, not the old ones.
Old programmers tend to say "That's how we do things here.", experienced and mind-opened ones can lead you to finally replace the classic old php 5.4 require mess that is your framework.
Sadly, there are plenty of old programmers outta here, and young ones are just trying to save their jobs because of this market.
Old programmers tend to say "That's how we do things here.", experienced and mind-opened ones can lead you to finally replace the classic old php 5.4 require mess that is your framework.
Sadly, there are plenty of old programmers outta here, and young ones are just trying to save their jobs because of this market.
An experienced programmer might look at the problem of whether or not the company should replace php 5.4 and determine whether or not it's a completely or partially a good idea based on the factors they have control over and have budget to solve. An in-experienced programmer would probably not have learned PHP 5.4, and so would need to replace it in order to be productive, regardless of accounting for how much value they actually add by doing so.
The end result would probably be well argued strategy of incrementally adopting new ideas, testing them, and re-writing when time permits.
The end result would probably be well argued strategy of incrementally adopting new ideas, testing them, and re-writing when time permits.
Being old does not make you close minded. People who assume old people are close minded are ironically close minded themselves.
I don’t think, somebody needs old programmers. Look from business perspective: there is no difference how polished code base is. Younger folks can develop the same product with lower salaries than grown ups. Yes, they will look for greener grass, or do some crazy things, but business gets same output at lower cost. I am experiencing this at my current workplace. It is desired, that people leave after few years and freshmen can be hired again. Experience has zero value in business context.
This is the classic naive perspective. To a serious extent, experience tells you what to build and when. The actual building is quite often better to farm out to someone who can be bothered to trawl through familiarity with the latest 5-minute javascript framework. That is why successful founders tend to be middle aged[0]: they know when not to waste resources, and to use the right tool for the job. That tool might be you.
Furious activity is no substitute for understanding. - H. H. Williams
... via https://github.com/globalcitizen/taoup
[0] https://theconversation.com/most-successful-entrepreneurs-ar...
Furious activity is no substitute for understanding. - H. H. Williams
... via https://github.com/globalcitizen/taoup
[0] https://theconversation.com/most-successful-entrepreneurs-ar...
You are hoping they actually build what you told them to - from bitter experience.
Actually that's not true. Experience does matter. In one particular class I took we implemented a simple marching cubes implementation, or rather I did because the rest of the class could not complete it. I had about 8 years of experience in graphics type programming at that point.
People stupidly think programming is applying the most common patterns to the most popular frameworks. That is one type of programming inexperienced young people do. More typically it requires some strong domain knowledge. For instance one particular system I worked on was mostly written by one person who obviously had a lot of experience in the field. I think the younger programmers complained for many many years about the implementation, but none of them could have written it. This person had to ignore everyone else, who he knew were complaining without any experience to back it up, to get it done.
People stupidly think programming is applying the most common patterns to the most popular frameworks. That is one type of programming inexperienced young people do. More typically it requires some strong domain knowledge. For instance one particular system I worked on was mostly written by one person who obviously had a lot of experience in the field. I think the younger programmers complained for many many years about the implementation, but none of them could have written it. This person had to ignore everyone else, who he knew were complaining without any experience to back it up, to get it done.
> Experience has zero value in business context.
I wish you luck fundraising.
I wish you luck fundraising.
Luckily I am in industrial electronics without a smallest chance of fundraising.
You must have a different definition what is "business context". In business context, it's all about selling your ideas and making money for the business - even as an industrial electronics.
In this case I see business context as a cost structure of my current employer. I clash almost everyday against big bookkeeper army of the big Corp. Their view is very primitive: engineer costs money, they don’t differentiate by experience, age, capabilities. Even mythical 10x engineer (there is one in the whole floor!) is just another row in excel. Technical people often overlook the fact, that organizations are run by bookkeepers and so called business people. They have no background to judge technical development. If they can sell code written by freshmen, why should they hires bunch of experienced and expensive experts?
Awesome comment. When you become old you’ll then be talking about the value of experience and how that makes business sense. You’ll switch because you think exclusively in terms of self interest.
I am already graybeard. I had eye opening moments looking for a job right before pandemic. Now I desperately want to produce some rental real estate and leave engineering.
> there is no difference how polished code base is
There is no difference how maintainable the code base is?
I've seen a very well-known business, which is regularly discussed on HN to grind to a halt and fall behind all of it's competitors in a very fast-growing and fast-moving space because it was built on a ugly spaghetti monolith developed by someone with PhD in history and almost no experience in engineering. And that's only the first of many examples I can think of.
There is no difference how maintainable the code base is?
I've seen a very well-known business, which is regularly discussed on HN to grind to a halt and fall behind all of it's competitors in a very fast-growing and fast-moving space because it was built on a ugly spaghetti monolith developed by someone with PhD in history and almost no experience in engineering. And that's only the first of many examples I can think of.
Could you, please, elaborate more about that ugly spaghetti monolith? I have similar situation at work. Maintainability is hard to measure, so my every try to measure and improve stuff ends with words “not a business case”.
If you're looking for help fixing the mess you are dealing with, find the book Working Effectively with Legacy Code - https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe....
You might also want to read Refactoring to Patterns, but the legacy book is more important to start with.
You might also want to read Refactoring to Patterns, but the legacy book is more important to start with.
Then learn their language and phrase your suggestions in ways that expose the issues to them in terms they understand. This requires you to fully understand what is important, and what is not important, to the business.
Oh, and you should get good at incremental refactorings, and at downscoping your improvements so that they become feasible and easy to sell. Or even not require any selling as they can be done as part of normal work. It is not the big rewrites that get done, it is the small improvements that take only a little time, so learn how to compound them.
By the way, getting good at the above points will over time also change your own priorities.
Oh, and you should get good at incremental refactorings, and at downscoping your improvements so that they become feasible and easy to sell. Or even not require any selling as they can be done as part of normal work. It is not the big rewrites that get done, it is the small improvements that take only a little time, so learn how to compound them.
By the way, getting good at the above points will over time also change your own priorities.
But is it really my duty to play managers, so they are ok with refactoring and improvements? I imagined somehow, that management and developers have same goals and it’s natural thing having clean codebase and up to date electronics.
Yes, it is your duty to make them understand. Especially if they don't have a background in development themselves.
Also I would not frame it as playing them. That is the wrong mindset. You should be among for a high level of trust from their side and then playing them can backfire.
Also I would not frame it as playing them. That is the wrong mindset. You should be among for a high level of trust from their side and then playing them can backfire.
It depends on the work and the caliber of talent. It also depends on the state of the organization. Some fields require specialized skills, and experience is highly valuable. Programmer is broad term. Not everyone is building crud apps.
Inexperienced people can build small orgs into business crippling holes.
Inexperienced people can build small orgs into business crippling holes.
Unless they fuck up - for example a botched site migration that causes massive losses and ends up mentioned in the financial pages.
A number of UK banks have had disasters TSB, Santander caused by not having enough older more experienced developers.
A number of UK banks have had disasters TSB, Santander caused by not having enough older more experienced developers.
To be fair - the example of the UK banks who had disasters was because the systems in question were usually old 'legacy' systems that were being slowly replaced by new tech and newer developers. It was a lack of developers with experience of those particular legacy systems when something went wrong that was the problem, rather than the lack of older developers with more experience of development in general.
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.