Ask HN: Programmers who don't use autocomplete/LSP, how do you do it?

Think of it as people who feel more frustrated than other by being interrupted in their thinking process. From my anecdotal evidence I think one can map different psychological spectrums like ADHD or autism to them liking or disliking such tools that "pop up".

> LLMs can instantly review changes and suggest ways to improve it, which would require either reading up on the topic or asking a fellow engineer on payroll to spend their time doing the same job.

If we train ourselves out of being able to do these tasks, won't we find it harder to recognise when the AI makes mistakes?

Ctrl+N in Vim, and API docs.

I work almost exclusively in Emacs without the modern LSP-based tools. I believe I do keep more in my head than programmers that use more advanced IDEs.

In code I have control over myself I avoid imports that doesn't enumerate all imported symbols. That is I always use the import Library (symbol) syntax in Haskell and never do wildcard import in Python.

When coding C I sometimes use tags so that I can go to definitions quickly, I should probably use it more than I do to be honest.

I do use hippie-expand for quick auto-completion but it is completely textual, it has no understanding of the programming language it currently works on which makes it much less powerful of course but it also has some benefits.

I always have the documentation very reachable, I use a search keyword in my browser to search on hoogle. I type H symbol/type-expression and I quickly find the documentation.

I do use Visual Studio on a Windows box for working on a C# codebase a couple of times per year and when I do I always turn off that code lens thing and I find that I rely on the code navigation features quite a bit. Part of it is probably due to it being a code base that is larger and that C#(/Java)-flavoured OOP makes the code more spread out. In terser languages like Haskell (which is much terser) it is natural for more functionality or types to live in the same file which means that you get much further with just simple textual search.

Some of us learned (and later shared it) at the times when you had to close an editor to access digital manuals. We went through different phases of “dev envs”, some of which were not that advanced (or later died), and we invented our own stable ways to overcome the issues. Some people chose complete off-road, some found a balanced approach. It all turned into various knowledge bases, muscle memory, tools, habits - that we shared. Inadvertently that created more people who do the same but might never have the issue in the first place.

When someone tries to repeat that from an IDE/LSP perspective, it obviously feels slow, akin to speaking a new language for the first time. Does one need this language? It’s hard to tell.

Problems show different contrast to people with different backgrounds. My personal position here is that if you shouldn’t solve non-problems. The set of problems you decide for yourself based on your experience.

I’m a balanced guy, btw. Sometimes I just sit and try to force upgrade my dev env. What sticks sticks. What doesn’t, goes to hell. I’m using ALE (nice multi-LSP tool) and all the tools I know since ancient times. Copilot writes what I call boilerplate, and I neither trust it nor have the need to write it. Passing my real-business functions to LLMs usually produces unfixable mess, so if someone knows another way for it to be useful, I’m all ears.