[0x008]

Yeah I always wonder who these people are for which the editor is a bottleneck and how they work or what they work on. 90% of my time is spent debugging, understanding legacy code and drawing trees or writing pseudo code on my notepad. The actual time I type stuff into an editor is like 10minutes per day.

[roveo]

It's not about typing speed, it's about reducing mental load. When vim (or any editor for that matter) becomes second nature, you stop thinking about how you're editing the text, it just happens, like moving a part of you body. And then you can better concentrate on the problem at hand, which matters even more for solving novel problems/algos/architecture.

Same with touch typing: you don't need the speed, you need to eliminate the distraction of looking for a key.

Even when you're debugging/reading code, you're still making small changes: adding a print here, removing an argument there. I read somewhere that the main insight behind creating vim was that you spend more time moving your cursor and parts of code around than you spend writing new code. So that's what it optimises for.

[0x008]

Well I guess then it is different for each person what induces mental load. I for one sometimes just use my mouse to click and copy things or insert a character here and there or to go to some other line. Why? Because I can think about the next problem while I do that because I don’t have to think about any keystrokes.

[enriquto]

Just a single data point, but as a matter of principle I never use a debugger. Any time spend inside the debugger is 100% lost and useless to other people.

To study a code, it is best to copy it, run it, and keep adding assertions, comments, and logging infrastructure. Besides helping you to understand what the code does, all these changes are useful for other people who may need to understand the code in the future.

[0x008]

I feel like you and I work on very different types of code. If I tried to do what you suggest, I would be adding comments and assertions for days. Also I follow the school of thought that code should be self explanatory and comments should make statements about the trade offs you made from a business or systems design standpoint, not explain what the code is doing.

I feel like the approach you are taking is impossible with the I inherent complexity of the systems I work with and for me the only chance is to follow a trail of a data point through the system like in Hansel and Gretel and see what effects it has on certain objects in a debugger.

I don’t use the debugger to understand code, I use it to find out why my tests are failing, where in the system the faulty data point comes from and if the values in each step behave in a way that is acceptable.

The second big use case for me is exploring in the debugger REPL what would happen if I change value x to y or test lines of code before I put them in the unit test, because I can only run the test a limited number of times per day since it takes like 5 minutes to boot up. I have to be very careful not to waste computer cycles.

[philipswood]

Styles differ, but for me using actual runtime behaviour to guide my reading of a code base is often a LOT faster, and your approach ends up boiling the ocean. The way for this activity to benefit others is to use your improved understanding to refactor/simplify the code you are working with to make it clearer for someone else to understand at first reading. Personally for me many systems only clicked after seeimg the, from the inside.

[barbs]

I don't understand - how is using a debugger a waste of time?

I don't often use a debugger, but they have proven to be useful in a lot of cases.

[DavidWoof]

Not OP, and I think never using a debugger is silly, but IMO if I need a debugger to figure out a problem then I'm missing either sufficient unit tests or sufficient logging, and spending my time on that rather than in the debugger will aid future devs as well.

I do think the write/debug/edit cycle is a very, very slow way to program, and I have to admit I'm suspicious when somebody tells me they spend 90% their time in the debugger (but a lot of this is dependent on type of work).

[0x008]

I work with big data and have to solve a lot of problems in integration or by debugging again at the a live Systeme, which you simply cannot reproduce in local unit tests.

And sometimes running a single test takes like 7 minutes so I have to reduce the times I run it to save time which is why I tend to fix code in an interactive REPL in the debugger.

[enriquto]

> I don't understand - how is using a debugger a waste of time?

The debugger may help you understand, at some moment in time, what an unclear piece of code does. When you revisit this piece of code later, or another person finds it, your first experience with the debugger is not remembered, thus lost. This is what I meant. On the contrary, if you clarify the code and make it easier to instrumentate (by adding assertions, tests, comments, logging, etc.), it helps you right now, you in the future, and everybody else at any time. Furthermore, as a result of these efforts you will create a code that is clearer and nobody will ever need to debug to understand what it does.

The only case where debugging makes sense to me is for cases that are difficult to add instrumentation to, like assembly programming, where it will be somewhat inevitable that you need to step through the instructions to see what's going on.

[detaro]

If code had instrumentation for every variable someone ever looked at with a debugger it would be unreadable because it'd be buried under instrumentation code, configuration to only enable instrumentation when needed, ... That's not to say instrumentation/logging/... aren't useful tools that can be more appropriate, but "never use a debugger" seems like a misguided dogma that seems surprisingly common. Part of the strength of a debugger is being able to look at all the things to find the ones worth a closer look, without having to add instrumentation or logging to every single one.

> by adding [...] comments, [...] etc

If you need a debugger, those are not there or not good enough, and you can only meaningfully add them after you understand what's happening.

(EDIT: there is also a wide variety in what people count as a "debugger" further muddying the debate)

[horsawlarway]

I feel like your understanding of a debugger is very limited.

To me - A debugger is the instrumentation you're talking about, but created by the language/runtime developers instead of having to be remade by you, poorly, for each new project.

A good watch statement is a hell of a lot more useful than an assert - even though they both try to do the same thing.

Not even touching the places where a debugger solves a problem you simply can't touch with instrumentation after the fact (crash dumps immediately come to mind...).

And neither of them are (in any sense) a replacement for writing a test after you solve the problem, or adding comments so the next developer has context on the why of that piece of code.

[enriquto]

First of all, I agree 100% that a debugger is an indispensable tool. I just say that it is often not necessary or useful when you are writing new code or reading old code that you are supposed to edit. Your example about interpreting a crash dump is definitive.

I've had a fair share of using debuggers in my life, and I ended with my anti-debugging stance as a matter of fatigue, and a sense of time lost. I know what debuggers are capable of, especially regarding data visualization. But for your example of the variable watch, what are you going to watch, precisely? That the value of a variable is always positive? That it increases one by one? All these things are better served by assertions. What kind of information can be inferred by just looking at the evolution of values of a variable that is not easily formalized as an assert or a simple in-code test?

[antoineMoPa]

It's weird to write the test after solving the problem. You should write the test before solving the problem to get the most benefit. You can then edit + compile + run test until the test pass and normally this is shorter than the "edit+compile+start app+replicate bug manually in application+debug" loop.

[horsawlarway]

Depends on the bug - most times I'm breaking out the debugger it's because I have a timing/race condition somewhere, or an unexpected interaction with some other service/component.

Basically - the debugger is not a tool I use if the issue is clear and reproducible.

Those are also issues where it can be hard to write a correct test up front. Typically - tests are passing already, but we're seeing intermittant problems somewhere. Once we understand the interaction and the root of the problem, it's much easier to put a test in place.