Hacker News Reader

Comment by thatjsguy | Hacker News Reader

I mean this in the nicest possible way: I see this all the time with the JavaScript set and I am absolutely not the least bit surprised. I used to work on a team that was TypeScript top to bottom, with people who didn’t really even understand how to debug (they were mostly bootcamp juniors). Whenever something would break, if restating it didn’t work, you know what they’d try? Yup, upgrading random dependencies. Refactoring was also pretty popular, although it usually just ended up making things more complicated.

It’s silly to suggest that JavaScript itself is somehow responsible for this. It’s obvioisly just a tool. But I have to say, the most professional cluelessness I’ve ever encountered was in the JS ecosystem.

View on HN

I concur. I’m having a hard time not coming off as a dick while trying to opine on how amateurish I think this is. I like JS but the devs and ecosystem leaves me wanting.

The sad thing is that this is in my experience the norm. Not just in frontend/js either. It's everywhere.

> the most professional cluelessness I’ve ever encountered was in the JS ecosystem.

A testament to how low the barrier of entry has gotten. It's both a good and bad thing at the same time.

It however leads to having to be ever more so vigilant about at least your first layer of dependencies in that ecosystem, if you do want to be professional.

The higher the barrier of entry is to a language, the more likely it is that when you're pulling in dependencies, the code isn't amateurish

Incidentally this is probably why JS juniors think to upgrade dependencies when they encounter unknown situations... a lot of problems in JS do come from your dependencies.

It's been a long time goal of the software dev community to lower barriers to entry through bootcamps and such, in an attempt to "democratize software".

And the result is unsurprisingly poorer quality software. So why is it a good thing?

It's a good thing because it avoids the problem of blocking people from entering for largely arbitrary reasons (i.e., country of birth; exposure to computers in childhood).

I don't think the problem of quality should be addressed by arbitrarily axing people from the field. Some sort of a standardization / accreditation seems like a better approach.

The country of birth and exposure to computers in childhood are not preventing people from becoming software engineers. I'm living proof of that, as are many people all around the world.

And axing is not arbitrary, it's generally done based on experience and know-how. Not everyone can or should become a software engineer.

Because people think bad software is better than no software

So I completely agree, but let me play devil's advocate.

If you do go and track down the problem in your depedency and file a bug, one of two things is likely to happen: they close it and say it's fixed in the latest version or they refuse to accept your bug because it's filed against an old version.

Skipping the track it down part and just jumping into upgrading can be a time saver. It works fairly well if you fit into the 'common' part of the user base with frequent updates. (Incidentally dependencies with frequent updates are kind of a pain)

> If you do go and track down the problem in your depedency

This is the part the parent's cow-orkers didn't perform. There's nothing wrong in updating a dependency to include the fix for the problem you're experiencing. But the people in question were apparently too lazy/clueless to even track down the problem, opting for randomly upgrading stuff instead.

There is a possibility you found a bug and a workaround is known/suggested

There is the possibility you are told you made a mistake in thinking it’s a bug with the library

>If you do go and track down the problem in your depedency and file a bug

There's a difference between upgrading your dependencies because you traced a problem that you know is fixed in the newer version and upgrading your dependencies because you hope it fixes a problem you don't understand.

Js is currently more visible than other platforms, also the sheer size of the community takes a role. Idiots are everywhere.

The current trend and curse of DRY and NIH is to solve stuff by adding dependencies and gluing them together. Rookies expect that some software solved the problem at hand without thinking about it. Even worse is that they even apply this to rather simple things. The problem of OP - countig items inefficiently - is absurdly common. IMHO this is the heart of the problem, the new generation is highly uneducated how to handle data.

Are you... in the JS ecosystem yourself?

I used to be in the Java ecosystem, the C# ecosystem, the PHP ecosystem... and I could have made the statement "the most professional cluelessness I’ve ever encountered was in the X ecosystem."

I think it's just an industry thing.

Having spent more than a decade working and hiring in the Java world, I'm inclined to agree.

Having spent much of the past year writing Rust and interacting with that community, I'm inclined to disagree.

My overall feeling is that it isn't only JavaScript, but it is JavaScript and languages that attract a higher caliber of developer don't suffer from this problem the way that languages that appeal to a wider demographic do.

