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

[zackoverflow]

I am totally fascinated by programmers who don't use many of the IDE features I take for granted today: autocomplete, language servers, and recently copilot

So to the devs who don't use these tools, how do you do it? Do you just remember every type and field in a codebase? What does your flow look like?

One example is that I cannot live without the language server go-to-definition feature. What do you do if you need to look up the definition/implementation of some function which is in some other file?

[daltonpinto]

This question reminds me of the first time I met a blind programmer.

I asked him how he managed to code, and he replied with something that stayed with me: a good programmer should organize software in such a way that every piece of code has a clear and logical place. The organization should be so intuitive that anyone could build a mental model of the structure and navigate it easily, even without seeing it.

It felt like something out of a Yoda or Mr. Miyagi lesson. Skeptical, I asked his colleagues if he was truly able to code or if he was just exaggerating. To my surprise, they told me not only was he capable, but he was the best programmer they had ever worked with. They said no one else came close to writing code as organized as his.

That conversation changed my perspective. Ever since, whenever I’m unsure where to place new code, I don’t think about DDD or any specific methodology. Instead, I try to follow the logic and structure of the project in a way that feels natural and easy to follow later.

Later in life, I met two other blind programmers and heard similar stories about their ability to produce well-organized code.

To bring this back to the original question: I view LSP/IDE features the same way those programmers view "visual aids." Code should be organized according to a clear and logical structure that makes it easy to navigate.

Relying on features like Ctrl+Click to find where things are located worries me. Why? Because it can mask structural flaws in the codebase. If we can't intuitively figure out where something belongs, that’s a sign the codebase lacks structure—and that should motivate us to refactor it.

Not only do I avoid using LSP features, but I’m also opposed to their use. While they can help with navigation, they may prevent developers from experiencing and addressing the underlying structural issues in their code.

[brabel]

> Not only do I avoid using LSP features, but I’m also opposed to their use. While they can help with navigation, they may prevent developers from experiencing and addressing the underlying structural issues in their code.

LSP by itself will not prevent anything. LSP (using the terminology from OP, but any IDE really) is just a tool like any other which allows you to do things faster. It doesn't matter how organized your code base is, it will never be as fast to find some definition as hitting a keyboard shortcut (please don't use Ctrl+Click, my gosh... learn the keyboard shortcut for things you do often like this). I want to see docs for a function without moving my eyes from the code I am currently writing. I want to be able to jump back and forth between definitions without interrupting my chain of thought, see function definitions inline instead of having to jump to the file it's defined on.

When you have to manually search for files and then Ctrl+F to find functions, lookup docs in a web browser (which I hear is how people who don't use IDEs still do that), or manually run a linter/compiler to see warnings in your code, you're just being really inefficient. I can't understand that at all. Why don't you use automation to help your job when the whole point of your job is automation?

Keeping the code organized is still good advice, but has nothing to do with using an IDE.

[kapitar]

This is one of the features I like most about F#, after some years experience with it. The project is structured with a specific file ordering, and there's no forward referencing. Similar within a file/module as well, most of the time.

So to understand a project, you start at the top and work your way down, you wont encounter anything you haven't come across yet as you go.

Ironically, this 'feature' so annoyed me when I first came across the language in 2015 or so, that I put it down after five minutes and forgot about it for years.

[ozim]

You are lucky to have small code base or one that you write mostly?

With 6 other devs on the team and 5 apps our team supports there is no way I get code well organized especially when as a senior I have devops stuff to deal with meetings, explaining features to business, checking up support tickets and random stuff happening all the time.

I don’t know the code base and there is no way to keep up.

While I have to dive in and fix shit ASAP or when I get to code review I have to fix some less experienced guy code. Or write part of code when proposing architecture solution, because just telling people “I am right do it my way” does not work until I write piece of code and then they understand.

Language server and ctrl-click is my bread and butter because that is the fastest way while also going slow enough to understand context.

[jasonpeacock]

You should try turning off those features yourself for at least a month and see what happens ;) You’ll learn the answers yourself, much better than us trying to explain them.

You’ll learn where all the reference docs live for your language, libraries, and frameworks, and along the way you’ll learn more by actually reading the docs.

You’ll learn the value of good project organization and file naming, and explicit import statements.

And you’ll learn that the speed of typing, even long method names, is not the limiting factor of your productivity.

[maccard]

I agree on turning it off to find out. I disagree with almost all of your takes though. If you work without it, I would similarly suggest turning it in for a month.

> You’ll learn where all the reference docs live for your language, libraries, and frameworks, and along the way you’ll learn more by actually reading the docs.

I know where they are. I use them every day. But reaching for them to check every argument if every function I use is a waste of time. It als only works for stuff that has a full suite of documentation. If you’re using an internal library you’re very likely searching the code anyway.

> good project organisation, file naming and explicit import statements.

Good file naming is a crutch for a lack of tooling to explore and modify at a project level. Good project organisation doesn’t require you to disable tooling with semantic knowledge of your project. And explicit imports are a (necessary) distraction m.

> And you’ll learn that the speed of typing, even long method names, is not the limiting factor of your productivity.

It has nothing to do with the speed of typing and it never has. It has everything to do with working at the abstraction level I want to work at - my codebase. It’s using the tooling that means I think about “I have an X and I need it to do Y. “ rather than “let’s go context switch to the browser to figure out if it’s len, count, size, chars”

A good corollary is a linter - it’s incredibly important to the project, knowing and understanding the rules and why they exist is very helpful and would benefit everyone on the team. But a computer can do it for us, and let us focus on writing the code rather than ensuring we have tabs instead of spaces.

[IshKebab]

I don't need to turn it off to find out - I've worked in enough untyped languages (Python, Ruby) or badly set up ones (C++) where code intelligence tools don't work to know what it's like, and none of your points are true.

1. I know where the reference docs live already. Auto-complete doesn't obviate that need.

2. Again auto-complete doesn't completely obviate the need to navigate by file name/path (though it does reduce it), so I already know that is valuable.

3. The speed of typing sometimes is a limitation. I'm not a slow typer but sometimes there are situations where you just have to type out something tedious, and you're not doing anything other than typing. Yes even with fancy Vim/multiple cursor editing. Auto-complete speeds that up a little, but Copilot sometimes speeds it up a lot. You should try it.

For example for printf debugging, with copilot you can pretty much just type `dbg!` and hit tab. Much faster.

You also missed some significant advantages:

1. go-to-definition makes navigation much faster

2. type inlays make understanding the code much faster

3. auto-complete makes looking up method names much faster (is it .starts_with or .has_prefix? .contains, .has, .any, or .some?)

The only upside of not using LSP tooling is that sometimes it can bring your computer to it's knees, whereas plain text editing will always be fast. Easily worth it though.

[csomar]

I use Rust, so explicit imports are required. However, I fail to understand this point

> You’ll learn where all the reference docs live for your language, libraries, and frameworks, and along the way you’ll learn more by actually reading the docs.

With neovim/LSP, I have a key binding (Kg) that opens a small window within the editor with the rustdocs. Not only this is faster than going to the browser, typing the type name, opening the docs, looking up the method but also it ensures that I am looking at the docs of the correct version that my code base is using.

I don't really understand the aversion to using these tools. They are "auto-complete" and not generative complete. This means you need to know what you are going to type for them to help you.

[modernerd]

I work with two types of LSP/LLM-averse programmers:

1. The HLSP user

This group does use an LSP, it turns out, only via you as the conduit: you are their Human Language Server Protocol. They'll ask, ‘can we pair today?’. From that point, navigating code, looking up method names and signatures, and flagging syntax errors before runtime or compile time is your job. How they find their way around when you're not there is unclear, but it's likely slower.

2. I am one with the machine

This crowd has been wrangling code long before IDEs, LSPs and LLMs. They've amassed a terrifying arsenal of tools to find files and references, bulk-rename, pull up docs, and twiddle bits in ways that looks fluent and natural enough when _they_ do it but would take months or years for you to learn if you didn't give up and go back to your IDE. When you ask them _how_ they just did something, they either pull up a short page of Elisp and say, "it's really quite simple we just reverse the node tree and iterate over the folded quarkenspace", or — if they're a vim user — say something like, "oh, that's just the hiboscus plugin, but piped through smark".

So the response to "how do you do it?" seems to be broadly summed up as, "the way we've always done it".

Group 2 isn't necessarily _better_ than LSP/autocomplete/heavy LLM users (people who are very proficient with more modern tools can look like magicians too). The LLM-free crowd were just forced early to become proficient, they've gotten very good with their home-rolled methods, and — in many cases — they probably wouldn't benefit that much from LSPs, or they use them but with features that bug them switched off.

