> How do you do debugging?

I read the code and follow the state transformations in my head. The huge advantage is that this also works with software running in production, when all I can do is crank up the log level.

When I have access to the code and the compile-test-run cycle is quick enough, I speed up the process with printf debugging.

> Meaningful autocompletion?

I have a second screen where I can browse API documentation.

> Meaningful project management and navigation?

https://www.gnu.org/software/coreutils/coreutils.html

----

I don't know; maybe I'm just good at what I do. I have noticed that I can hold much more state in my short-term memory than other developers around me, and that helps enormously during debugging. The most important part of debugging is forming a mental model of what is going on. For some applications and subsystems that I wrote (between 100 and 10,000 LOC) my mental model is so fine-grained that when a user reports an error, I know which line of code is broken before I even cd into the source tree.

It should be noted that I'm not ignorant of IDEs. I have done a lot of work in Visual Studio some 10 years ago, and I liked it very much. When I moved to Linux, I switched to a text editor and gcc because these were readily accessible, whereas choosing and learning an IDE would have required additional effort.

Over the years, I've never found that effort worthwhile. I have used gdb a few times, and had some good times hunting memory management bugs in my C++ programs with Valgrind.

Instead, I've come to appreciate that on every system that I ever SSH into, vim is always just a package installation and (optionally) a git-clone of my vimrc away. And if shit hits the fan, vi(1) will do. And if shit really hits the fan, sed(1) will do.

Oh, I just remember that I had a relatively recent experience with IDEs: I had to use Java and Spring Boot for a university project, and was forced to use Eclipse because I could not get shit to build otherwise. It felt like being strapped in a straight-jacket, compared to the seemingly infinite freedom that a command prompt on a terminal has come to mean to me.

I have two IDE-like features in my vim: Syntastic (a plugin that runs syntax checkers and linters and shows the errors and warnings in-line) and a tiny vimscript that runs gofmt/goimports when I save a Golang file. My other plugins are all focused on more comfortable text editing.

----

I don't intend to hate on IDE users. If they can work better with an IDE, then that's great. I'm more productive without them.

----

Sometimes I snicker when someone on HN complains that Rust is totally unuseable because there is no stable IDE support yet, or something like that. And I'm sitting here and writing syntax highlighting rules in vimscript for DSLs that I just made up.

EDIT: One more thing. The choice of languages and frameworks shapes the choice of editor. I would never try to develop a Java project in vim, and working on Rails apps leaves much desired. (I could try to find a good IDE plugin for vim for the language in question, but I'm changing languages very frequently and don't want a bazillion IDE plugins clogging the editor.)

And of course, the same applies in reverse. Because I'm a vim user, I will prefer languages that play well with vim. Right now, my most-used languages are Golang and shell script and YAML (if that even counts), and these all work nicely.