Thanks for making this post. Any other similarly experienced devs please feel free to chime in!
Some context before my questions:
I have the opportunity to work on a project with a lead who has 30+ years experience with CS & math degrees. He prefers to avoid libraries, tools, modern IDEs etc. Anything that modifies the code we would write is out (Babel, Prettier code formatter etc). All valid JavaScript is allowed, no coding standards are imposed. No git branches because he doesn't like the possibility of merge conflicts. jQuery is embedded and won't be going anywhere because he likes its utility. JS files are loaded via script tags without any kind of modules. Functions are hundreds of lines long. Many suggestions of making improvements to the way things are done have been met with strong resistance. I think there is value to working on the project because I would have to build everything from scratch w/out crutches and it's an interesting domain. However, I am concerned about the opportunity costs in terms of time I could spend learning more modern dev practices. I'm also concerned that getting quality 1:1 time with a person that espouses the 'sink-or-swim' school of programming might be very difficult.
Would you view the legacy nature of the project and entrenched attitudes of the lead as red flags or opportunities?
What is a good balance of knowing fundamentals/legacy vs. modern, marketable practices?
What advice would you give to younger programmers on how to interact with programmers of your generation who are set in their ways?
Rather than a bio, I'll direct you to my AMA: https://dev.to/johnmunsch/i-have-been-a-professional-developer-for-31-years-and-im-53-now-ask-me-anything-5dlf
I hate to sell out a fellow developer but almost everything you described above doesn't seem like an opportunity to me, it seems like a whole series of red flags. About the only thing your lead and I agree on is no great love of Babel/TypeScript (though I use TS at work, I use straight ES6 code on my own personal projects outside of work). In my case however, it's just because I don't like a system with a lot of tooling and all of the modern browsers (Note: I'm excluding IE11 from that designation) handle ES6 just fine already.
It really doesn't seem to be about 'sink-or-swim' as much as it seems to be about discomforting an individual from his/her personal preferences. I'm going to come back to that in question 3.
Tough to say on that. You really do need to know your fundamentals, JavaScript, some kind of component system (Web Components, Angular, React, Vue), etc. But I think it is also super valuable to understand how to build a system as a whole. If someone asks you to explain how the various component systems differ or why someone might use Redux or even what concepts like dependency injection, GraphQL, or continuous integration are, then I think you should be able to do that. If someone asks you a question, do you understand it so well that you can answer it simply even if they are not technical at all.
In my case, my most marketable skill for quite some time has proven to be the ability to look at somebody and say convincingly, "I can fix your problems." Whether those problems were with performance, adding new features or fix bugs in an existing codebase, rewrite a codebase to make it modern, or the ability to get best practices of version control and continuous integration into place. I can listen to the problems they have and explain some of what they might need to fix it and tell a believable story about how I've helped others solve those problems in the past.
Let me extend that a little bit for you, because there are younger developers who at present think that webpack + TypeScript + React is literally the only way to build anything. They are as unwilling to consider any other tech because it would require them to learn something new and to consider that maybe some of the stuff they already know is actually starting to fade. It's not an age thing, it's a mindset.
Change is going to happen. Your favorite tools aren't going to be the favorites forever, it's a given. jQuery was king, it's not anymore, AngularJS, ditto. React is currently king but tomorrow it may not be. Ask them a simple question, "What is your current plan for change? What do you plan to introduce to simplify coding over the next few years, what do you plan to phase out, and how do you plan to acquire new talent with a good tech stack that solves our problems while still moving forward to well supported solutions?"
If you can lay out a convincing set of reasons why adoption of something new could make things better while not imposing a lot of tech debt and it would give the project a longer/better lifespan and they aren't willing to even consider it, do you want to work with that person or those people? If they can't articulate some kind of plan and they won't listen to yours, that is a big red flag.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi John,
Thanks for making this post. Any other similarly experienced devs please feel free to chime in!
Some context before my questions:
I have the opportunity to work on a project with a lead who has 30+ years experience with CS & math degrees. He prefers to avoid libraries, tools, modern IDEs etc. Anything that modifies the code we would write is out (Babel, Prettier code formatter etc). All valid JavaScript is allowed, no coding standards are imposed. No git branches because he doesn't like the possibility of merge conflicts. jQuery is embedded and won't be going anywhere because he likes its utility. JS files are loaded via script tags without any kind of modules. Functions are hundreds of lines long. Many suggestions of making improvements to the way things are done have been met with strong resistance. I think there is value to working on the project because I would have to build everything from scratch w/out crutches and it's an interesting domain. However, I am concerned about the opportunity costs in terms of time I could spend learning more modern dev practices. I'm also concerned that getting quality 1:1 time with a person that espouses the 'sink-or-swim' school of programming might be very difficult.
Would you view the legacy nature of the project and entrenched attitudes of the lead as red flags or opportunities?
What is a good balance of knowing fundamentals/legacy vs. modern, marketable practices?
What advice would you give to younger programmers on how to interact with programmers of your generation who are set in their ways?
I hate to sell out a fellow developer but almost everything you described above doesn't seem like an opportunity to me, it seems like a whole series of red flags. About the only thing your lead and I agree on is no great love of Babel/TypeScript (though I use TS at work, I use straight ES6 code on my own personal projects outside of work). In my case however, it's just because I don't like a system with a lot of tooling and all of the modern browsers (Note: I'm excluding IE11 from that designation) handle ES6 just fine already.
It really doesn't seem to be about 'sink-or-swim' as much as it seems to be about discomforting an individual from his/her personal preferences. I'm going to come back to that in question 3.
Tough to say on that. You really do need to know your fundamentals, JavaScript, some kind of component system (Web Components, Angular, React, Vue), etc. But I think it is also super valuable to understand how to build a system as a whole. If someone asks you to explain how the various component systems differ or why someone might use Redux or even what concepts like dependency injection, GraphQL, or continuous integration are, then I think you should be able to do that. If someone asks you a question, do you understand it so well that you can answer it simply even if they are not technical at all.
In my case, my most marketable skill for quite some time has proven to be the ability to look at somebody and say convincingly, "I can fix your problems." Whether those problems were with performance, adding new features or fix bugs in an existing codebase, rewrite a codebase to make it modern, or the ability to get best practices of version control and continuous integration into place. I can listen to the problems they have and explain some of what they might need to fix it and tell a believable story about how I've helped others solve those problems in the past.
Let me extend that a little bit for you, because there are younger developers who at present think that webpack + TypeScript + React is literally the only way to build anything. They are as unwilling to consider any other tech because it would require them to learn something new and to consider that maybe some of the stuff they already know is actually starting to fade. It's not an age thing, it's a mindset.
Change is going to happen. Your favorite tools aren't going to be the favorites forever, it's a given. jQuery was king, it's not anymore, AngularJS, ditto. React is currently king but tomorrow it may not be. Ask them a simple question, "What is your current plan for change? What do you plan to introduce to simplify coding over the next few years, what do you plan to phase out, and how do you plan to acquire new talent with a good tech stack that solves our problems while still moving forward to well supported solutions?"
If you can lay out a convincing set of reasons why adoption of something new could make things better while not imposing a lot of tech debt and it would give the project a longer/better lifespan and they aren't willing to even consider it, do you want to work with that person or those people? If they can't articulate some kind of plan and they won't listen to yours, that is a big red flag.