Group 1 would probably better be served by an LSP but either don't believe in the benefits or is just comfortable with their current setup and feels no pressure to change.

[hereonout2]

I might be in group 2, rely heavily on command line tools and vim to do what vscode and a load of plugins provides younger programmers.

My answer to the fairly common question of "how do you do it" is always the same though.

I always relay that it's taken an evolving 20 year career to learn all that voodoo, I never imply it's simple to gain that knowledge nor do I encourage others to change their working patterns to match mine. I do like showing off a few tricks though!

One thing I do always mention though is the longevity of vim + the command line. I went through a period of swapping IDEs like most junior devs, now I have a setup that I feel can last me till retirement and I can just continually invest in learning to use the same tools better

[dsego]

> This group does use an LSP, it turns out, only via you as the conduit

Oh man, it makes my blood boil when someone asks in which file the function lives, and I know they have a "go to symbol" in their editor of choice, but somehow they never want to learn some features of their tools. I did notice that how you use your tools changes how the project is structured. Neatly organized files and directories are a must if you are not comfortable with quickly jumping to a symbol.

[atomicnumber3]

It's weird to me that you group LLMs in with code analysis based LSP autocompleters.

Normal autocomplete is basically a context-aware AST browser. It lets you navigate the program semantically instead of file-based.

LLMs are token predictors.

[thwarted]

The shell is my development environment. I open up new terminals and shells willy nilly. I find cli tools like find/fd/grep/rg are useful because I rarely need to find only the definition of a function, but rather other call sites too, to find out how it is being used. I think being surrounded by the code and being able to slice and dice it leads to a certain kind of familiarity that a tool that takes you right there doesn't afford. I like fast compilers, and type checking, so it doesn't matter if I can remember the types and fields. I'm not bothered by error messages or warnings, I fix them and I have a greater understanding of the code I'm writing. My editor is a pretty stock vim setup with format-on-save and syntax highlighting, but I can operate without those (in fact, I'm often hindered by some other defaults, like bad color choice (dark blue on my black terminal) that makes things hard to read. I dont have much vim customization because I can not rely on it always being there. I use a pretty basic setup that lets me be productive in just about any default unix/Linux environment. I find IDEs to have a lot of visual distractions. When I was first exposed to unix in the early 90s, programming using it just clicked for me and I've never really felt hindered by the defaults. I read man pages and the languages' stdlib docs (usually web pages) so I'm a little more than passingly familiar with what's in them and their capabilities and how to navigate them.

[8organicbits]

This is my mindset as well. I often need to work with text that isn't code. Maybe it's a SQL dump someone sent me, some bespoke configuration format, a collection of log files, etc. Knowing how to manipulate and navigate text is extremely helpful as a general skill. IDEs degrade to notepad.exe quality when presented with unknown formats.

Personally, my recent work has been: short term freelance work, new code bases, a variety of programming languages including ones I haven't previously used, problem identification and solving, and mature code bases where you'd only write a couple lines of code a day.

In that context an IDE optimizes a tiny part of the work, while getting in the way for everything else.

I'll add that when I worked on a greenfield Java project as part of a large team, I absolutely used an IDE (IntelliJ at the time) and couldn't imagine working differently.

[tmountain]

I did it this way for about 20 years and recently moved to VSCode with its integrated terminal. It makes me feel pretty lazy and like I’m “cheating”, but there are some productivity benefits (LSP), and I’m less of a purist than I used to be. I maintained a blog about vim for 3-4 years, so I was pretty committed to that workflow back in the day.

[ximm]

I have an alias for `vim -p $(git grep -li "$1") +"/$1"` that allows me to quickly open files that contain a given string.

[RodgerTheGreat]

Most of these tools are distractions. I don't want suggestions or needling warnings sliding around on my screen while I compose and examine programs; I want a quiet space to write and think. Focus is essential.

I organize notes and action items in a paper notebook in front of me or a text file in another editor pane. I read the code. I search and diff with standard POSIX utilities that are available in every environment. In the languages which support it, I try ideas and answer my own questions in a REPL.

Practice leaning on tooling all day and living without it will feel unthinkable. Practice doing without, and you'll find you need very little.

[burnte]

Agreed. I don't need my code to turn red just because I haven't finished writing the entire line. I'm aware this isn't valid code, I'm not done.

[barrell]

I liken this to asking people who don’t use a GPS how they drive and if they have every intersection memorized. It’s not about absolute knowledge of a codebase, but intimate familiarity.

I also don’t think it’s a coincidence most people in the comments seem to be using some flavor of vim. I think using an editor designed before these tools were available will make it much easier than afterwards.

I’m not sure I’m the best case, but I just turned off copilot, haven’t bothered to configure my autocomplete yet in my latest neovim config, and only use an LSP so my macros can be highlighted differently. I write primarily in Clojure though, so inline docs and go to definition are just a part of life.

I don’t really have anything against LSPs, but neovim, telescope, and the repl have always gotten me where I want to go

With regards to my flow, I’ll normally have 1 vim session for every 1 project, each with 1-5 tabs open, each tab with up to 12 splits. There isn’t really structure to the tabs or splits, I’m just liberal with opening splits and conservative with closing them. To me it can be really helpful to have all the recent code I’ve been working on open at one time, and if it’s not, I just pop a new tab and start fresh

[tasuki]

> I liken this to asking people who don’t use a GPS how they drive and if they have every intersection memorized.

I find people who drive with sat nav often don't learn almost anything about their route (they don't have to! is the whole point!)

I at least orient my navigation north side up so I have a basic clue what I'm doing.

A friend of mine looks at navigation before driving, then turns it off.

[jedberg]

This post just gave me an epiphany. I work with some programmers in their 20s. They are some of the best programmers I've ever met. But they never seem to enter "flow state". In fact, they welcome distractions. And now I think I know why.

When I was coming up, you needed to enter flow state to be a good programmer. Because you had to keep track of all the functions and their signatures, all the different flows and objects, all the different files. And if you got interrupted, you had to reread the code to "load" all that back into your working memory.

But now the tools do that for them. They can click on a function and see the definition. The copilot and autocomplete will keep track of all the minutiae for them. So they don't need flow state to be productive.

This revelation may get me to actually switch from vim to something with all these modern features. Maybe it's finally time for me to try VSCode.

Especially since my kids never let me hit flow state anymore even if I wanted to!

[cmgriffing]

This is something I have been noodling with a bit. I'm 40 (started in my late 20's). I welcome the distractions as well.

When I was learning, I would always have a movie or TV show on in the background.

On stream, I am constantly responding to chat. But I am able to delay that by up to a minute most times. So I get most of my work done in short bursts.

BUT, while distracted by a TV show or a chatter on stream, my brain is probably not completely distracted. It becomes a moment for diffuse thought to kick in rather than relying purely on focused thought. (For anyone reading and unaware, diffuse thinking is what causes "shower thoughts")

So, those distractions are just a way of forcing myself to toggle between thinking states.

Diffuse thought is also the reason why I never end on a resolution for the day. I always try to have something that I can stew on overnight while going to sleep, waking up, showering, doing the dishes, etc. I have solved several bugs on my morning commute back when I used to go into the office.

Something somewhat related. People who do non-traditional sleep patterns like biphasic, or even something as extreme as uberman, are able to get to sleep faster than most people with traditional sleep patterns. It is something that you can actually train and practice. Forcing diffuse thought more often maybe helps it kick in quicker too?

[IgorPartola]

So one of my current projects has a part that is five coordinated microservices. Two of them need to use concurrency that modern tooling doesn’t love out of the box. The entire system has to have strict timing and low latency. Autocomplete can help with some pieces but this isn’t actually that much code. What it requires is being able to visualize the whole thing, be able to test exactly how the underlying libraries respond to different kinds of errors, and how to prevent deadlocks. I have yet to meet an LLM capable of reasoning about deadlocks, catching signals within threads of a process, correct semantics of anonymous pipes and their buffers, etc. In order to work on something like this it does require flow state. You can’t just casually add a few lines or rework some module. You need to visualize the entire system, including error flows, before you can start changing it.

I could likely use some basic autocomplete for things like a function signature, but most times I have the function implementation on one side of my screen and where it’s being used on the other and chances are I’m changing both at the same time. Vim is wonderful for this kind of work.

[vq]

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 <Space> symbol/type-expression <Enter> 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.

[reidrac]

That was me for 7 years (using vim instead of Emacs), and it was working fine with Python and Go. I used ctags for navigation, some shortcuts for pydoc, and that was essentially it.

