Linting features and autocompletes are nice, also autocomplete features are nice to have.

The issue that I pointed mostly resonates with the idea that depending on LSP is the big issue.

I personally use Neovim with minimal stuff, I run lint and tests manually and not automatically, because it feels to me like push notifications taking my attention elsewhere, so I go to fix them later after what my intention is already expressed in code.

But agree and dyisagree that "Keeping the code organized is still good advice, but has nothing to do with using an IDE.". It should not be based on IDE, but an IDE on the hands of an inexperienced dev may lead to some comfort that should not be there.

I reviewed many code written by junior people, and very often I see people adding code in random places that later may let the application to be hard to follow and everything "seems fine" to them.

Other smell is like, but "it is so easy to rename a variables with my IDE" even though I believe that refactoring is nice to be done, but if we keep changing names so often, why don't we read the code that is being edited to understand well its intention and maybe realized that a big chunk of code should be split and the name choice will be completely distinct once proper refactor is made.

My point is not about avoid automation, is about having a dependency on that because the code is not manageable to people anymore, but manageable by automation mostly.

But is that because they're following their IDE, or is it because they're junior developers? I also see that sort of issue regularly, and as someone who is very happy with their LSP creature comforts, it's still something that I have to call out and teach.

I think you're reversing cause and effect a bit here, in the sense that you're trying to argue that IDEs cause developers to be less thorough and diligent, and to care less about good code organisation. In practice I suspect it's the other way around: the people who are more likely to be diligent and get their code organisation right are the same people who would take more care in choosing exactly which tools work best for them. That is to say, it's not that IDE users are worse at code organisation, it's that the people who are worse at code organisation tend to use IDEs.

The entire purpose of computers is to automate things and reduce complexity

https://boto3.amazonaws.com/v1/documentation/api/latest/inde...

It’s the same in every supported language since it is autogenerated from service definition files. I chose the Python version because it is all on one page. Would you rather memorize thousands of functions across hundreds of classes? Should AWS “reduce complexity” by getting rid of services and functionality?

Would you rather have an auto complete IDE or have to look up the web reference?

I’m sure it’s more complex to run S3 at scale than to build out the data center I did as part of my job to store 4TB worth of data in the early 2000s.

I would much rather run a 4 line CloudFormation template and do it in less than a second over it taking months to do it in house.

I started my programming in assembly in the 80s, should we go back to that too or should we keep using compilers and interpreters?

Should we keep programming in C or should we use manages runtimes with garbage collection?

There is no reason to purposefully make your life harder and not use the tools available.

The parent poster doesn’t use IDEs because it hides complexity. There is a such thing as necessarily complex.

About a decade ago I was working at a company that created a SaaS product for railroad car repair billing.

These are the main requirements not including a dozen addendums

https://public.railinc.com/sites/default/files/documents/CRB...

The parent commenter would say that we shouldn’t use an IDE to navigate through the massive code base to make sure records submitted from the railroad yards were in compliance. What alternative would you suggest?

Intellisense for Visual Studio has been out since the mid 90a

As someone who got their start in edit/Notepad, it wasn't "productivity boosts" that made me bad at code architecture when I was inexperienced.

It's inefficient the first time but you quickly build a working memory and a deeper mental model of the code, which becomes even more useful in the future.

Why don't you use automation to help your job when the whole point of your job is automation?

That sort of thinking will get your job automated out of existence.

Why spend your life doing something a computer could do for you?

The goal of programming is not to write code (however much I enjoy that part), it is to solve problems.

I don't think copilot et al is anywhere close yet though. They are occasionally useful when working with popular APIs you use very rarely, or when you need to write some very repetitive code. Other than that, I feel like it's mostly a monkey typing plausible but incorrect code on my screen everywhere I go.

Why spend your life doing _anything_ a computer could do for you? Why even live, if you're going in that philosophical direction?

I don't think copilot et al is anywhere close yet though.

Unfortunately, many of those in management already think it is.

The less people use their brains, the more easily they will be replaced, and the worse the product they'll produce. Unless you want to lose your job and let society drown in mediocre software (which you will no doubt need to use), do not hand over your agency to the machine.

The latter gives me dopamine. The former gives me carpal tunnel.

The typing is the rhyme scheme. The algorithm is the rhythm.

Right, which is exactly why autocomplete is not a huge help.

I've only found it truly useful in a codebase, language, or library I'm unfamiliar with or haven't touched in a long time.

It doesn't do much for me most of the time as I'm usually thinking or walking around the code, but the codebases I'm in usually are extremely easy to jump around in with fzf.

Properly naming functions/classes/modules goes a long way.

Back in the 2000s for me part of that job was to lead the buildout of a data center with a SAN that took up a whole room to hold 4TBs. Now I do that with 5 lines of yaml in a CloudFormation template.

My job was not “automated out of existence” by not having to provision a data center as part of it.

But I find there to be a world of difference between every keypress being processed as I touch the key versus slightly after it.

With enough experience on a given language you just of internalize a lot of the common linter rules.

I use ctrl-space to activate autocomplete when I need it, but I find when it pops up automatically to be maddening.

I’ve been using AI autocomplete more and more, though it’s a real mixed bag between seeming magical and guessing the completely wrong thing.

Yeah, I've used xterm for so long I found it a pain a few years ago when I had to use gnome-terminal, because keypresses have enough latency to be noticeable. I never expected that from a terminal.

