Do you think maybe this is less of a big deal in the brave new world of chatGPT.
I know I have zero worries about having to code in a new language or framework with the ability to get answers so quickly to my dumb questions, but maybe that is because I’m still choosing languages and frameworks that are fairly popular and have so much online documentation that the LLMs know about them, and if something is really esoteric maybe the help wouldn’t be that good?
Due to the restrictions (short term at least) when it comes to training data and availability of documentation, I believe coding in a new language or framework becomes an even bigger mountain than usual due to chatGPT providing misleading information.
This is made worse if there are breaking changes in a new release that you are using. Even when the thing is popular, like Svelte, it was giving me outdated information before the introduction of Runes that often led to deadend packages or solutions that resulted in odd performance.
I'm sure eventually it'll be resolved, but ultimately I would only recommend people sticking to more traditional languages and frameworks that have been around for many years now and are relatively unchanging in order to benefit from chatGPT. Basically, the more projects you find using that thing on github, the better your outcome is going to be with current LLMs.
No? React reinvents itself constantly. I've worked on React websites and am currently working on a React Native app. React was first classes-based, now there's functions, hooks and it will soon get a compiler. Not to mention that they nudge you to use Next.js (and Expo for RN) now. Svelte did the same with the switch to these god awful Runes. Not to mention a lot of libraries that constantly get deprecated or don't work anymore with React 19.
I think companies are way too worried about hiring developers based on their specific technology they’ve previously worked with.
Unless maybe you are doing something radically different, like web development to graphics drivers or something.
Development skills are typically very transferable between languages, libraries, etc. And I think it’s healthy for developers to branch out and try new tech stacks from time to time.
I’d be more worried about a developer who doesn’t have the versatility to pick up something new. Because they probably also haven’t invested the time and effort to really understand what they’ve worked on in the past.
Your example of web devs writing drivers is why I posed the question, as go is very much not a widely used web dev language, and the devs who know go may not at all understand the common web development patterns and practices.
Rather than the specific language, I’m more thinking of the domain, meaning ‘web devs who know go’ being a smaller cohort than ‘webdevs who know react’.
I think it’s better to have somebody who has a deep understanding of all layers of the application rather than only one part.
If a developer is already an expert in the back end using Go, then great. Maybe they’ll bring a different perspective when they work on the front end. And they will probably enjoy a new challenge.
Web development is not so hard that a good developer can’t learn the basics in a couple months, especially with some mentoring.
I wouldn't say that web dev is "hard" as in any part would need a very deep knowledge, but it sure as hell very wide.
There are so many things and concepts, multiple must-know languages, browser quirks, some networking knowledge, CORS, etc. If you do use an "industry-strength" backend framework then the complexity surely drops, e.g. it will handle injections and stuff, but not having heard at least a bit about what your framework does for you, and reinventing the wheel can go really bad really fast.
If you’re trying to build a team from scratch, you probably want to hire devs with relevant experience.
But I think it’s a sign of an unhealthy or immature team if it is unable to onboard and train new developers.
You are right that a new developer could easily make a lot of mistakes, but it is the responsibility of the senior developers on the team to give feedback and review the code of less experienced members.
An LLM makes it even more beneficial to use popular tooling, because it's going to be better at answering questions about it. Meanwhile it's basically useless for whatever I'm doing at work with internal tools unless I have a pure language question (which for C++ is still ehh).
Maybe this is what will get people to stop reinventing wheels.
I know I have zero worries about having to code in a new language or framework with the ability to get answers so quickly to my dumb questions, but maybe that is because I’m still choosing languages and frameworks that are fairly popular and have so much online documentation that the LLMs know about them, and if something is really esoteric maybe the help wouldn’t be that good?