Note I'm not knocking down on IDEs; as an Emacs user I would love reliable semantic indexing and navigation, but all the solutions that I have tried (rtags was the best) consume a lot of time and CPU indexing and switching branches often forces a rebuild. Currently, on a 1M lines code base I get around with projectile (which uses the project git as a file index) for file discovery and ag for brute force search, which at least on linux can search the codebase quickly.

If you are from gamedev land though everything is rigged around working with Visual Studio, so the debugging strategies/workflow I feel are more related to that than anything else. You also (generally) are debugging relatively locally to the problem as opposed to continents away. GDB and TUI stuff is wonderful if you are 6+ timezones away from the problem.

It is also possible that the kind of things you are debugging also don't fit Visual Studio and better served by tools and things like WinDbg. This comes up when you are doing kernel driver debugging or really having to work with lots of symbol server shenanigans when you have kernel dumps from all sorts of random versions of Windows.

There's a lot of tools out there, and Visual Studio is often not the best tool for the job even for debugging. Settling for Visual Studio has its own set of compromises. As I mentioned for gamedev the Visual Studio experience is the current de facto standard for engines like unreal and as far as I am aware many of the SDK's for consoles, and all of the asset creation tooling from Maya, 3dsmax, etc. There are just other things that exist in the world than the primary pipeline that Visual Studio services with fantastic tech.

I have to use the VS debugger at my workplace, and even as someone who has merely dabbled in GDB a bit, I recognize that it's so far out of VS' league, it isn't even funny.

I'm working with vim on a ~5 million line C++ code base. Thanks to rtags[1] I've all I need: auto completion, goto definition, even semantically correct renaming or finding all locations in code calling a certain function.

I'm certainly not saying that it's as polished as 'Visual Studio', but it works pretty well.

If tooling isn't baked into an IDE - which unfortunately is often the case - then pretty much every editor with some kind of extension mechanism can take advantage of it.

> Maybe it's just because this is what I'm used to, however I just don't see how some of the tools would even be displayed in a terminal (parallel stacks window, for example) without some horrible ascii node graph.

Yes, most visualization are text based. E.g. for showing the references for a function rtags uses the Quickfix-window of vim, which pretty much is just a list with one entry for every reference. I can now jump to every occurence in the list or even execute an operation on every reference, like I've removed the last parameter of the function call, and now I'm defining a vim substitution command for removing the last parameter and execute it on very item of the Quickfix-window.

Sometimes visualizations are certainly helpful, but I never found them particular useful for software, because the more complex an application gets, the less useful the visualizations become. At some point you're less interested on the class level and more on the system level, but tools can't that easily detect what are the systems in an application.

[1] https://github.com/Andersbakken/rtags

The visualisations I’m talking about are mostly debugger tools. The parallel stacks view is life saving when you’re trying to figure out a deadlock. Having to scroll around this huge viewport with a cursor would just piss me off. I just can’t see how you could navigate a huge (10x screen width) node graph in a text terminal using vim style commands.

I had a look at parallel stacks and it looks nice and seems quite helpful. But I have to think, if you have that many threads that might deadlock and it happens often, if your architecture might be the issue.

Most of our parallelism is job based. There is a job queue and worker threads are taking jobs from it. So deadlocks are pretty much a non issue for us.

I‘m not trying to say that everything you‘re doing is obviously wrong, but the older I get the more suspicious I‘m getting if there‘s a need for „fancy“ debugging tools, because it might mask that there are some more serious issues in the application.

For a game or similar code that's sometimes too much RAM, and usually too much latency.

It sounds lame early in your career, but after a while, switching between C++, java, JavaScript (ok this one requires a little more involvement because the browser is the compiler of sorts), typescript, etc is very easy.

When you switch languages/projects it is just a matter of opening a file with a different extension. All your text editor muscle memory is still there.

If you use IDEs, today you are on a project that only builds in eclipse, tomorrow intellij, then you move back to C++ and have to use visualstudio... and you don't even know the Go To Line keyboard shortcut or Text Search...

Since he started streaming he has moved (from emacs?) to I think http://4coder.net/, which seems to have spawned from his audience. Similarly, a few debuggers have, too. https://remedybg.handmade.network/ https://lysa.handmade.network/ but I think he still uses VS' debugger.

Anything else really visual, like CSS, and I need a GUI to feel productive. It's because the changes in the system are dynamic and cascade in unexpected ways. You make a box a little thinner and a heading flows to a new place and now the space between the heading and the image is off, etc.

