When I was right out of college, I was a night owl, and I would roll into work in late morning, even though I stayed late for hours after everyone else left. It was really hard to build rapport with other people. It was no surprise that I also felt unwelcome when I tried to ask questions or work collaboratively.
Even though your coworkers use waterfall methods that are considered outdated, it doesn't mean they work ineffectively. An successful project has more to do with teamwork than any particular methodology. Agile methods have codified this idea, but it's still practiced informally in any successful team.
You aren't going to change the way the whole group does their work, so try it their way for a while. Come into work at the time they do. Talk with them at coffee breaks and go to lunch with them. Ask open-ended questions and listen to their answers. You might be surprised to find they have some useful experience to offer.
I'd also recommend against trying to persuade them to adopt agile methods. Instead, you can practice some agile methods de facto. For example, simply ask someone to look over your shoulder to help on a tough problem (people are usually willing to show their skill at solving tough problems). Voila! You're pair programming. But don't call it that! :-)
I have been on both sides of the fence, so to speak.
The problem with agile programming is that, like any tool, it isn't always appropriate for the task. In some environments a waterfall methodology is still effective.
I don't think the collaboration differences come from an age difference, but rather that is the style that has been fostered by that company and the work environment. I worked at a defense contractor for a while just out of school where almost everyone on the project was considerably older than I was but there was a very high amount of collaboration. On the flip side, I have worked for companies where everyone was around the same age and there was almost no collaboration.
People will either like answering questions/mentoring or they won't. Age doesn't necessarily make much of a difference. I have worked with people that are older and younger than I am but there have only been a few people that genuinely like answering questions (whether they were project related or not).
Excellent question. I've been in this business almost 50 years, and I'm still learning things.
I guess if I have a gripe it is that nearly all younger programmers had classes in programming, and their heads were filled with normative judgements. It reminds me of the Arthur C. Clarke novel "The City and the Stars", in which the population were indoctrinated with a fear of going outside the city limits that went well beyond reason.
I'm mainly self-taught (in programming), and I have a background in other kinds of engineering. In other kinds of engineering, no idea is feared like the devil (i.e. goto) or elevated to mythic status (OOP). Rather, every idea has pros and cons and situations in which it has more or less utility. Everything is based on math, and inventiveness is valued.
While the younger programmers are bright, willing, and energetic, I wish they were more curious and open-minded.
i apologize in advance if the tone of this sounds harsh, i am actually very amused as i write this because your situation happens all the time, i.e. you're not the first to notice the difference between the 'noobs and the 'oldsters at work ;-)
the first flaw: "old school" vs "new school" - assuming your seniors are "old school" and therefore inferior is called prejudice, and is not a very good way to start your career.
chances are, the "old schoolers" can and will code circles around you, especially in their domain. Since your new job depends on learning their domain perhaps you should learn and befriend them first and try to teach them later, after you have earned their respect...
...and definitely keep your "new school vs old school" prejudices in check; if your "aging" coworkers (as if you are immune from aging!) perceive you to be a know-it-all "punk", no one will want to help you. It really doesn't matter even if you actually do know it all, no one likes a punk. ;-)
so pretend to be humble for the first few months, listen carefully, and be ready to learn more in your first year of real work than you ever learned in college!
as for your specific issues so far, here's another way to look at it:
waterfall works fine with experienced developers and a target that isn't moving too fast
what you call "collaboration" i might call "interrupting my concentration"; code tends to be written most efficiently by individual programmers working alone and uninterrupted; continual multi-tasking is inefficient
working during normal business hours is what normal employees do; get used to it. There is an advantage to being in the office when your customer is also in the office. Of course there are also disadvantages. The balance between the two is called "time management" ;-)
as a corporate noob, you are expected to ask a lot of questions. Just don't jump up and interrupt the seniors every ten seconds like a toddler, save up a hand full of questions and interrupt them only a few times per day.
the good news is, the fact that you asked this question means that you care, and as long as your seniors can sense this about you they will care about you, too.
I don't think the issues you are dealing with are age dependent. I've had great experiences with programmers twice my age and have learned a lot from them. The converse is true as well.
Someday I'll be an old programmer, but that doesn't mean that I have to be "old school".
Continue learning and be open to accept new ideas.
You need to fit in with the group, They won't change to match you, but that does not mean you cannot gradually bring in change.
While you will find some people who don't like to answer questions, most people will especially if you show you are genuinely interested in the subject.
Ask the team leader / manager for a small project you can do using more modern methods (agile might be difficult to do by self). Show people that it works and demonstrate how it is better.
Be tactful and try not to upset people. remember "old age and treachery will beat youth and skill". Don't get in a fight you cannot win. People will resist change.
As always it depends on the environment and company culture. If you work a corporate job that's open 8am-5pm, it doesn't really matter if you prefer nights...
As for the different methodologies, it really just depends on how "on board" with it everyone else is and, ultimately, whether it produces anything. I'm from the Cowboy Coder methodology group, myself, but I have to reign that in a bit when I'm working on a project that requires a lot of collaboration. And no matter how great the methodology is, if it gets in the way of delivering the product on time, no one is going to care.
Waterfall is an example of a flawed, non-working software development model. Unfortunately, it doesn't sound like you're in a position to point this out to your aging co-workers. :)
I recommend you keep asking questions to different people until you find someone (or a few) who seem interested in mentoring you. No education or training that I've received in my career has ever been as valuable as the advice of a few really good mentors that I've had.
Once you find a mentor, I suggest you try to work around their schedule, at least for awhile. Don't feel too bad about asking questions, since that's the only way you can learn (Google it, or ask your question on here first, so you don't ask them too many easy questions).
Good luck!
EDIT: Since only the first two sentences of my original answer seem to be getting read, I thought I'd better provide some more links to support what I said.
I'm a recent college graduate as well. I work with aging developers, but for the most part they embrace agile methodology and understand why it is a necessary for our purposes to use that instead of waterfall. I'll admit that their execution of it sometimes isn't correct, but at least they try.
I find that corporate interests put a much bigger strain on trying to correctly use agile methods. Try using agile when you got a corporate executive on you telling you to plan all the tasks and estimate the hours for 10 sprints at once. Trying to tell them that it will probably change and there's no point will cause spouts of anger. Problems like that make age differences seem trivial.
Language. I don't just mean COBOL vs C#, but also the words used to describe problems and solutions. I have often found myself having difficulty in conversations with older COBOL programmers because we lack the shared language of ABENDS, working storage (old school), methods, automated unit testing (new school), and much more. As with many other problems in life, "knowing is half the battle" — once you recognize the issue, you can work to overcome it.
It sounds to me as if the corporate culture is not one that you feel comfortable with. You have two choices, either get used to it, the culture is not going to change for one very junior programmer, or find another job where the culture is more what you want in a work environment.
The biggest issue of age I've seen in the workplace is that many young people come in with the idea that they are the best, most knowldgeable of the group and what they want is the only way to do things. They think that the work place should revolve around giving them special treatment even though they have accomplished nothing to deserve such treatment. They think they should get the most interesting tasks becasue the boring tasks are beneath them. They don't want to do the hard work of understanding the existing system before trying to change it to whatever is to the coolest new thing. The corporate world just doesn't care if something is cool or fun nor does it care particularly about what the most junior person on the team wants. Maybe that doesn't seem fair to you, but that's the way things are in most companies.
Older workers understand more about how corporate politics work and understand the rules of the game better, so they are more effective in getting what they want. Mind you, I'm not saying that my generation was any better when we were young.
Someday you will be senior, too, and you get to complain about the young and how much worse they are than your generation was. Scary thought, isn't it? (Just when did I turn into my mother? Why am I not still 26?)
From everything I've seen, albeit in a somewhat short period of 3 or so years of industry experience is that all developers fall into 1 of 2 categories regardless of age or experience.
Those that are always learning and realize change especially in the software field is inevitable and accept it happily or full out welcome it.
Developers that feel they are good enough and just "do their job" and have no interest in growth as a developer.
I've seen many developers both younger and older fall into each category, I would never want to work with any person that falls into the category #2 as they really are inferior and are only a detriment to a project. I would gladly take a college intern that is focused on learning and growing (assuming they can work logic correctly) than any person even with decades of "experience" that falls into category #2.
Too often people don't seem to want to bring this up. Experience isn't by itself a description of what to expect of results. There is bad experience and developers that either fall into category #2 or are subjected to category #2 developers all the time will frequently bring worse experience and more poor decisions into a project than a developer that has no experience and such no preconceived notions.
发布评论
评论(12)
当我刚从大学毕业时,我是一个夜猫子,我会在早上晚些时候开始工作,即使在其他人都离开后我又熬夜了几个小时。 与其他人建立融洽的关系确实很难。 毫不奇怪,当我试图提出问题或合作工作时,我也感到不受欢迎。
尽管您的同事使用被认为过时的瀑布方法,但这并不意味着它们工作效率低下。 一个成功的项目更多地取决于团队合作,而不是任何特定的方法。 敏捷方法已经将这一想法编入法典,但它仍然在任何成功的团队中非正式地实践。
你不会改变整个团队的工作方式,所以尝试一下他们的方式一段时间。 在他们上班的时间上班。 在茶歇时与他们交谈并与他们共进午餐。 提出开放式问题并聆听他们的答案。 您可能会惊讶地发现他们可以提供一些有用的经验。
我还建议反对试图说服他们采用敏捷方法。 相反,您实际上可以实践一些敏捷方法。 例如,只需请某人在你身后帮助解决一个棘手的问题(人们通常愿意展示他们解决棘手问题的技能)。 瞧! 你们正在结对编程。 但不要这么称呼它! :-)
When I was right out of college, I was a night owl, and I would roll into work in late morning, even though I stayed late for hours after everyone else left. It was really hard to build rapport with other people. It was no surprise that I also felt unwelcome when I tried to ask questions or work collaboratively.
Even though your coworkers use waterfall methods that are considered outdated, it doesn't mean they work ineffectively. An successful project has more to do with teamwork than any particular methodology. Agile methods have codified this idea, but it's still practiced informally in any successful team.
You aren't going to change the way the whole group does their work, so try it their way for a while. Come into work at the time they do. Talk with them at coffee breaks and go to lunch with them. Ask open-ended questions and listen to their answers. You might be surprised to find they have some useful experience to offer.
I'd also recommend against trying to persuade them to adopt agile methods. Instead, you can practice some agile methods de facto. For example, simply ask someone to look over your shoulder to help on a tough problem (people are usually willing to show their skill at solving tough problems). Voila! You're pair programming. But don't call it that! :-)
可以这么说,我一直站在栅栏的两边。
敏捷编程的问题在于,像任何工具一样,它并不总是适合任务。 在某些环境中,瀑布方法仍然有效。
我认为合作的差异不是来自年龄的差异,而是公司和工作环境所培养的风格。 我刚从学校毕业就在一家国防承包商工作了一段时间,项目中几乎每个人都比我年长得多,但合作量非常大。 另一方面,我曾工作过的公司,每个人的年龄都差不多,而且几乎没有合作。
人们要么喜欢回答问题/接受指导,要么不喜欢。 年龄并不一定会产生很大的影响。 我曾与比我年长和年轻的人一起工作过,但只有少数人真正喜欢回答问题(无论他们是否与项目相关)。
I have been on both sides of the fence, so to speak.
The problem with agile programming is that, like any tool, it isn't always appropriate for the task. In some environments a waterfall methodology is still effective.
I don't think the collaboration differences come from an age difference, but rather that is the style that has been fostered by that company and the work environment. I worked at a defense contractor for a while just out of school where almost everyone on the project was considerably older than I was but there was a very high amount of collaboration. On the flip side, I have worked for companies where everyone was around the same age and there was almost no collaboration.
People will either like answering questions/mentoring or they won't. Age doesn't necessarily make much of a difference. I have worked with people that are older and younger than I am but there have only been a few people that genuinely like answering questions (whether they were project related or not).
很好的问题。 我从事这个行业已经快 50 年了,而且我仍在学习东西。
我想如果我有什么抱怨的话,那就是几乎所有年轻的程序员都上过编程课,他们的脑子里充满了规范性的判断。 这让我想起阿瑟·C·克拉克的小说《城市与星星》,书中向人们灌输了一种对超出城市范围的恐惧,这种恐惧远远超出了理性。
我主要是自学(编程),并且有其他类型的工程背景。 在其他类型的工程中,没有任何想法像魔鬼(即 goto)那样令人恐惧,也没有被提升到神话地位(OOP)。 相反,每个想法都有优点和缺点以及或多或少有用的情况。 一切都基于数学,并且重视创造力。
虽然年轻的程序员聪明、愿意、精力充沛,但我希望他们更加好奇和开放。
Excellent question. I've been in this business almost 50 years, and I'm still learning things.
I guess if I have a gripe it is that nearly all younger programmers had classes in programming, and their heads were filled with normative judgements. It reminds me of the Arthur C. Clarke novel "The City and the Stars", in which the population were indoctrinated with a fear of going outside the city limits that went well beyond reason.
I'm mainly self-taught (in programming), and I have a background in other kinds of engineering. In other kinds of engineering, no idea is feared like the devil (i.e. goto) or elevated to mythic status (OOP). Rather, every idea has pros and cons and situations in which it has more or less utility. Everything is based on math, and inventiveness is valued.
While the younger programmers are bright, willing, and energetic, I wish they were more curious and open-minded.
如果我的语气听起来很刺耳,我提前道歉,当我写这篇文章时,我实际上很有趣,因为你的情况一直在发生,也就是说,你不是第一个注意到工作中“菜鸟”和“老手”之间差异的人;-)
第一个缺陷:“老派”与“新派” - 假设你的前辈是“老派”,因此低人一等被称为偏见,而不是一种偏见开始你的职业生涯的好方法。
很有可能,“老派学生”能够并且愿意在你周围编写代码,尤其是在他们的领域。 由于你的新工作取决于学习他们的领域,也许你应该先学习并与他们交朋友,然后在赢得他们的尊重后尝试教他们......
并且一定要保留你的“新学校” vs 老派”的偏见受到控制; 如果你的“衰老”同事(就好像你对衰老免疫一样!)认为你是一个万事通的“朋克”,那么没有人愿意帮助你。 即使你真的知道一切也没关系,没有人喜欢朋克。 ;-)
因此,在最初的几个月里要假装谦虚,仔细倾听,并准备好在真正工作的第一年学到比在大学里学到的更多的东西!
至于到目前为止您的具体问题,这里有另一种看待它的方式:
作为企业菜鸟,您应该提出很多问题。 只是不要像小孩一样每隔十秒就跳起来打断前辈们的谈话,要存起一大堆问题,每天只打断他们几次。
好消息是,您提出这个问题就意味着您关心,只要您的前辈能够感受到您的这一点,他们也会关心您。
i apologize in advance if the tone of this sounds harsh, i am actually very amused as i write this because your situation happens all the time, i.e. you're not the first to notice the difference between the 'noobs and the 'oldsters at work ;-)
the first flaw: "old school" vs "new school" - assuming your seniors are "old school" and therefore inferior is called prejudice, and is not a very good way to start your career.
chances are, the "old schoolers" can and will code circles around you, especially in their domain. Since your new job depends on learning their domain perhaps you should learn and befriend them first and try to teach them later, after you have earned their respect...
...and definitely keep your "new school vs old school" prejudices in check; if your "aging" coworkers (as if you are immune from aging!) perceive you to be a know-it-all "punk", no one will want to help you. It really doesn't matter even if you actually do know it all, no one likes a punk. ;-)
so pretend to be humble for the first few months, listen carefully, and be ready to learn more in your first year of real work than you ever learned in college!
as for your specific issues so far, here's another way to look at it:
as a corporate noob, you are expected to ask a lot of questions. Just don't jump up and interrupt the seniors every ten seconds like a toddler, save up a hand full of questions and interrupt them only a few times per day.
the good news is, the fact that you asked this question means that you care, and as long as your seniors can sense this about you they will care about you, too.
我认为您所处理的问题与年龄无关。 我与年龄是我两倍的程序员有过很好的接触经历,并且从他们身上学到了很多东西。 反之亦然。
有一天我会成为一名老程序员,但这并不意味着我必须成为“老派”。
继续学习并开放地接受新想法。
I don't think the issues you are dealing with are age dependent. I've had great experiences with programmers twice my age and have learned a lot from them. The converse is true as well.
Someday I'll be an old programmer, but that doesn't mean that I have to be "old school".
Continue learning and be open to accept new ideas.
你需要融入这个群体,他们不会改变来配合你,但这并不意味着你不能逐渐带来改变。
虽然您会发现有些人不喜欢回答问题,但大多数人都会特别愿意,如果您表现出您对该主题真正感兴趣的话。
向团队领导/经理询问一个您可以使用更现代的方法完成的小项目(敏捷可能很难自己完成)。 向人们展示它是有效的,并展示它如何变得更好。
保持机智,尽量不要让别人不高兴。 记住“年老和背叛会打败年轻和技巧”。 不要卷入一场你无法获胜的战斗。 人们会抵制改变。
You need to fit in with the group, They won't change to match you, but that does not mean you cannot gradually bring in change.
While you will find some people who don't like to answer questions, most people will especially if you show you are genuinely interested in the subject.
Ask the team leader / manager for a small project you can do using more modern methods (agile might be difficult to do by self). Show people that it works and demonstrate how it is better.
Be tactful and try not to upset people. remember "old age and treachery will beat youth and skill". Don't get in a fight you cannot win. People will resist change.
一如既往,这取决于环境和公司文化。 如果你的公司工作时间是早上 8 点到下午 5 点,那么你是否喜欢晚上并不重要……
至于不同的方法,这实际上取决于其他人的“参与度”,最终,它是否产生任何东西。 我本人来自 Cowboy Coder 方法论小组,但当我从事需要大量协作的项目时,我必须稍微控制一下。 无论方法有多么出色,如果它妨碍了按时交付产品,那么没有人会在意。
As always it depends on the environment and company culture. If you work a corporate job that's open 8am-5pm, it doesn't really matter if you prefer nights...
As for the different methodologies, it really just depends on how "on board" with it everyone else is and, ultimately, whether it produces anything. I'm from the Cowboy Coder methodology group, myself, but I have to reign that in a bit when I'm working on a project that requires a lot of collaboration. And no matter how great the methodology is, if it gets in the way of delivering the product on time, no one is going to care.
Waterfall 是一个有缺陷、无法工作的软件开发模型的示例。 不幸的是,您似乎无法向年迈的同事指出这一点。 :)
我建议您不断向不同的人提问,直到找到一个(或几个)似乎有兴趣指导您的人。 我在职业生涯中接受过的任何教育或培训都没有像我所拥有的一些非常好的导师的建议那样有价值。
一旦你找到了一位导师,我建议你尝试按照他们的日程安排工作,至少暂时如此。 不要对提出问题感到太难过,因为这是你学习的唯一方法(谷歌搜索,或者先在这里问你的问题,这样你就不会问他们太多简单的问题)。
祝你好运!
编辑:由于似乎只有我原始答案的前两句话被阅读,我想我最好提供更多链接来支持我所说的。
请注意,最后一篇是 Royce 的原始论文。
Waterfall is an example of a flawed, non-working software development model. Unfortunately, it doesn't sound like you're in a position to point this out to your aging co-workers. :)
I recommend you keep asking questions to different people until you find someone (or a few) who seem interested in mentoring you. No education or training that I've received in my career has ever been as valuable as the advice of a few really good mentors that I've had.
Once you find a mentor, I suggest you try to work around their schedule, at least for awhile. Don't feel too bad about asking questions, since that's the only way you can learn (Google it, or ask your question on here first, so you don't ask them too many easy questions).
Good luck!
EDIT: Since only the first two sentences of my original answer seem to be getting read, I thought I'd better provide some more links to support what I said.
Note that the last one is Royce's original paper.
我也是一名刚毕业的大学毕业生。 我与老年开发人员一起工作,但在大多数情况下,他们都接受敏捷方法,并理解为什么我们的目的有必要使用敏捷方法而不是瀑布式方法。 我承认他们的执行有时是不正确的,但至少他们尝试了。
我发现企业利益对正确使用敏捷方法施加了更大的压力。 当公司高管告诉你计划所有任务并同时估计 10 个冲刺的时间时,请尝试使用敏捷。 试图告诉他们情况可能会改变并且没有任何意义会引起愤怒。 诸如此类的问题让年龄差异显得微不足道。
I'm a recent college graduate as well. I work with aging developers, but for the most part they embrace agile methodology and understand why it is a necessary for our purposes to use that instead of waterfall. I'll admit that their execution of it sometimes isn't correct, but at least they try.
I find that corporate interests put a much bigger strain on trying to correctly use agile methods. Try using agile when you got a corporate executive on you telling you to plan all the tasks and estimate the hours for 10 sprints at once. Trying to tell them that it will probably change and there's no point will cause spouts of anger. Problems like that make age differences seem trivial.
语言。 我不仅仅指 COBOL 与 C# 的比较,还指用于描述问题和解决方案的词语。 我经常发现自己在与老 COBOL 程序员交谈时遇到困难,因为我们缺乏 ABENDS、工作存储(旧派)、方法、自动化单元测试(新派)等共享语言。 与生活中的许多其他问题一样,“了解是成功的一半”——一旦你认识到问题,你就可以努力克服它。
Language. I don't just mean COBOL vs C#, but also the words used to describe problems and solutions. I have often found myself having difficulty in conversations with older COBOL programmers because we lack the shared language of ABENDS, working storage (old school), methods, automated unit testing (new school), and much more. As with many other problems in life, "knowing is half the battle" — once you recognize the issue, you can work to overcome it.
在我看来,这种企业文化似乎不是一种让你感到舒服的文化。 你有两种选择,要么习惯它,对于一个非常初级的程序员来说文化不会改变,要么找到另一份工作,文化更符合你在工作环境中想要的。
我在工作场所看到的最大的年龄问题是,许多年轻人进来时都认为自己是团队中最优秀、最博学的,他们想要的就是做事的唯一方法。 他们认为工作场所应该以给予他们特殊待遇为中心,即使他们没有取得任何成就值得这种待遇。 他们认为他们应该接受最有趣的任务,因为无聊的任务在他们之下。 他们不想在尝试将现有系统更改为最酷的新事物之前进行理解现有系统的艰苦工作。 企业界并不关心某件事是否酷或有趣,也不会特别关心团队中资历最浅的人想要什么。 也许这对你来说不公平,但这就是大多数公司的情况。
年长的员工更了解公司政治如何运作,也更好地理解游戏规则,因此他们能够更有效地获得自己想要的东西。 请注意,我并不是说我们这一代人年轻时就更好。
有一天,你也会成为老年人,你会抱怨年轻人,抱怨他们比你这一代人差多少。 可怕的想法,不是吗? (我什么时候变成妈妈了?我怎么还没26岁?)
It sounds to me as if the corporate culture is not one that you feel comfortable with. You have two choices, either get used to it, the culture is not going to change for one very junior programmer, or find another job where the culture is more what you want in a work environment.
The biggest issue of age I've seen in the workplace is that many young people come in with the idea that they are the best, most knowldgeable of the group and what they want is the only way to do things. They think that the work place should revolve around giving them special treatment even though they have accomplished nothing to deserve such treatment. They think they should get the most interesting tasks becasue the boring tasks are beneath them. They don't want to do the hard work of understanding the existing system before trying to change it to whatever is to the coolest new thing. The corporate world just doesn't care if something is cool or fun nor does it care particularly about what the most junior person on the team wants. Maybe that doesn't seem fair to you, but that's the way things are in most companies.
Older workers understand more about how corporate politics work and understand the rules of the game better, so they are more effective in getting what they want. Mind you, I'm not saying that my generation was any better when we were young.
Someday you will be senior, too, and you get to complain about the young and how much worse they are than your generation was. Scary thought, isn't it? (Just when did I turn into my mother? Why am I not still 26?)
从我所看到的一切来看,尽管在较短的 3 年左右的行业经验中,所有开发人员都属于以下两类之一,无论年龄或经验如何。
那些不断学习并认识到变化(尤其是在软件领域)是不可避免的,并愉快地接受它或全力欢迎它。
那些不断学习并认识到变化(
开发人员认为自己足够好,只是“做好自己的工作”,对作为开发人员的成长不感兴趣。
开发人员觉得自己足够好
我见过许多年轻和年长的开发人员都属于每个类别,我永远不想与任何属于第二类的人一起工作,因为他们确实很差劲,只会对项目造成损害。 我很乐意接受一位专注于学习和成长的大学实习生(假设他们能够正确地工作逻辑),而不是任何拥有数十年“经验”的人,属于第二类。
很多时候人们似乎不想提起这个问题。 经验本身并不是对预期结果的描述。 与没有经验且没有先入为主观念的开发人员相比,有糟糕的经验的开发人员要么属于类别#2,要么始终受到类别#2开发人员的影响,通常会给项目带来更糟糕的体验和更糟糕的决策。
From everything I've seen, albeit in a somewhat short period of 3 or so years of industry experience is that all developers fall into 1 of 2 categories regardless of age or experience.
Those that are always learning and realize change especially in the software field is inevitable and accept it happily or full out welcome it.
Developers that feel they are good enough and just "do their job" and have no interest in growth as a developer.
I've seen many developers both younger and older fall into each category, I would never want to work with any person that falls into the category #2 as they really are inferior and are only a detriment to a project. I would gladly take a college intern that is focused on learning and growing (assuming they can work logic correctly) than any person even with decades of "experience" that falls into category #2.
Too often people don't seem to want to bring this up. Experience isn't by itself a description of what to expect of results. There is bad experience and developers that either fall into category #2 or are subjected to category #2 developers all the time will frequently bring worse experience and more poor decisions into a project than a developer that has no experience and such no preconceived notions.