Then I started working with Scala and, until metals (the language server for Scala) and LSP support was good enough (first vim, now I'm a happy nvim user), it was awful.

So I'm certain it depends on the language. My take before Scala clicked for me was that I didn't want to use a language that required an IDE (or IDE-alike features) to be productive. And I think that opinion was mostly because my bad experience with Java.

I still write C without LSP, and I'm fine.

[098799]

Despite many years of development, I find lsp and eglot to me mostly unusably slow. I need my emacs to be fast and the only way to achieve that is something oldschool like Jedi/Elpy for python.

[gotts]

> I work almost exclusively in Emacs without the modern LSP-based tools

I'm wondering how many people in the comments would misinterpret it as "Emacs is outdated"/"Emacs does not have modern LSP-based tools"

[userbinator]

The sibling comment about a blind programmer is very worth reading, because it is relevant to what I've observed about other (non-blind) programmers who are highly skilled: they do not need tools to tell them what to do, because they have completely internalised the structure of the program and can think about it as a whole. Incidentally, one of the things I often do when solving a problem --- be it finding a bug or fixing it, or implementing a new solution --- is to close my eyes and think deeply about it, without distraction.

I don't use IDEs either. A plaintext editor and a console window (for compiling, testing, and the occasional grepping) is enough. IMHO someone who is reliant on IDEs and autocomplete is in the same category as not knowing how to type without looking at the keys on the keyboard --- yes, you can get by, but you will never be able to code as fluently and effortlessly as those who can think deeply about the code entirely in their brain, and you'll be frequently writing code that looks reasonable when viewed in isolation but obviously redundant and/or inefficient if considered as part of the bigger whole.

[tasuki]

This works for small projects.

I've worked on projects where "hold the entire project in your head" might be somewhere between very hard and impossible. Work the right abstractions, it should be possible to hold the relevant parts in your brain. Still, when you're new to a large project, an ide goes a long way.

[perrygeo]

As someone who started programming on Solaris UNIX, then Linux workstations, in the late 90s, there just wasn't an option. You used vi or emacs or you didn't work.

I'm not saying it was the good old days but it was not a significant barrier to doing what we wanted to do. Code is code and ultimately you need to have a clear mental picture of the codebase, regardless of your tools. LSP isn't valuable because it allows novel functionality (there are dozens of different techniques for discovery within a codebase). LSP is valuable because you have an efficient way to "query" your codebase for contextual information directly in the editor window.

But you can build that knowledge through other means, you just need another terminal window and external tools.

The understanding of the codebase is what maters. LSP is a means to that end, making an already common task slightly more efficient.

> look up the definition/implementation of some function

Text is effective. git grep "def foo"

Autocomplete engines work on text too, based on the contexts of the buffer or files in the directory.

Static analyzers have always worked wonders in identifying LSP-like warnings.

Compilers and debuggers give you access to state and type information.

This stuff has been around for decades. LSP just makes it more convenient and packages it into one UI.

For what it's worth, I'm 100% in on LSPs for my work these days. But if LSPs disappeared tomorrow, I could revert to the old ways with only a small hit to productivity.

[bigpingo]

I hate annoying distractions, be it popups, beeps, notifications, alerts, auto brace/quotes/etc and autocomplete prompts. I turn all of that off in every program because I want to be in total control of the computer.

When it comes to autocomplete specifically I initially turned it off because I was mainly a C++ programmer and C++ autocomplete has just never been good enough and a half-working autocomplete is just worse than nothing at all because you end up stalling and waiting for the prompt. But eventually I just grew to hate it for all languages because it interrupts flow and "pipelining".

[vaylian]

> I hate annoying distractions, be it popups, beeps, notifications, alerts, auto brace/quotes/etc and autocomplete prompts.

This was also my first reaction when I saw someone else using an IDE. My way of writing code is to get my ideas written into the editor first. Only after I have written the code, I run the compiler to see where things don't fit. The people who were using the IDEs were really astonished that I could understand the output from the compiler on the command line.

Programming is a lot more fun when you sketch out your ideas first before you make sure that all the details are correct.

[hliyan]

When you have a good mental model of the code base you're working on (and the libraries you use), you don't really need a lot of IDE features, and IDE features can sometimes hamper the formation of such a model. Let me explain:

Twenty years ago, my IDE was two terminal windows running VI, vertically tiled. On the left, I open header files, and on the right, source files (I was a C++ programmer). When I wanted to look up method signatures or member names, I would quickly look it up from the relevant header file. This could take anywhere between 5-60 seconds.

If you remind me that IDE features could improve this by a factor of 10x, you're absolutely right. But if we apply Amdhal's law to developers, their biggest time waste is often not the physical act of coding, but fixing logical and structural issues in their programs. And the best way to prevent such high level issues is for the programmer to have a good mental model of the code base.

So, the possession of a good mental model of your code base obviates the necessity (but not the convenience) of IDE features such as autocomplete/intellisense. But at the same time, reliance on such features hampers the formation of a good mental model.

My current compromise is to rely more on the "Go to definition" function than auto-complete.

[bazmattaz]

I’m not a developer but someone who is curious about development, can you explain what it means to have a good “mental model of the code”. Does that mean where you understand all code and what it does?

[SoftTalker]

I turn off autocomplete everywhere I can. Whether web searches, composing code, or anything else, I do not want the computer anticipating what I am about to type. I find it is often wrong, and always distracting.

Yes, I try to learn the language well enough that I know the parameters of common functions. If I don't, I consult the docs. If I need to find the definition of a function in another file, I use grep.

[cjohnson318]

There's nothing more annoying than putting my cursor on text, and then having a pop-up block that text.

[ethagnawl]

> I turn off autocomplete everywhere I can

I'm the same way. I have never, ever been pleasantly surprised by auto completion when I did not explicitly enable it -- can't think of on instance of me doing this, either. In particular, web-based code playgrounds, IDEs, etc. auto-inserting quotes and parentheses drive me mad. Google Docs also frustrates me with their word/phrase suggestion widget that I can't seem to ever fully turn off.

[scop]

I have jumped around over my career: Sublime -> Vim -> Emacs -> VSCode -> Neovim -> Cursor, which is now my daily driver.

However, I still relish in the ability to open up a nerfed Sublime or basic Vim install where it’s just me and the text. I do so when I want particular lucidity in my thought process and code composition.

Then I can always fire up heavier tools for code review after the fact. How do I “do” it? I got really good at grep’n my way through a code base. It’s amazing what grep/ack/rg/etc can tell you when you know what to ask. And if you don’t know what to ask, well finding that answer is going to teach you a lot more than just hitting Tab on autocomplete or GoToDef.

[tomrod]

I've found cursor tends to muck up system internals and such when I use shells in it. There is a lot going on under that hood -- would prefer it work as a VS Code extension so it has some guardrails.

[wruza]

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.

[gregjor]

I use vim with ctags. vim has good autocomplete but I don't use it much -- I rely on memory and looking things up in the docs. With ctags I can jump to definition/implementation of a function.

ctags has worked since the early 1990s.

Check out this video: How to do 90% of what plugins do with just vim.

https://youtu.be/XA2WjJbmmoM

[imron]

Same. ctags all the way!

[throwaway81523]

I use Emacs and sometimes I open a window to bring up a man page or code definition for some function, but I've never felt the need for a fancy IDE. You just get used to what is going on in the code. Like if you are a fiction writer and you're asked to write a new Star Trek episode, after watching a few existing episodes you would get familiar enough with the characters and milieu to not need to refer to the series bible too much. An IDE that pops up suggestions like "Live long and prosper" or "we have 93.2357% chance of blowing up the ship, Captain" when you type the name "Spock" sounds counterproductive. Maybe I'm missing something though.

Added: it helps a lot to have real documentation, something that has gone out of fashion in recent years. Maybe these IDE's are being used as a substitute. I hadn't thought of it that way before. Hmm.

Added 2: Also, Emacs has always had TAGS (this quick navigates the editor to a function's definition given its name) and I do use that sometimes.

[crabbone]

For years now Emacs had integration with LSP. The experience isn't quite the same as VSCode (I think, there are some proprietary extensions to LSP protocol, or some such, but don't quote me on this). But it's good enough to work in most cases (this is how I write in Ada and Rust, for instance). So, if you use Emacs: https://github.com/joaotavora/eglot I believe this is the most popular implementation.

[trevor-e]

This thread is certainly eye opening. It reminds me of a post I saw somewhere, maybe on Reddit, where someone was describing their experience working as an intern at an old-school tech shop. All of the developers there were hardcore Vim/Emacs users with 20+ years of experience.

The intern was tasked with a large-scale refactoring of some modules which the senior devs estimated would take months of work to complete. After shadowing a senior dev to get an idea of the work involved, they realized the dev was literally string replacing a lot of the code, hence why the estimate was ridiculously long. The intern instead loaded the project into IntelliJ and used the built-in refactoring tools to get the task done in a couple days. This caused a bit of an internal shit-storm with the product owners because the intern made the devs "look bad".

[jherico]

The intern didn't make them "look bad". They were bad. I mean, I'm sure that they were great developers in some sense, but refusing to ever update your toolkit because you've always gotten along just fine with what you already use is a great way to get sped past by the next generation who start from a better baseline.

[uludag]

Work at a "tech shop," even old-school ones, most likely involves extremely varied types of work, much more than name-refactoring, for which something like IntelliJ indeed would be the best tool. Just because one use-case of one tool being better than another use-case of another, doesn't imply that users of the former are stubborn/unintelligent/worse than the others. Maybe there's a use case where the Vim user is at an advantage.

The fact that the market hasn't outright eliminated such people goes to show that things like LSPs aren't that extreme of an advantage.

[jez]

> What do you do if you need to look up the definition/implementation of some function which is in some other file?

Code search (ripgrep, GitHub search, Sourcegraph, git grep, or even just plain grep). You can use VS Code search but I prefer CLI tools so I can filter the output of my search with more searches—VS Code makes it hard to post-process/filter project-wide search results.

Filename search (fzf, fd, or just find).

There are cases where LSP-powered Go to Def is faster, but there are also cases where it’s less accurate. I’m talking:

- Untyped code in a graduate typed language

- References of a method name in a YAML file pulled out with reflection

- References of that method in a comment of some other method, where that method is actually the method I’m looking for.

- A one-to-one mapping of method names with some enum somewhere else, but lowercase in one spot, and all caps in the other spot.

So yes, sometimes go to def will be faster, but you’ll lose out on so many other possible references.

Another case: repos where the codebase is so large that the editor tooling is slow. Repos where I’m brand new to it, because I just need to check why some code in a third-party library is going haywire.

Grep (code search) is just so powerful.

I have a post about how to do large-scale code migrations/codemods. Everyone assumes the post is going to be about how to use high-powered, language-aware AST-based static analysis tooling. But half the post is talking about the unreasonable effectiveness of regular expressions.

[patchymcnoodles]

For me it is actually a disturbance, especially autocomplete. So yes, I need to remember stuff, but if I cannot or just don't know the codebase, I look it up very quickly and then can learn more from looking at the specific code.

At the start of learning rust I used a bit more help from the IDE, but now not anymore.

For me it is just easier to have a much deeper knowledge instead of "only" have knowledge about the tools. A good example was when I used SVN back in the days, I only used a GUI and always struggled if something does not work out. I had basically no idea, what is really going on. So when Git became the new normal I forced myself to use the command line only and because of that I can always help myself (with Git atleast :D).

Certainly not something for everyone, but it works for me :).

