There are certain classes of autocomplete bugs that just can't happen when you're typing every #include/import/require that I find myself continually cleaning up and writing static analysis for.

I spend far more time reading other people's code than writing it. Autocomplete doesn't provide any assistance there.

I definitely had this experience with CodeWarrior back in the day. I really loved that IDE. But then when Mac OS X came out and Objective-C became the native language, the tools weren't there yet, and I had to either program "alone" without autocomplete/fancy dynamic highlighting/etc, or use Project Builder (the predecessor to Xcode), which was lacking in all these departments. I found myself much slower, and not for the obvious reason of "of course, I'm missing all these great tools", but as you say, slower at things I knew I used to be fast at. It's kind of like discovering that no, you don't like broccoli, you actually just like the melted cheese on top. That was a big moment for me deciding to focus on generally applicable skills vs. IDE-specific skills.

Interestingly enough, I think this legitimately doesn't apply to a lot of people because they spend most, if not all, their career in one domain. In that environment I think learning IDE-specific things makes a lot of sense. I discovered that this wasn't for me and move around a lot, so its nicer to not be dependent on those things.

Which popular languages these days don’t have a dedicated IDE, plug ins for popular IDE’s and/or support for the language server protocol?

sometimes its because a product gets discontinued, or your employer forces a different IDE, etc.

I wouldn’t work for a company that forced an IDE on me.

In that environment I think learning IDE-specific things makes a lot of sense.

Visual Studio Code works with multiple languages as does Visual Studio.

Most new languages until someone implements it. Again, this is very dependent on what you like to do. If you like trying bleeding edge stuff then you’ll probably run up against this.

> I wouldn’t work for a company that forced an IDE on me.

Sure, sometimes it’s kind of out of their control (or understandable). For example Xcode at Apple. Or if you work in a dev feature that needs to work with some tool or something. Again, my position is that it’s probably fine for most people.

> Visual Studio Code works with multiple languages as does Visual Studio.

OK, it’s interesting you bring up a fairly new entrant as proof this (at least I’m the Mac). Again, my interest is in trying lots of syntax extensions and stuff that usually just breaks these sorts of things. As I mentioned before, if you’re doing application development on a specific set of established languages for a very long time it’s probably the right move.

Now you’re giving me flashbacks. I worked for a company where the founder wrote his own VB like IDE/Compiler/VM for Windows CE. I hated every minute of that job until I got the chance to work on the actual compiler written in C++/MFC.

Two decades later, at any given time, I’ll be writing C#, Python, Javascript, yml for CloudFormation, a litany of third party external dependencies, internal libraries written by developers on multiple teams, etc.

Not to mention “polyglot persistence” dealing with Mysql, DynamoDB and ElasticSearch. All that and Zi purposefully avoid the front framework of the week.

The scope of what I am expected to know changes.

But on the other hand, for the good of the company, it’s often good to sub optimize the individual for the good of the team. You usually don’t want only one person knowing the entire feature and while you will lose out on individual productivity, you can get features out sooner if you have more people working on it.

On a personal level, I love having not to wait on other departments/props to get my work done especially in a dev environment.

I admire those who stick with their old tools and forgo modern ones so they can stay sharp. They tend to miss the forest for the trees though.

The point I was making that when I was writing C day in and day out and mostly just working with a combination of my own code and my companies vote libraries, it was easy to use just a text editor and the command line to build.

But things have gotten more complicated since then. No one could be expected to know the hundreds of functions that make up the entire AWS SDK or all of the options that you need to specify for a typical CloudFormation stack in yml. Of course now it’s even better with the Cloud Developer Kit that lets you generate yml programmatically using a static language - with autocomplete.

This sounds good to me. I'm not qualified to judge the quality of the linux kernel, but judging by the adoption, many features, and hardware support, they must do something right.

Perhaps, it is not so much giving up knowledge but filling the first-level cache with other stuff, like the larger picture of the software you are developing or the ever growing number of abstraction layers below the code you are writing. And whether that is good or bad thing is an interesting question. I am not aware, that it has an definite answer, yet.