Remix.run Logo
austin-cheney 4 days ago

I can provide you with some missing background as I was a prior full time JavaScript/TypeScript developer for 15 years.

Most people writing JavaScript code for employment cannot really program. It is not a result of intellectual impairment, but appears to be more a training and cultural deficit in the work force. The result is extreme anxiety at the mere idea of writing original code, even when trivial in size and scope. The responses vary but often take the form of reused cliches of which some don't even directly apply.

What's weird about this is that it is mostly limited to the employed workforce. Developers who are self-taught or spend as much time writing personal code on side projects don't have this anxiety. This is weird because the resulting hobby projects tend to be substantially more durable than products funded by employment that are otherwise better tested by paid QA staff.

As a proof ask any JavaScript team at your employment to build their next project without a large framework and just observe how they respond both verbally and non-verbally.

sangeeth96 4 days ago | parent | next [-]

> Most people writing JavaScript code for employment cannot really program.

> As a proof ask any JavaScript team at your employment to build their next project without a large framework and just observe how they respond both verbally and non-verbally.

With an assumption like that, I bet the answer is mostly the same if you ask any Java/Python dev for example — build your next microservice/API without Spring or DRF/Flask.

Even though I only clock at about 5YOE, I'm really tired of hearing these terrible takes since I've met plentiful share of non-JS backend folks for example, who have no idea about basic API design, design patterns or even how to properly use the same framework they use for every single project.

3 days ago | parent [-]
[deleted]
jbreckmckye 4 days ago | parent | prev | next [-]

> The responses vary but often take the form of reused cliches of which some don't even directly apply.

"It has been tested by a 1000 people before me"

"What if there is an upstream optimisation?"

"I'm just here to focus on Business Problems™"

"It reduces cognitive load"

---

Whilst I think you are exaggerating, I do recognise this phenomenon. For me, it was during the pandemic when I had to train / support a lot of bootcamp grads and new entrants to the career. They were anxious to perform in their new career and interpreted that as shipping tickets as fast as possible.

These developers were not dumb but they had... like, no drive at all to engage with problems. Most programmers should enjoy problems, not develop a kind of bad feeling behind the eyes, or a tightness in their chest. But for these folks, a problem was a threat, of a bad status update at their daily Scrum.

Dependencies are a socially condoned shortcut to that. You can use a library and look like a sensible and pragmatic engineer. When everyone around you appears to accept this as the norm, it's too easy to just go with the flow.

I think it is a change in the psychological demographic too. This will sound fanciful. But tech used to select for very independent, stubborn, disagreeable people. Now, agreeableness is king. And what is more agreeable than using dependencies?

austin-cheney 4 days ago | parent | next [-]

The two I hear the most are:

reinventing the wheel

some comparison to assembly

12_throw_away 4 days ago | parent | prev | next [-]

> They were anxious to perform in their new career and interpreted that as shipping tickets as fast as possible. [...].. they had like, no drive at all to engage with problems

To be honest, I think these programmers understood their jobs perfectly here. Their bosses view programmers as commodities, are not concerned with robustness, maintainability, or technical merit - they want a crank they can turn that spits out features.

jbreckmckye 3 days ago | parent [-]

I think you are right. Those feature factory teams were the ones hiring as fast as they could; they didn't need to filter on programming fundamentals; and they could exploit the anxiety of junior developers who sensed the market was becoming competitive.

notmyjob 4 days ago | parent | prev [-]

Not sure about “agreeableness” but I can see group think and disagreeableness to anything that falls outside of the group think. Cargo cult coding isn’t a new thing but the demographic shift you note is real. But is that not just the commodification of programming labor?

IshKebab 4 days ago | parent | prev | next [-]

Not my experience at all. It's more like a) JS devs view NPM packages as a mark of pride and so they try to make as many as possible (there are people proud of maintaining hundreds of packages, which is obviously dumb), and b) people are lazy and will take a ready-made solution if it's available, and c) there are a lot of JavaScript developers.

The main reasons you don't see this in other languages is they don't have so many developers, and their packaging ecosystems are generally waaay higher friction. Rust is just as easy, but way higher skill level. Python is... not awful but it's definitely still a pain to publish packages for. C++, yeah why even bother.

If Python ever official adopts uv and we get a nice `uv publish` command then you will absolutely see the same thing there.

3 days ago | parent | next [-]
[deleted]
pixl97 4 days ago | parent | prev [-]

It seems in some large businesses code ownership is an issue too.

If you NPM import that's now part of your SCA/SBOM/CI to monitor and keep secure.

If you write code, it's now your problem to secure and manage.

xorcist 4 days ago | parent | prev | next [-]

If Javascript people were bad programmers, we wouldn't see two new frontend frameworks per year. Many of them are ambitious projects that must have had thousands of hours put in by people who know the language well.

The observation is real however. But every culture develops its own quirks and ideas, and for some reason this has just become a fundamental part of Javascript's. It's hard to know why after the fact, but perhaps it could spark the interest of sociologists who can enlighten us.

skydhash 4 days ago | parent [-]

There's a reason you don't see two frameworks every year in another language. Being a good programmer is recognizing when a problem is solved and actually contributing to the solution instead of recreating it. Coding a new system can be done really quickly as you're mostly focusing on the happy path. The real work is ironing out bugs and optimizing the performance.

crabmusket 4 days ago | parent | prev | next [-]

Glad to see someone else identify the anxiety at the root of the culture.

After an npm incident in 2020 I wrote up my thoughts. I argue that this anxiety is actually somewhat unique to JS which is why we don't see a similar culture in other languages ecosystems

https://crabmusket.net/java-scripts-ecosystem-is-uniquely-pa...

Basically, the sources of paranoia in the ecosystem are

1. Weak dynamic typing

2. Runtime (browser engineers) diversity and compatibility issues

3. Bundle size (the "physics" of code on a website)

In combination these three things have made JS's ecosystem really psychologically reliant on other people's code.

duped 4 days ago | parent | prev [-]

I don't quite know how to put this thought together yet, but I've noticed that no one quite hates programming more than this class of programmers. It's like playing on a football team with people who hate football.

A key phrase that comes up is "this is a solved problem." So what? You should want to solve it yourself, too. It's the PM's job to tell us not to.