[freehorse]

I do not really belong to that group, but when I am learning a new language I avoid using LSPs and anything more than a generic autocomplete because I find that too distracting while I try to learn the language. Moreover I realised that it actually slows down my learning; I may type stuff faster but I learn and gain understanding slower compared to eg typing everything and searching the docs. In stuff I am already proficient with, it makes more sense to me as such tools help me code faster, including finding and fixing bugs faster.

As for copilot, I find it impractically distracting and I do not understand how people are supposed to code with it tbh. While coding I spend most time thinking about the code than just typing, and having random autocomplete suggestions popping up with lag while typing disturbs my chain of thoughts. Maybe if I was writing more boilerplate I would have liked it more, or I am using it wrong somehow, or maybe one gets used to it after some time. I sometimes use copilot chat though.

[d3VwsX]

My personal observation, even if this is similar to what others already said: I found that in some (two? three?) big Java-based projects I worked on, where almost everyone used a IDE, the codebase became almost impossible to navigate or modify without using one, so I did. It was so easy to just add a method or class wherever, and it did not matter because you could just ctrl-click a name to find its implementation. It did not matter if you put 100+ methods in the same class or if you named things willy-nilly or overloaded method names.

If I was back working on a project like that, I would use whatever IDE everyone else was using. It makes no sense to fight it. But I prefer projects to not be designed for/by IDE, since that tends to make everything more readable and easy to navigate. I prefer to be able to navigate around the source-code on the command-line or use whatever generic tools to browse, and not be forced to ctrl-click my way around, and if (almost) everyone else working on the code wants that as well it is less likely that someone ruins it.

That said, I have at times also set up Emacs to use LSP or other built-in code-navigation tools, or templates (yasnippets) for generating boilerplate, for some projects. I rarely end up using it much. Usually I just jump around using built-in tools like M-x vc-git-grep or M-x rgrep. The code has to be pretty heavily designed-for-IDE to make those simple tools slow to use.

[javcasas]

Ah, yes, autocomplete: the propagator of typos. Write it wrong once, have it copied wrong everywhere.

Go-to-definition: the band-aid for overengineering. Write 37 levels of indirection, don't pay the price.

AI programming: now you don't even have to pretend you understand the code! Bonus point: sometimes it generates from StackOverflow, but from the question, not the answer.

These are good tools, but it's easy to figure out who uses them to help themselves, and who couldn't write code at all if it wasn't for these tools.

[javcasas]

Related to workflows: vim, tmux, grep -r for finding stuff in somewhat sane codebases, watch to have unit tests running, minor scripts for everything else.

[HarHarVeryFunny]

I'm an old school programmer - built my first 8-bit home computer in 1978, and been programming ever since (currently Linux/C++ telecom - heavy multi-threading).

There are tools like ctags that have been around forever and build an index of definitions to let you jump to them, but personally I've never found a use for it, anymore than I ever found a utility for IDEs. I just have multiple terminal windows (or tabs) open along with my editor (emacs).

When I'm deep into a project - even a very large one, I basically just remember where everything is (as well as the code itself), or when needed just use terminal find/grep. For stuff I've written from scratch myself (vs at work working on a large legacy codebase), code organization is certainly part of it - organizing code into file-based modules. I use record/playback editor macros a lot to avoid typing, and occasionally use sed (scriptable Linux command line editor) to perform entire codebase renames etc.

I've tried modern IDEs like VS Code, but really don't find them to be a productivity benefit. I get the appeal of a single tool/environment that does it all (like old-school hard-core emacs folks who treat it as an IDE), but in terms of productivity you can work just as fast with a collection of tools rather than a single one.

[herbst]

I feel heavily annoyed from most IDE features. I love to code in a chill relaxed way where I just write the code that I want.

I actually remember all the relevant fields and I am currently working on, or just reread the relevant code when necessary.

I wonder if syntax and cute grammar has any relevance in a world where people basically let the IDE to the coding.

I honestly wouldn't call me a good coder if I wasn't confident I could produce the same code quality on a computer with just nano or vim and no internet.

[ryan-c]

I use vim, and program mostly in Python, Rust, TypeScript, JavaScript, C, and Bash. There are about a dozen other languages I use on occasion.

My vim configuration is moderately customized, and I regularly write code on systems I SSH into since my personal laptop is a Pixelbook.

The main things I rely on are syntax checking plugins.

I use ripgrep to find stuff in codebases, and when I'm working seriously I use an ultrawide monitor with plenty of screen space to have documentation I can glance at open.

I have a significant collection of small libraries I've written for common tasks, and often refer back to my own code across projects to figure out how to do things. Metaprogramming is something I do often too.

As another person said, thinking is my main constraint when working, not actually writing the code.

It should also be noted that I'm not primarily a "Software Engineer". I'm a Principal Security Engineer at a big tech company. If I'm working on actual code, it's generally "interesting", either a hard problem at work, or a personal side project. There tends not to be much boilerplate.

For TypeScript/JavaScript in particular, something like copilot would get in my way, as my style for this languages is extremely non-standard.

I'm not sure how much any of my coding habits have to do with it, but I regularly tear into unfamiliar codebases to fix bugs and add features, and I'm pretty good at orienting myself quickly, even in languages I haven't used before.

The first thing I did with Rust was add features to a data compression library without any prior exposure to the language...

[kunos]

Here's my experience so far. 1) The best analogy for LSP is GPS navigator in your car. It's invaluable when you have to navigate to unknown places to do stuff but, it also slows down your ability to learn the roads of your closer neighbourhoods. I am often surprised how confused I am if my GPS sends me down a road that is closed for whatever reason and I have no idea how to figure out an alternative route even if I am driving around my place, it shows me how much I rely on the navigator to get me anywhere now.

So what using an LSP is doing for you heavily depends on the kind of code you write. Are you the kind of dev who works in pretty much a very familiar codebase for a very very long time? Then LSP could even be impeding acquiring a better mental image of your code. Conversely, if you are a coder who often ventures into different and unknown parts then LSP might make you way more productive.