The problem is VS Code then. Try IntelliJ, they spent ridiculous amounts of engineering to make typing as fast as Vim.

> I find when it pops up automatically to be maddening.

Me too, the first thing I do in my IDE is disable that. I love autocompletion, but I want it only when I need it. Now, that's completely different from just saying I don't need autocompletion at all.

> though it’s a real mixed bag between seeming magical and guessing the completely wrong thing.

Agree completely. Sometimes I am totally amazed at how it knew exactly what I wanted to write. But sometimes it misses the mark for sure. This tech is just going to get better though, so I like being able to use it while it improves and notice the difference with every new model.

I presume that does not apply on an old laptop with 8 GB of RAM.

Automation is not the point of programming. Think hard about this. It's the most important point. Code/build/hack to create more work for people to do, not less. It's thanatos. People need to unlearn "programming==automation" before it's too late. Everything we do as programmers should be done with "create more work" as a mantra.

I assume this is where 'automation' comes in, reduce dependence to the meatbags (us, humans)

Coincidentally, humans are generally really bad at the things that computers are good at and vice versa.

I think our job is to build systems where the computers are doing the computer work, which frees up the humans' brains and time to do the human work.

So not creating more work per se, maybe creating the opportunity to do better work?

The fastest definition is the one you never need to look up.

In the absence of "coding aids" like function lookup, people (are forced to) write code that is inherently better-organized and easier to conceptualize.

I spend comparably little time actually writing the code.

If there is an IDE available that works well out of the box, I'll certainly use whatever automation is available. But often it is broken, incomplete, slow, inaccurate, etc. and rather than spend countless hours fine-tuning some automation / LSP workflow that is going to break when I move to a different project anyway, I just deal with whatever features are missing.

This also has the advantage that I can quickly move to other tools, other languages, other computers, other companies, etc. without requiring days of setup and re-accommodation.

I do have a pretty good memory, which is probably a large part of why this is effective for me.

I think you are unduly harsh here. As a longtime emacs user and who switched to IDE recently (ones that come from JetBrains) my experience hasn't been what you mention. Yes there is a bit of time (not huge) to get adjusted to the shortcuts and efficiently navigate the code, but post that the IDE ecosystem is not as broken as you allude to.

But most of the large industrial codebases I've worked on at FAANG companies break IDEs one way or another - either because of the build process, or the size of the codebase, etc.

I want to be clear, I don't think my workflow is the best, most good, better than everyone else's. But it is mine, and it's the one I'm very proficient and productive with. Vim, tmux, and an assortment of command line tools isn't the right workflow for everybody, but I would argue I'm as, if not more, productive than most people I know using that latest fancy IDE tools.

> Why don't you use automation to help your job when the whole point of your job is automation?

Because I don't see that as automation, I see it as things getting in my way. My brain is set in its ways, and when I try to use tab completion or other nice editing things that people like I feel so slow, I feel like the computer is putting blockers in my way, because I know exactly the line I want to write, and popups and tab-complete break that flow for me.

All power to everyone who can handle that and prefer it, but it's not for me.

I am sorry to insist on this, but you're clearly mistaken: it's literally impossible for your grep workflow to be faster than hitting `Cmd+b` (IntelliJ MacOS shortcut to go to definition if you're on a symbol, or to see usages if you're on a definition).

> when I try to use tab completion

You don't use tab-completion even on the terminal?

> and popups and tab-complete break that flow for me.

It's very easy to turn off popups and make auto-complete only show up when you explicitly request it. In fact, that's the first thing I do on my IDEs. I highly recommend spending some time changing the IDE settings so that you're happy with how much "automatic" stuff it does. The amount of help an IDE gives is just immeasurable. I do sometimes have to write code without one and it feels like walking on glass. Even running a particular test, for example, is difficult, while in the IDE you just, again, hit a shortcut while your cursor is on the test. I know approximately how to do that from the terminal, but ffs that's useless knowledge to have when I just don't have to write code without an IDE at all, and using the terminal would take minutes (even if you're super fluent in it, as you're forced to come up with a regex for the particular test you want to run or just type the entire name, without assistance) rather than a fraction of a second, while distracting me from what I was even trying to do. This is one example, I could give hundreds more.

I would actually phrase that as “LSP optimizes for understanding” (which is of course important for writing code).

For example, when doing code reviews I routinely pull the branch down and look at the diff in context of the rest of the code: “this function changed, who calls it?”, “what other tests are in this file?”, etc. An IDE/LSP is a powerful tool for understanding what is happening in a codebase regardless of author.

If it's really "just a tool", why so defensive?

Sorry. I know I'm a dick. But come on man, don't pretend the effects of crutches doesn't exist. It's silly to try to deny something so obviously observable all day every day, in all possible contexts not just coding.

To each his own. I use the tools depending on the project. Meaning: most greenfield stuff (even at work) and my personal projects, I can handle with just Vim, a handful terminal tabs---where I grep, run linters (which send out OS notifications), and compile---and a web browser. The main dayjob codebase with all its 10+ years of legacy I wouldn't even dare look at without an IDE.

That said, I find the UX of IntelliSense + autocomplete to be extremely distracting (and don't get me started about Copilot). It's just a necessary evil because, distracted as I am with them, I am simply less productive in the dayjob codebase without it.

Hence, really, your Kung Fu is no better than mine, nor vice versa.