I feel like JavaScript is a bit of a special case, because there are people out there who, 5-10 years ago, did HTML, CSS, and jQuery, and called themselves "front-end developers", and then along came Node, so they read a few tutorials because it was just JavaScript, and they got some stuff vaguely working and then rebranded themselves as "full-stack developers" - throw in Firebase and Heroku and you have people who can store data and deploy applications to the web with only the most superficial understanding of what they're doing (and yes, that's how you end up spending $30K accidentally on Firebase and thinking that upgrading Angular might fix the problem).

It has to do with the barrier to entry.

PHP, Ruby on Rails, and jQuery are other technologies that had low barrier to entry received the attention of the "unwashed masses".

This being 2018, JS has very low barrier to adoption (Have a web browser? You have a JS runtime.) and nature runs its course.

Oh come on. Tech does not need barriers to entry. It just needs debugging and improving one's code to also have a low barrier to entry.

Software engineering is very hard and can't be taught in bootcamps, blog posts or on the job. It takes years of concentrated effort and quality learning material.

A significant number of graduates of computer science couldn't do software engineering after graduation even before.

That barrier to entry is designed to protect society from poor quality software and actual software engineers from having to suffer through picking up the broken pieces after those people that were helped to jump the barrier.

Type with one hand, make your software better!

Where can it be taught, then? There are no resources for this right now, mostly people are left to their own devices.

Most barriers to entry are not designed to protect anyone, they're designed to preserve power. To protect people from bad products, you need regulation, accreditation, etc.

There are very good universities focusing on computer science and software engineering in most countries.

This is the first step. Then one needs to find a company with a good engineering culture, apply the theory they learned and gather experience. Ideally one should find a qualified engineer as mentor.

Self-study and being aware of developments in the profession are the last piece of the puzzle.

Yes, some people won't be able to do some of these things and as a result they won't be good software engineers. They could still be successful programers, the two aren't necessarily related.

This seems more like what you would like to happen, not what actually happens to most people, so it doesn't really qualify as resources.

Universities ?

Most universities don't even cover something as basic as version control. Monitoring? Forget it.

> Oh come on

Apologies if I suggested otherwise, but of course programming doesn't need barriers to entry. Just like PCs and the internet don't.

Something about jQuery does remind me of JavaScript

Most JS Devs think debugging is just console.log(), that's nice and all, but it's not connecting a debugger, adding breakpoints, and watching the data go around. The amount of times I've caught issues with just a simple game of follow the calls and objects around with the debugger.

As soon as I got to the part where they just upgraded a bunch of libraries.. I rolled my eyes, I was expecting a serious look at something, perhaps even a bug in Firebase or something in-depth. But nope, what we got was "Ooops I didn't think about the number of API/DB calls we were making because we don't think that way, we just assume everything is the fault of the libraries we use."

That kind of attitude is why I cannot wait to abandon JS all together..

> Refactoring was also pretty popular, although it usually just ended up making things more complicated.

Yeah I'm guilty of this one. Sometimes you know the problem is somewhere in a particular area of code, but that code is all over the place. Pulling it apart and refactoring it can be a good way of understanding all its dependencies. If the refactoring doesn't help, just don't check it in..

I don’t think it’s necessarily something to be “guilty” for. Especially if it’s someone else’s code I’m debugging, I agree that rewriting it “in my own words” can be a great way to understand what’s going on. Like you said, its not like you have to check in the changes.

However it sounds like people are talking about refactoring an app solely for the purpose of hoping that the refactor shakes out whatever bugs. That sounds like the debugging equivalent of “8 hours of coding saved me 30 minutes of planning”

r/Javascript/PHP/g # 7 years ago

r/Javascript/Visual Basic/g # 14 years ago

r/Javascript/Basic/g # 21 years ago

Us old/wise/thoughtful folk have denigrated the tools that young/foolish/impetuous kids use since we were they.

We need both: yes, these young people made some mistakes, but I'm in awe at what they achieved. They built, triaged and fixed a massively successful campaign in the time I would have taken scoping out the requirements. Oh, and gladhandled Google into paying the tab... impressive!

[Update: formatting]

Reply on news.ycombinator.com