2) Depending on the language, LSP can become an actual part of the language itself. When I code in languages with good LSP (C#, Rust but also C++) I often code with the LSP as my "target".. I think what I'd like to see popping up when I type a "." . In this part of the code I want to see this var and this method.. in that part of the code I want to see also this other vars and methods it gives a very good idea of what the "surface area" of a piece of code looks like.

LSP are also very good instant feedback if something you are typing is wrong. I press "." and nothing shows up? I have some error somewhere and/or the thing I am dotting is not what I think it is.

But, in order for this to work the LSP has to be REALLY good to the point that has to be close to zero doubt that if the LSP is not behaving it means it's your fault. Sadly, not many LSP ever reach this level of reliability.

This is one of the thing that made languages such as C# and Java so popular: the ability to "dot" your way through unfamiliar libraries with great ease without having to dive into documentation to discover there's a function X in some file Y that already does exactly what you are trying to do.

[entropyneur]

I've recently experienced a sharp decline in my ability to remember anything code-related. At one point I looked at the code I wrote the day before and it felt as if I don't even know the language it's written in. I was attributing it to the age, but this thread made me realize it coincided precicely with the switch to using IDEs after 15 years of getting by with a text editor.

[OliveronData]

I visit HN every so often but never felt the need to comment, until just a few minutes ago.

Yes, what you've described, I also went through something similar.

I've been programming little over two decades now. Been an autocomplete (ctags, intellisense, lsp) user throughout my career. Never had any real problems with them; they were convenient tools, nothing that different from someone using grep/fd etc.

The codebase I (used to) work on is a 30m+ line behemoth, and API frequently changes underneath me; an LSP is crucial to get the work done. How could anybody keep two dozen+ minor-naming and subtle-semantic variations of the same method in their head? I'll say yes to auto-complete any day of the week, I thought.

About two years ago, I've noticed some worrying cognitive signs. Out of the blue I realized I could not remember the name of methods, classes, interfaces, even the ones that I use daily. I could code, there wasn't any problem with that. But I could not write anything down without auto-complete. I couldn't even fill the arguments of a function without the LSP holding my hand throughout the ordeal.

With the realization that both my grandmothers went through dementia/alzheimer's, I truly felt like walls were closing in on me, in real time. Of course, I went for a check up, which came out clean, but I could not shake that feeling of impending doom.

By luck ---and some hefty dose of depression due to unrelated personal reasons--- I started writing a toy compiler in C, something that I had no experience with whatsoever. With just a text editor, because I dreaded having to install visual studio on a two decade old computer (which was the best I had under the circumstances). Despite forcing myself to fumble through, a few days later I noticed that the entire code base was in my head. I knew precisely what I wrote, how I wrote it.

Life went on and I went back to work. And only then I noticed. I was waiting for the LSP to catch up and fill the correct type, my mind went back to my crappy lexer. Programmer? No, I felt like a factory worker on an assembly line.

A month after that I finally gave my resignation, then started a new (self-employed) programming job. For the past year I've been working on a game + an engine, without intellisense or LSP. In fact, I even disabled syntax highlighting a few weeks in, and never turned it back on. I've ditched quite a few of my regular tools, opting for simpler (often homemade) alternatives; simple bash script instead of cmake for example.

Suffice it to say, I've come to some personal conclusions. These conclusions stem from my personal bias, true, but I do feel strongly, that they apply widely to the field as a whole.

In short:

1) LSP, intellisense, code completion, are overall harmful.

2) Syntax highlighting does not work (most of the time), it just satisfies the part of our brains that like to recognize patterns.

3) Complex and highly integrated tools are a net negative unless they are purpose built.

Most people will vehemently disagree with all of the above. That is fine; I'm not on a crusade against the machine, so to speak. I just wanted to share my view since I resonated with the post I'm responding to. But I will still briefly explain what I mean, in case if anyone's curious. (In part 2, because comment was too long)

[habosa]

I think lumping in LSPs to Copilot is wrong.

The LSP is a (mostly) deterministic system that surfaces information provided by the language or by other programmers (types, comments, etc) which are meant to save you time and reduce the cost of context switching.

The other is a completely non deterministic system which generates code from thin air.

That would be like comparing GPS to a self driving car. Both are certainly helpful aids but using one is not like using the other.

[irrational]

I learned and worked for decades before these tools were available. If they still weren’t available today, you would find that you too could program without them.

[brookst]

Sure, but isn’t this just “why don’t you use the backup camera that all cars have had for a decade or more” / “I learned to drive without one, and you could too”?

[battle-racket]

Maybe it's my ADHD, but I cannot for the life of me stand using an IDE. There's too many distractions - popups, suggestions, underlines, warnings, and a million different buttons cluttering up your screen. That along with an AI assistant would make my head explode.

All these things that supposedly "help" us code end up limiting us in severe ways because we aren't forced to think anymore. Typing, syntax checking, and recalling function definitions isn't the bottleneck to programming. If they are, maybe you're not programming.

[ARandomerDude]

1. Memorization (i.e., knowledge) beats tooling every time.

2. Pain is the most effective way to learn.

I was a 90s kid, still just young enough to have my parents tell me to go get out a paper dictionary when I asked "what does this word mean?" It's amazing how much better it "sticks" when you have to stop, get up, open a book, and find the entry.

With a minimal vim setup, I find that I just know Linux, the language intricacies, and the codebase better than my coworkers – not because I'm smarter but because I have to manually look up things I don't know. It's slower in the moment but over time it is much, much faster.

For the same reason, I never copy/paste code that I could not have written from memory.

[zelphirkalt]

Use it or lose it (or never gain it in the first place).

In a past job I have worked with other engineers and even some, who were senior engineers, however, I was the only one, who was able to write a proper shell script. This knowledge came in handy also for writing CI files, which somewhere tend to have shell commands in them.

You don't do it yourself, you don't learn it. Simple as that.

[ryukoposting]

I tried copilot for a few months, found it annoying, and uninstalled it. These tools make IDEs/LSP unnecessary for my workflow:

1) regex be it grep, or equivalents built into the editor. 2) Multi-cursor editing. 3) dumb autocomplete. 4) knowing how to type fast.

