Hacker News Reader

Comment by PebblesHD | Hacker News Reader

Would be interesting to see a follow up in a few months on whether the tradeoff from a heavier but widely used stack to a possibly more performant but certainly more esoteric one works out positively.

I can’t imagine trying to hire for a front end developer to work on something like this is that easy compared with finding a react dev.

View on HN

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?

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’.

Go is a pretty popular language for web servers, so while "react devs who know go" might be small, "go devs who know react" might have large overlap.

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.

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.

Maybe JS devs will learn to stop reinventing the wheel every half a year thanks to the knowledge cutoffs.

No. JavaScript is a mid-level developer’s heaven — everyone has a right to framework

React was released 11 years ago and is the de facto default choice for most of the web applications.

They have definitely chilled out on "reinventing the wheel" quite a few years ago.

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.

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.

In the brave new world of chatGPT, developers will be in for a shock once they get good enough to generate executables.

It will be like looking for a job as Assembly programmer, when everyone else has moved into high level programming languages.

Better improve those architecture design and social skills.

If anything, LLMs require "boring tech" much more so than people.

Sure, it may know the language, but God save us from all the hallucinating in case of some niche lib

Reply on news.ycombinator.com