Indeed. I've noticed an increasing number of people who call themselves "developers" and appear to create software, but all they can do is follow step-by-step tutorials to glue together some massively bloated thing that they have absolutely no understanding of, much less the skills to debug it when something doesn't work perfectly as expected.
That won't really happen, right? No Computer Science (CS) professor would designate special cloud Interactive Development Environments (IDEs) to students.
On the other hand, it would really resolve a lot of "doesn't work on my machine" issues.
GitHub has said one of the largest growing areas for Codespaces (cloud IDE) usage is Education.
It's already happening. It does resolve a lot of "doesn't work on my machine" issues; it does leave some questions about how much students see of the "ground" below the Clouds.
Setup some obscure software, with poor documentation, build something nice on top of it, then rewrite it because some fundamental assumption is broken, sounds like this kind of first year of cs course we should have.
The idea being weeding out those not as passionate about computers.
Welcome to the world of npm and supply-chain hell
Here's what I mean. There's a difference between:
* Using an IDE knowing what you want to do but you just like the convenience. You know what the IDE is doing for you, but you want your tool to do it for you quickly and get out of the way. If the IDE does something you don't know, you try to learn what this was.
* Using an IDE because you literally can't work without one. Not knowing your programming language and depending 100% on autocomplete to do most stuff. Not even knowing how to write the files that the IDE automatically updates when doing certain things.
It's a subtle difference, but the former is more likely to leave better comments in a web-based code review ("pull request") than the latter.
And if a project consists only of the latter type, it's unlikely that there will be comments like:
* "Use this other class with the same name but different package because this one is buffered" (because depending on autocomplete without knowing the language prevented them from even caring about which import to use, or the difference between those, as long as it works).
* "Would this change affect this other file that's not in the PR but calls this function a thousand times per request?" (because not knowing their own projects general structure due to depending on their IDE for navigation, so they're more likely to NOT notice a file that's not mentioned in the PR).
So if a project has only people that depend on an IDE (instead of using an IDE for convenience), it's easy to end up with stuff that technically works, but copies 40MB of strings around multiple times, and thrashes your performance due to reading one character at a time without buffering.
Granted, this technically is not related to IDEs, but in my experience (emphasis on "my"), most of the people I've worked with that use an IDE, are of the "can't program without it" type, and not the "I use it because it's convenient" type.
Not all of them. But most. Even if there's a learning curve at play here, I'd say there's usually overlap between "use IDE because convenient" and "actually bothering to put an effort into learning".
I understand this is an inevitable consequence of lowering the barrier of entry and making programming more accessible, and it doesn't matter if we're talking about npm, IDEs, programming languages, or anything.
Pretty much this. Anybody new to the field will be using an IDE, it's extremely unlikely that someone new will be using vim/emacs. So IDE users will be a mix of newbies and experienced people, but since the field grew so much in recently, the number of newbies using IDEs will outnumber the experienced people using them. In contrast, people using vim/emacs will consist mostly of people with a lot of experience at this point.
So the average IDE user will be less experienced than a non-IDE user, but I don't think it has anything to do with the fact that they are using an IDE. I wouldn't attempt to pre-judge anyone's ability based on if they use an IDE or not.
Neither would I, but I will certainly judge them as lacking if they can't write a nontrivial program without using code completion or looking things up on SO/Github/etc.
Does this arbitrary bar extend to language and library documentation as well?
I certainly have way too much in my head to remember every nuance of several languages. As such, I lean heavily on multiple sources of external documentation to help me recall the specifics. That being said, this would in no way replace actual software development expertise, so I agree with your clarified stance.
I find using a good IDE with code completion and navigation is essential to efficient use of my time. I _also_ use vi constantly and perform most every other operation from the command line. I know I can get the same from properly setting up vi with the right plugins, but I find the ergonomics less appealing for my habits.
Sure, maybe there's some design principles to share that aren't obvious. But it's hard to share and teach those before someone has experience with at least putting stuff together. Also, it's not like there are principles that are universally accepted or universally applied by trained software engineers.
The way to bring a cargo cult developer into the light typically involves debunking or contextualizing a whole bunch of weird ideas.
Knowing how to apply design principles and rules despite not fully understanding them is a different level, in my mind.
Soon we may have no-code solutions getting good enough to warrant broader adoption. No-code solutions are as black box as you can get, and it's also as anti-learning as you can get in terms of the underlying technology and its theoretical principles. But this is also an example of more people than ever making things.
A tool which only allows perfect solutions by perfect users is one that rejects a lot of work and prevents a huge number of projects from ever happening at all. Useful for safety-critical work, but not everything is safety-critical.
As in be a terrorist and produce bombs? These are all ticking time bombs.
Relevant: https://xkcd.com/1988/
Lego's dream has come true.