About 70% of the code I write at work is C. Another 20% is Rust (which does have a nice LSP implementation that I use, though I wouldn't call it essential), and the remaining 10% is the usual bash/Python/Ruby/cmake/make mumbo jumbo.

[iamsaitam]

I think purism is a slippery slope for experienced people, I too suffer from this to a certaint extent. It's natural to fight change as you get older and it's part of the struggle to change your behavior and adapt to the changing times.

Short comment regarding syntax highlighting, unless you have some impairement, I think everyone benefits from this. It's something that helps you recognize patterns much faster and you can skim through the code way faster than without.

[bigstrat2003]

I don't benefit from syntax highlighting and don't see how anyone does. It's pretty, but doesn't convey useful information that isn't already right there in the syntax itself.

[efxhoy]

My preferred way of working is plain sublime text and the terminal. I use command line tools for linting, formatting and type checking, wrapped in “make lint”.

I find that sublime is just smart enough to go to the definition using only its “dumb” grepping based approach.

I think the hurdles of getting a nice LSP setup that works across projects in different languages and in a polyglot monorepo is a real determinant. I just really dislike spending any time configuring my editor past the basics, because I’m lazy, updates break them, I move between machines, etc. Getting comfortable with just the basic features means I have less pain maintaining my editor. It’s not a great excuse but for me it’s the path of least resistance.

I frequently pair with colleagues, some are vscode users that are heavy on LSPs and copilot. I have one greybeard colleague who runs a very sophisticated neovim setup, and spends a lot of time maintaining it. We’re all roughly equally productive at the “writing code” part of the job. What sets us apart is our skill in actual software development, which I find is completely uncorrelated to the editor setup. We all work in the tools that are most comfortable to ourselves.

[bschwindHN]

I do basically the same exact setup. It works, it's fast, and it's simple.

I also work almost exclusively with Rust, so I just go to crates.io. for uniform documentation for all the libraries I use.

[codazoda]

> What do you do if you need to look up the definition/implementation

I have these features on (more or less) and I still use grep, ag (the silver searcher), and GitHub search. I often need to look for things my editor can’t possibly figure out. I’ve never found editors to be great at this. Then again, I probably haven’t optimized for it. I’ll admit that might be a mistake. Old habits die hard sometimes.

BTW, I’m usually looking for other people’s work or code I wrote long ago. Functions written somewhere in a vast code base that I don’t have completely checked out (because I’ve never coded on parts of it). I don’t think much about the obvious stuff, like a function in the standard library.

[magnetowasright]

Autocomplete in code is the single most annoying thing I've ever experienced. While I do have a fantastic memory, I don't feel like it makes a huge difference? I don't quite understand the workflow using autocomplete, I suppose. If I'm typing something I know what I'm trying to achieve (with or without a more concrete implementation plan), the general context of the code I'm working with, and it is quicker and far more enjoyable for me to just type instead of dealing with a minefield of never ending pop ups from autocomplete. I know the types/fields/classes/language features/whatever because I have to in order to do whatever I'm doing. I reference the relevant code, open in other tabs in my editor. I also reference documentation. I don't really find myself wanting for more. I don't understand how using auto completion would impact needing to know that stuff anyway? I get that it's annoying and maybe less efficient to have to type out all the params and types and other predictable stuff by hand but you have to know it to make sure the option you've chosen from the potential many options suggested is correct anyway, right? It feels like less mental and physical effort to me to just type exactly what I mean instead of having to review options and double check I've chosen the right one, but I can kinda understand why that's a minority opinion. I still fuck it up or end up changing my implementation and having to revise it anyway but I definitely prefer to type.

Before I figured out how to configure Sublime Text (I used Atom until it was killed) to have JUST go-to-definition and no other LSP features enabled, I'd just do a quick couple of searches across a code base or file. It was fine tbh. Yes, a single key press is much nicer but it really wasn't that annoying to not have it. I got just go-to-definition working and was able to turn literally everything else off and I'm really happy with it.

For context, I've worked in all kinds of code bases with all kinds of quality and organisation (including lack thereof) in a variety of languages and frameworks, and I've not really felt the NEED to change. I do try VSCode and/or using more of these typical IDE features maybe once a year in an attempt to leverage these features that seemingly every other programmer feels they gain a lot from but I just HATE it. I can't stand it. I really have tried! I do assume I'm leaving some quality of life and productivity gains on the table but I've never been able to make it work for me.

[pbowyer]

> While I do have a fantastic memory, I don't feel like it makes a huge difference?

I'd say it does. Particulary for names based on English words with synonyms, if I recall the wrong synonym for this particular library, at least autocomplete is faster than searching the docs for all the synonyms. But not as fast as scanning the method/function list should the docs have that (and far too many miss it out).

If you can remember which word for the concept the method you're after uses, then you don't need autocomplete.

BTW only Jetbrains (and other heavy Java IDEs?) get autocomplete right IMO. The basic form in VSCode doesn't cut it in my experience, and gets in the way.

[akerl_]

I do 100% of my software development in vim. I have syntax highlighting and some auto indentation but otherwise no autocomplete, no LLMs, no vim plugins for hopping between files.

I just… write code? If I need to remember what’s in another file, I open up that file in an adjacent iTerm pane, or pull up the docs for the library, etc etc. if I want to have the program run every time I save, I run a watchexec in an adjacent pane.

[xlii]

As many others I do use fd/rg/ctags, custom scripts, some even Perl ones; Today I’m on Kakoune but had plenty of Emacs integrations when it was my daily driver (Kakoune taught me to pipe selection through a script that echoes code fragment which works in most editors, e.g.: `|gosnip_if_err_panic.pl` with `responseErr` selected).

I think that the reasons I’m not using IDEs/LSP are more worthy sharing:

First one is that I cannot use one. While the main language I’m using has relatively ok LSP, the codebase prevents usage - as it’s ridden with circular dependencies, macros, module aliasing and multi dispatch cast chains. Everything outside of syntax highlight it unusable.

Second: I noticed that assisted coding is like GPS assisted driving. I stopped internally understanding architecture of the code when using IDEs, this disconnected my mind from the code and at some point it started to feel like shoveling. Mindlessly spit out the code at let IDE handle the rest. That made me efficient at local change but unable to build up and see „big picture”. It bothered me to the point I decided to not use them anymore.

The third thing is that I don’t take „no” (coming from software) for an answer. I often get those specific needs for code search/refactorings that IDEs/LSPs refuse to work with. E.g. I need to search customized OpenAPI specifications and link it to a macros/generated code for browsing. IDEs/LSPs cannot help as it’s not idiomatic, so I customize. And customization is a loop. You customize, you learn how to customize better, you customize more etc.

When it comes to LLM-based aids I’m at point of minimum trust. I’ve experienced so many problems with that code that I rather just disable it entirely. Example? I was setting up Ticker based waiters for Go and then in one place I accepted `time.NewTimer` local-LLM snippet instead of `time.NewTicker` in infinite loop. It was 4 lines of code and looked VERY similar as in 3 functions above (that was before code reduction phase). For those unfamiliar: Go’s ticker ticks every N time. Timer fires once. One-shot-fire in infinite loop == lock. Took 4 hours to debug.

I’m not against using LSP/IDEs. They have their use (but for Pete’s sake ask your organization leaders before feeding proprietary code into ChatGPT). They don’t work for me, I feel dumber. Maybe I’d be more efficient but I don’t care. I do this job also for fun, and GPS kills the fun part for me.

[lispm]

I load the Lisp code of a project into the Lisp environment, which is the program and the development environment in one thing. Then all the information about the project is available in the running IDE/program combination. The thing then is fully reflective and introspective.

An example is GNU Emacs itself. For Emacs Lisp it is both the IDE and the application environment.

Similar integrated systems existed already earlier for Lisp and Smalltalk. Interlisp, the MIT Lisp Machine, Smalltalk 80 and others were examples where the IDE and the code was integrated.

OTOH, the combination of GNU Emacs and external Lisps, like Common Lisp systems, was basically LSP before LSP existed. There were tools like ILISP, which connected GNU Emacs to various external Lisp runtimes (which have all the development information about the loaded code). SLIME replaced it at some point in time and usually connected to external Lisps via network connections.

[Rendello]

I like syntax highlighting and basic automatic indenting, but not much beyond that. I can't stand autocomplete if there's an automatic popup. I tried some LSP stuff and it was quite nice but I couldn't turn off some features in my editor and they distracted me. The thing I really can't stand is automatic closing of parentheses!

[zelphirkalt]

If they are good at what they do, I think they are simply good at keeping things in mind, what everything is called, developing a good mental model.

Personally I often write code without LSP, and use pure text completions with Emacs (words of opened buffers) and cycle through them. I know the language well enough, or I look things up in their documentation until I know them well enough. Occassionally I will also use LSP, if it exists and is easily configured and works well.

Go to definition: If I don't have it, I develop a map of the project in my mind where I find what in a project. I have also observed how projects become not so well organized, when people rely too much on always being able to "navigate through code". One does not need to pay much attention to module naming or class names and the like, if one never na igates the file tree to go to the file. Sometimes I have to rgrep/ripgrep.

[exDM69]

In Vim, the "stupid" auto complete will get 80% of the way there and works without setting up a language server and it works for any language.

By default it will give all the identifiers in all open files. Having a few of the relevant files open in the editor will get you pretty far.

I do use LSP in other environments where it is available but I still do a lot of my work with just plain vim because I jump between code bases a lot and setting up LSP for C/C++ needs some extra steps to work.

[codr7]

I feel that's a big issue with learning a language in an IDE.

I've written a ton of C# and I don't remember shit about methods in the standard library, because it's all there, and getting worse with AI. Not to mention the detrimental effect that the constant interruptions must have.

I use IntelliJ for Java, but since I learned the language and standard library long before fancy IDEs were a thing I barely notice the blinkenlights.

[mgaunard]

Good code should be designed such that it's easy to find where things are to begin with.

If you need an IDE, that just means your code is a mess.

Ironically, the more messy the code is, and so the more you need the IDE, the more likely it is that the IDE will have trouble coping with the code, becoming extremely slow, or randomly failing to jump into some functions.

Ensuring your codebase remains workable without an IDE is actually a good litmus test for quality.

[wenc]

I used to code in pure vim, so no autocomplete and syntax checking. It is definitely possible.

Is it a better way to work though? Well, in some ways, it forces you to use more cycles in your head, so you do gain proficiency, and you can spot mistakes more quickly. This is a skill.

But once I started working on larger codebases and higher complexity code, I felt it was better to redeploy those brain cycles toward thinking more about architecture, and letting the LSP check the code. With an LSP, I'm now able to write more correct code in fewer iterations.

Like everything it's a trade off. Am I impressed by people who can do complex mental arithmetic? Yes, but for anything complicated that I'd rather not get wrong, I will reach for a calculator. Same idea here.

[Jugurtha]

I don't use any of these out of ignorance first, laziness second, and incompetence third.

I didn't know about them, and I had spent a lot of time with the documentation and code of everything I touched (language, dependencies, etc). Looking things up reinforces this. The value of a feature such as autocomplete is marginal to me as a function of the effort I have to make to learn how to use it properly, the frustration of using it improperly, and the added steps to fix a blunder, so I just don't bother with it.

I also have a habit of having the documentation/book/code of a dependency open nearby and doing my look-ups there.

A lot of time is spent refining existing code, debugging, optimizing, refactoring, etc...

[spamizbad]

So back in the day before LSPs:

Typically I'd leverage 2 large monitors and keep at least 3 editor "views" into code open at once: one for what I was actively working on and 2 others that would contain reference code. You also take considerable care as to how you organize the code, so that grepping for definitions is easy. If I needed to see how a particular object or function worked, I'd pull it up in one of the auxiliary code windows - which would typically start with a grep alias command that would have a shortcut to open it in a designated emacs buffer window. Not anywhere near as convenient as an LSP but it got the job done.

[jcalvinowens]

I do most of my programming work in vim on a machine with no X. I will literally use grep to look for definitions, and it really amuses me now much this horrifies people. At the risk of sounding like an ass... I'm exceptionally productive, it works for me.

I feel very strongly that the key to getting things done in the real world is the ability to identify simple tractable solutions to complex problems, not some ability to crank out mountains of code by brute force.

If I'm constantly needing to search for definitions, that tells me I've failed to spend enough time studying the codebase before trying to patch it. I'll shelve what I'm trying to do, and go study the code for awhile before trying again. How can I possibly hope to see the optimal solution, when I clearly don't even understand the basics of how the code is organized!?

I use tools like cscope when jumping into something completely new to me, but I find they quickly stop being useful once I've gotten to know the project.

Spending hours to days studying a large complex codebase is a necessary prerequisite to successfully working with it, IMHO. Shiny IDE tools can juice short term productivity by allowing you to brute force through code you haven't taken the time to understand, but that costs you a lot in the long term.

Of course, you can use the IDE tools for code study: I'm not saying they're inherently bad.

[CarVac]

I want to be able to reason about my code without sitting in front of it, so I simply don't use those tools and this understanding of the codebase builds over time.

When you're working in one area of it, you read it and make additions in it repeatedly, and eventually your familiarity increases until you have mastery.

Then you can code anywhere, anytime, and merely type it in when you get back to the keyboard.

It's like learning a (human) language. As an analogy: "[foreign language] speakers who don't use a dictionary, how do you do it?" But the foreign language is your codebase. Learn it.

[finnthehuman]

> So to the devs who don't use these tools, how do you do it?

This is the kind of question where you can easily go get a much better and more comprehensive answer on your own by experiencing it yourself.

[iio7]

Before mobile phones where a thing, we used to memorize the phone numbers of every family member and friend and co-worker, etc. The numbers we rarely used, we wrote down or looked up in the phone book. When you got a new number, you maybe wrote it down, then after having dialed it a couple of times, it stuck. This didn't really require any effort, it was just the natural way of doing things.

Then came the mobile phone with the ability to store contacts, today I can't even remember my wife's number.

I have coded for more than 40 years and I hate autocomplete, language servers, etc. I don't use any of it because I have found (after having tried to use it all) that, just like with phone numbers, you don't remember much if you use all of that and you have to make a real effort, but things just don't stick the same way. But if don't use any of that, you only have to look things up in the beginning, then occasionally, then rarely or never again and more things just stick, you get faster in a natural way and you understand your code better. You also think deeper about how to structure your code and how to organize everything.

If you always use a crutch to help you walk, you will never walk by yourself. The crutch will look like it is helping you, but that's only in the beginning, eventually it will hinder you and hold you back.

That's my 2 cents.

[ximm]

I prefer using language agnostic tools where possible because that is both simpler and allows me to use the same tools with every language. For example, git, grep, or vim all work on any text file. vim has a few language specific settings though (e.g. syntax highlighting).

[jgb1984]

Been using Debian and vim for almost 25 years now. Tried many IDE's but they're distracting, bloated and slow.

My main language is python and for that I use jedi-vim (which allows me to jump to a definition), fzf with ripgrep to easily open files and search for specific things, and ALE that runs ruff formatting and linting. Tmux to keep my terminals organized and openbox to make it stylish and stay out of the way.

No LSP, no autocomplete, and sure as hell no AI nonsense.

[diegof79]

In my experience, code navigation features are necessary for writing code comfortably. If you mean only auto-complete by LSP, then yes, it saves you some typing or function lookup, but that’s not the main benefit for me.

Years ago, I worked for a long time using Smalltalk (VisualAge Smalltalk, to be more specific). Older Smalltalk versions didn’t have autocomplete. But it wasn’t a problem because Smalltalk has excellent code navigation features: find implementations of a message, find callers, and evaluate code inline. With those features and some code conventions, I never felt the need for autocomplete.

Perhaps it’s my Smalltalk legacy, but nowadays, I use the most Cmd/Ctrl-Click to navigate to the implementation, read the sources, and use the “find references” feature. I don’t know if the LSP implements those features, but reading the sources gives me much more information.

Before programming in Smalltalk, I did some C++ and Java programming. While all Java IDEs had autocomplete, C++ autocomplete was unreliable on most tools I used. The solution is to read the docs and the source using search tools across the code base and third-party sources.

[alentred]

In the past I have been training in a coding "bootcamp" for a while. I insisted that people new to coding use a plain text editor, like Notepad on Windows, no syntax highlighting, no autocomplete, nothing, and a command line to lint and compile the code. I only introduced the IDEs much much later, closer to the end of the bootcamp. First, I confirm that it is perfectly possible to complete rather complex projects this way. Secondly, I have no ground truth to compare my results with, but I know that most of the students appreciated the fact that they do not depend on the IDE/LSP/Copilot that much and developed their own understanding of how the things work.

I don't advocate to do the same outside of the learning process, of course. The tools help a lot (in fact, LSPs are awesome), but there are two principles that are important here I think:

- having an understanding of the underlying code, language, etc.

- being intentional about the use of the tools (e.g., invoking auto-complete with a keystroke vs an endless suggestions list; running a linter explicitly vs a code bloated with "insights" and "warning highlights", etc.)

[akoboldfrying]

"Back in my day, goin' to foo's definition meant packin' yer bags for a four-day horse trek over the mountains..."

Seriously though, pressing Ctrl-B in JetBrains IDEs is half my workday.

I just tried out Copilot starting a couple of weeks ago for Advent of Code, and I'm very impressed. Easy 2x speed boost, with occasional bursts of much more. I'm mostly using Java, though I've tried Perl and it knows that too.

[chikere232]

I use auto-indent and syntax highlighting which is sort of an IDE feature, and some other quality of life things like triming trailing whitespace on lines I edit. I also trigger compilation from the editor so I can step through the compilation errors one by one.

I know my editor (emacs) could do some of the more advanced things you mention, but it needs a bit of setup and I'm lazy. It's not really a blocker.

I look at the docs if I'm doing something new to me or have forgotten a function call. I google more complex things which often gets me more useful info than an IDE could give me, unless it's drowned by AI-slop.

If I want to dig around in a codebase I can grep for things, or just open a likely looking file and isearch for the thing.

I do git etc from the commandline, which I could probably do from emacs too but I never really bothered to.

I have nothing against IDEs and have used some at places where it was harder not to because they'd standardised on a common one. I kinda enjoy the simplicity of just having a familiar editor for any language I encounter though.

[pino999]

I did for a very long time. I only used vanilla vim, a terminal, a couple of core utils, and documentation.

You just learn to memorize a lot, organize and design your code. It feels very similar to learning to navigate a city without map. The map will be in your head. A very similar feeling I had with code bases. I navigated a map, sometimes I knew the route towards a piece of information, sometimes I knew exactly where it was. Sometimes you add a building or a new road, but you all keep it in your head.

Nowadays I use LSP, autocomplete LLM's and what not. Makes things easier and above all faster.

I still can do without, I am just a bit slower. For small changes and simple scripts I fallback to vim. For git I still use the terminal. And I still use a lot of commandline utilities, because each IDE has a zillion of commands that do the same anyway.

For your example, nowadays I would use grep or some modern equivalent to search for definitions. And to be honest, that isn't that much slower. I can have my editor open in tmux tab and in the other my editor. You don't have to jump through files then.

[thedanbob]

I'm a Rails programmer and recently the Ruby language plugin for VSCode I was using was deprecated so I switched to Shopify's ruby-lsp. On the one hand, it's much much more capable than the old plugin: better syntax highlighting, actually useful inline definitions, style hints, etc. On the other hand, it's also way more annoying: there's a bug that sometimes breaks my projects' dependencies so I have to reinstall them, the code completion actually slows me down more than it helps, and if the LSP can't start for some reason (which happens quite often) I get a stack of error popups in the corner of my screen.

On the whole I think I prefer my old setup. All I really need out of my IDE is decent syntax highlighting. I've got devdocs.io for Ruby and most Rails definitions and I know how to spelunk through the Rails codebase for anything that misses. Go-to-definition is handy for my own code but I generally know where it lives, and if I've forgotten there's always ctrl-shift-f or `method(:blah).source_location`.

[john61]

The hard part is not writing code but to maintain a deep understanding of how it works for a long time. The tools you mention do not help in this regard, maybe they even worsen understanding, structure, format and comments.

[Muromec]

At some point in time I wrote vue.js in vim without syntax highlight. For a few months. I had to eventually configure it, once somebody asked me if I'm color blind (I'm not).