But I look at that very differently than an overall pronouncement on development. If I'm primarily interacting with data and transformations then GUIs are a disease that do nothing more than slow me down. Only when an analysis is truly one-time does Excel sometimes have an edge, but even there I really miss the adaptability of the terminal. The raw speed. The testability. The sheer maneuverability of it. The permanence.

Do you have some GUI for manipulating CSS with click&drag? Otherwise, isn't this use case handled by having an editor and a browser simultaneously open, and connected via live code reload. A web IDE can do this, but any other editor can do this too.

This approach does work in gamedev too, but it's not popular - mainly because languages supporting REPL-driven development on live images are not popular in this sector.

I agree though that there are tasks where GUIs are superior. But we're not talking about "regular" GUIs here, but domain-specific ones. Say, 3D editing. I can't imagine doing that from Emacs - the interface would heavily retard the feedback loop, in the same way GUIs slow you down when writing code. But then, Blender shows how one can apply Vim philosophy to 3D editing, resulting in a tool that embraces power users while still being GUI-driven.

I do a decent amount of CSS / HTML editing live in the chrome dev tools. I even sometimes move elements around by dragging them in the DOM tree UI. It can be a nice way of experimenting with UI design, as the feedback loop has less friction and can be much quicker, in some cases.

One workflow is to write out an initial sketch of the HTML structure, with little to no CSS. The first round of the styling is then done in the dev tools, tweaking until it seems ok, then copying those styles from the inspector stylesheet into my code and saving, and then iterating further as necessary.

Horrible ascii graphs look horrible, but they are arguably more functional in that you can navigate them with your keyboard.

Made me smile. This is a great analogy. Tactics vs strategy. You can become more efficient at low-level tasks by doing faster text editing. However, as you get into actual software engineering, the first time you need to do some semantic refactoring will wipe out any time you saved through low-level efficiency.

That applies to Java and C# only, where the language grammar is so simplified that you can be 99% confident semantic refactoring didn't screw your code up.

> You can become more efficient at low-level tasks by doing faster text editing.

It's not efficiency for efficiency's sake. It's for being able to code at the speed of thought, to tighten your feedback loop to the point where the act of writing & editing happens in your mind in larger syntactical units.

Also, for actual software engineering, nothing beats a pen and a piece of paper.

Sometimes I use pen and paper quite effectively, but between the slowness of writing and the difficulty of editing, I wouldn't describe it as ideal.

Some of us would say well-designed instead of simplified :-)

That's a longer topic. Having worked professionally both with Java (Eclipse, Netbeans, IntelliJ IDEA) and Common Lisp (Emacs + SLIME), I've experienced both sides of the coin. On the one hand, working with a language without a proper REPL and macros is painful to me. On the other hand, I frequently wish it was even possible to have semantic completion and automatic refactoring in Common Lisp, even at 10% of what you get for Java out of the box in an IDE...

With that, the only remaining thing in which IDEs are a better choice than vim or Emacs is debugging. I wish for decent and fully featured debugging TUIs.

https://code.visualstudio.com/api/extension-guides/debugger-...

I imagine Emacs, vim, and friends could implement their own frontends for this, much as has been happening with LSP.

And it turns out, Emacs and vim do implement their own frontends for this - [0], [1]. My wish just literally came true!

[0] - https://github.com/emacs-lsp/dap-mode

[1] - https://github.com/puremourning/vimspector

Here in spaghetti enterprise land it is. Quite often the biggest challenge to any given story is understanding the impact of a single line change on a code base.

And since we decided to split a single bowl of that spaghetti into nuget packages the more "primitive" tools like ctags are the best way to navigate the project, they don't care about pesky things like dll boundaries.

Isn't that a test coverage issue more than a navigation issue ?

Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage.

> Opening 3 files via keyboard shortcuts vs opening them by clicking on 3 different buttons won't solve spaghetti code and low test coverage.

It doesn't solve it, but it makes it quicker and easier to navigate, it's not just the shortcuts but the navigation stack (go to declaration, go to declaration, go to declaration, pop, pop, got to declaration, pop, pop, etc) that make it easy. Tmux and/or vim are also much better at multi-window editing than IDE's which is also handy.

Most navigation is done using keyboard shortcuts, but I can use the mouse to click around menus if I forget where something is.

Visual Assist X is terrible and extremely slow. Also, it is a clutch, showing one of the biggest weak points of Visual Studio.

I use it in a daily basis for more than 7 years, and I just hate it. VS is such a mixed box of feelings, it is so bad for most of it but then there is a very good debugger, arguably the only thing holding VS alive.

I would prefer to switch to a better text based IDE or even vscode and use windbg, if it wasn't for co-workers with Stockholm syndrome that can't see how bad their tools are.