>So to the devs who don't use these tools, how do you do it? Do you just remember every type and field in a codebase? What does your flow look like?

You don't have to remember every field and type, because you don't work with all the types at the same time. Ones that you work with more often, you remember.

Workflow is something like this: open the file, split to left and right to see two stack frames of the same code path, open another terminal tab, start test watcher. Make changes and see tests fail. If tests don't fail -- write more tests. Then write more code. The usual TDD struggle. In case of CSS, just change it in the browser, then copy back to editor and refactor a but, then check again.

When in doubt about spelling, press shift 8.

>What do you do if you need to look up the definition/implementation of some function which is in some other file?

:open another file and search through it, quote simple. How do I know which file to open? I know and when I don't git grep goes brrr. In theory you can jump to definition even in vim, use fzf to open files faster, in practice, none of that is not the limiting factor.

The limiting factor is iteration cost and the size of your context window.

That all being said, I use vs code now (at work) and use jump to definition all the time, because typescript support is just better in vs code. I think I started using it the moment I had to open more than one repo and switching between them on a regular basis.

Then I get back to my own fun stuff and there I use vim.

[throwawa14223]

I discovered copilot was disrupting my flow and providing subpar suggestions. Autocomplete and language servers seemed to result in me not knowing the language and libraries as good as I would otherwise.

I almost always have a browser with documentation open on another monitor and while there is a speed hit removing the tools I feel like it improved my mastery of software engineering overall.

[atrettel]

I suppose this is like a lot of tools in general: you just get used to doing it yourself. People wrote code before tools like that existed, and you can too if you put your mind to it.

I typically just use plain Vim without much customization. You get used to it. I am somewhat forced to use just plain Vim on most things because I often write code on random HPC servers and have no control over what is available. But Vim is universally available, so I got good at the one tool available to me. Vim does have have Ctrl-P to auto-complete a word, though.

I also have books and other documentation available, when possible. Man pages are actually quite good and available on many systems I work on. For C, you can type something like "man 3 printf" to get basic documentation on "printf". This works for MPI too with things like "man 3 mpi_allreduce". I've been pleasantly surprised at times how much offline documentation is available.

[0xfaded]

I'm one of these, though I use a simple version of autocomplete which only suggests other strings currently loaded in my vim buffers (helps with RSI).

I liken it to spaced repetition. The first time I don't know where to find something I grep, after a few times I start to remember. I have a vim layout with 12 windows, so I have many views into the code and always have space to pull up more without losing context. I genuinely feel claustophobic with less.

> What do you do if you need to look up the definition/implementation

Sometimes I feel "jump to definition" trades immediacy in favor over natural exploration of the surrounding code. I work on a 10 year old mono-repo with 1000s of contributors. After two years I have a good feel for the basic layout, and would say I have a good mental map of the stuff that most affects me. During code review I'm often pointing people to existing implementations that they've just duplicated.

[selamtux]

i remember when i start coding first time (with note pad), first couple of month i keep pocket book close, then i download the manual (it was 56K times) and it was open all the time. back then memorizing functions from stdlib was a normal thing, but there is a saying, always check man page after you write the code.

first time i use an editor which have auto completion but it works only for same file, it was time saving thing.

then i see real auto completion feature, full function name, parameters, returns and couple of words from manual, it was mind blowing for me.

then i start using eclipse, with one click whole class generation from interfaces etc. one of my friend create its own snippets and it was writing like 3 person, couple of keyword strikes and bamm, whole thing is ready.

then internet become something like air instead of water, constant flow of information, constant needs.

[mvanveen]

> What do you do if you need to look up the definition/implementation of some function which is in some other file?

At some point, for me, ‘find <dir> -name “*.ext” | xargs grep <pattern>’ took over for recursive grep, because the required tools are available on most Unix systems.

[dools]

I've never used an IDE, perhaps it doesn't matter because I don't write Java. I actually find auto complete annoying in places where it can't be turned off like Google Apps Script or the BigQuery console.

Over the past few years I rarely write code anyway I just use ChatGPT and then edit the code.

I tried using the new canvas/project features last night and I think it slowed me down versus a copy/paste workflow. I think those formats could be good but they're not fast and polished enough and I've gotten used to tricks and hacks for working in chat style.

I've never used a LLM that has actual access to the codebase, so I kind of take chunks of code and put them where they need to be. Even if I have like 6 lines of code and I want to change the logic I past that into ChatGPT and say "change this to do XYZ". Even though that sounds dumb I actually gain massive advantage in concurrency. I can be working on lots of tasks at once because ChatGPT kind of toils away and I'll then jump over to something else and come back 90 seconds later and the code is there, I read it over, maybe diff it from a previous version, then I run that to test it and maybe while that's running I go to a different chat and issue another instruction.

Before LLMs I used vim. When I want to find a function definition I ctrl+z find . -name ".whatever" | xargs grep "function whateverThisIs" and things like that.

grep -d skip "thing"

I copy and paste a lot if I'm using function names, I use a clipboard manager I guess as a sort of pseudo auto complete.

"Then why don't you just use an IDE?" I hear you ask!

It's because I write lots of what you might call "glue code" or "microservices". Lots of snippets of SQL and JavaScript functions that are executed on a queue, and API calls to integrate with things and code that runs on different platforms.

I'm almost never working on what you would call "an app" these days, so that's probably why I've never gravitated towards an IDE. Even when I was working on more monolithic web apps I never used anything other than vim with "set nocompatible" turned on so it wouldn't try to do anything IDE like.

I think what I liked about it then was that I could be just as productive using putty from an internet cafe as I could be on my own computer. Like a doomsdray prepper version of coding.

[theideaofcoffee]

My bottleneck is how efficiently or completely I can keep the problem I'm working on in my head, not how quickly I can look up a function name or variable or type out the actual code. Really, only the latter is helped along by autocomplete. I find myself with that feeling of my mind slowing down more and more as I get older. When I actually get around to writing the code itself, the problem is mostly solved from my perspective, I'm just dumping out of my head into the editor, that part is easy. Until an autocomplete is wired up with an LLM and LSP which knows exactly how I think and approach problems and remember the codebase, it'll be mostly useless for me. So I don't bother.

[sparr0]

In my experience, autocomplete/intellisense/LSP/etc is very difficult to get working on most codebases if you aren't already intimately familiar with how that codebase / language / framework / etc works, or someone with that familiarity has laid out exact steps for your IDE.

When I see someone using these features as part of their workflow, I semi-confidently predict that they spend the majority of their time working on a single codebase, such that the time investment to get everything working was worthwhile.

If, like me, you work on multiple different codebases most weeks, it rarely makes sense to even try setting those things up.

[pandemic_region]

In Java, not having something that automatically inserts imports would be incredibly counter productive. I feel that this is easier in other languages, where you don't need to manually import almost every 'jdk' class that you use.

[bawolff]

> What do you do if you need to look up the definition/implementation of some function which is in some other file?

I open the other file.

[okaleniuk]

I use IDE at work but rarely at home.

My design is usually very simple, I don't have to keep a lot of things in mind to begin with. For instance, https://wordsandbuttons.online/ is about 100KSLOC now, but since it's inherently flat, no dependencies, no third parties, I can manage it with a Vim or a gedit with none of the IDE features. My implementation is always in the same file as the call.

I suppose, IDE makes writing harder code easier, which results in tons of saved time, but it also makes writing harder code easier, which results in tons of hard code.

[dpcan]

I’ve been doing this a looooooong time. And that’s really about it.

Every time a popup or tooltip covers code around my cursor I groan in agony.

I’d probably use it if the tool tips just updated in the bottom right of my screen while I typed or something.

[hn30000]

CS department at my alma mater was very, very theoretical and we were encouraged to just write code in text editors. After that I got into programming for CAD software which had rudimentary editors as well. Basically I just memorized a bunch of stuff and always had a second monitor with the docs open. These days I use autocomplete but I still largely code the same way, and for better or worse I’m set in my ways — at least when I’m using libraries I’m familiar with. If I’m messing around with something completely new then sure, I’ll make extensive use of autocomplete.