It’s most likely they use tools like grep and find which easily work with any language, but yes, LSPs are significantly changing the usefulness of autocompletion.
This is very true, and built tooling around it. My largest codebase was 10mm lines of code written in a Mainframe language, that couldn’t leave the clients hardware; so we wrote some simple tooling to help with finding things, and basically built a map around things.
Whilst I still don’t use an editor that provides those sorts of things, I do use tools like ssadump or go guru to help give me the lay of the land
How do you know if somebody does not use a debugger/line numbers/syntax highlighting? They are going to tell you!
Seriously though, what is that? Trying to show how smart you are? I use the excellent debugging facilities of Intellij for java, python and js almost daily and would not want to miss them. I have debugged hairy classpath issues in datacenters on other continents with my IDE. It is a wonderful tool. The thing is though, that unlike Mr. Professor here I can’t do green field development, but have to work in big messy production code bases.
Seriously though, what is that? Trying to show how smart you are?
So here’s an example from personal experience. I program with extremely limited syntax highlighting. Everything is in black font, except for comments which are (a fairly bright, almost garish) green. It’s limited enough that I’ve had coworkers ask how I work without syntax highlighting, so I’ll claim to qualify as using “no syntax highlighting” :)
I have a not all that rare, but uncommon enough corneal disease. It reduces my visual acuity. The low contrast themes that seem to be perpetually in vogue (think Zenburn, Solarized, Gruvbox) can have elements that contrast so poorly with the background that I would need to crank the font up to a huge size to really see and read them. And if I don’t make the font uselessly big, I find myself working harder to read the thing someone tried to hint away from me with a low contrast color choice - talk about irony.
When I have attempted to yak-shave my way to a color scheme that I can see well, I’ve found that what it tells me doesn’t actually help me in any meaningful way: I don’t need to highlight “function”, I know I’m in a function because I trust my editor/style enforcer to set the right indentation, because I jumped to the tag, because I navigated by balanced expression - whatever. And because I’m an easily distracted person, the visual noise from a screen filled with colors denoting data types, control structures, function calls… it’s just too much cognitive load. So I turn it off – with the exception of comments, but that’s easy for my brain, “black is live, green is dead”.
I can’t defend the others, but that doesn’t mean they are indefensible. Of course, it’s also quite possible that those choices are ascetic cargo culting of the bad old days too.
I have a not all that rare, but uncommon enough corneal disease. It reduces my visual acuity.
This makes a lot of sense to adapt to a unique setup based on what works for you personally! A lot of “I don’t need syntax highlighting” talk feels more like “I don’t need this and neither should you” which comes across as a superiority complex on top of just not understanding how the typical visual cortex processes color.
I strongly agree with the low contrast color schemes, I can’t stand them either. I am not arguing that everyone should use any of the things I mentioned, I am just annoyed by people that try to show off by not using them and the article came across like that. To each their own.
I’ll use an IDE when it doesn’t crash within five minutes of me using it.
Seriously, every couple of years, I attempt to use an IDE, and without fail (starting from the late 80s mind you) I have not had one that did crash on me. And I wasn’t trying to load millions of lines of code into the thing—no, generally, just a single simple file and in five minutes, poof—there goes the IDE down in flames and forget it, I’m not wasting my time. I move back to my previous editor (back in the 80s to mid-90s that was PE from IBM, and from the mid-90s to today it’s joe because I now work mostly in Unix). They work. I don’t need an IDE per language, nor do I need a few gigabytes just to run the environment and by now, it doesn’t get in my way of editing.
As for debugging, I can get by without one, and since I tend to play around with languages from time to time, a debugger might not even exist for the language I’m using. And oh, hey! At work I too have to deal with a big, messy production code base spread across three languages!
Sorry, but programmers who have to use an IDE annoy me. Get off my lawn!
Sorry, I use the stock installation, no customizations. And I think I use three different versions (different computers) but I don’t recall for sure since all the versions I have work the same.
I agree that IDEs are very useful. But they’re also very slow. I have a license for IntelliJ IDEA via my university and have been very impressed with it. But it takes a non-trivial time to start even on my rather powerful desktop PC. And when I program on UNIX, I usually use hardware from the early 2000s. My favorite editor is (n)vi. On Windows, I usually use Notepad2.
Would I like the tons of useful features that IDEs provide? Sure. But if I have to choose between useful features and low latency, I’ll personally choose low latency. I find I get by pretty well without the features. Vi’s ! and | commands are able to make up for much of the lost functionality.
Not to mention the immense, confusing complexity of the IntelliJ GUI…
But it takes a non-trivial time to start even on my rather powerful desktop PC.
Sure, but an IDE is meant to be started once a day (or kept running all the time) It is the tool you are going to spend all day in, so I think it is fine if it takes a bit to start.
I program on UNIX, I usually use hardware from the early 2000s.
Luckily my employer gives me hardware that is less than 15+ years old..
My favorite editor is (n)vi.
I prefer more than one level of undo tbh. vim it is for me.
Not to mention the immense, confusing complexity of the IntelliJ GUI…
Any expert tool will be complex. A 3D modeling, CAD or photo editing tool will not be simple and obvous either.
I prefer more than one level of undo tbh. vim it is for me.
Most vi implementations have multiple undo. Unlike Vim, however, most don’t have the Ctrl-R binding. Instead, you press . (period) to continue undoing, then u again to undo the last undo, then . to undo the previous undo, and so on.
Any expert tool will be complex. A 3D modeling, CAD or photo editing tool will not be simple and obvous either.
Eh, I think Photoshop has a pretty good interface, despite being an expert tool. For the most part. I’m quite comfortable in it despite knowing very little about it.
Yeah, I mean that Vim uses uu for “undo two changes” and ^R^R for “undo two undos”, whereas many other vi implementations use u. for both (depending on which “direction” you’re currently going). uu is “undo one change and then undo the undo”, which makes people think that vi doesn’t have multiple undo.
well, then scratch the photo editor from the list. My point still stands.
Or perhaps other companies could learn something from Adobe :-)
In any case, I agree as others have noted that this whole discussion really is about employed programmers vs people who program their own stuff.
Or … different people work in different domains and benefit from different approaches? I’ve spent a lot of years debugging interactions between systems where logging, tracing, pcap, and other log-oriented tools have been more useful to me than debuggers. I’ve also spent lots of time debugging customer reported problems in on-premise installations that I don’t have access to - so robust logging becomes a supportability requirement.
this person codes with a tooth pick and tweezers and is probably orders of magnitude more productive than me
Maybe? I wouldn’t confuse asceticism for skill, or a confidently written narrative for authority or productivity.
I think of myself as having a fair amount of programming experience, and I can’t imagine fixing understanding problems without debugging and instrumentation tools. I don’t buy the argument to authority the author makes about debuggers and the outsize personalities that have said they don’t use them.
I also can’t imagine writing Rust without using rust-analyzer for completion. It’s just nice and I don’t understand the value in avoiding it.
Don’t let exuberant manifestos diminish your own drive!
I sometimes wonder if the ascetics are actually more numerous or if they’re just more likely to write up their preferred tool set than the scads of “cold dark matter programmers” who like me will take every bit of help they can get thank-you-very-much including code completion, IDEs, and debuggers, and anything else that will help me visualize and clarify my understanding of complex code.
I sometimes wonder if the ascetics are actually more numerous or if they’re just more likely to write up their preferred tool set
Mostly the latter. Whenever you have this feeling, of being out-of-touch with the world around you, don’t hesitate to look at statistics that show what developers at large actually use. The 2019 Stack Overflow Survey shows that the most popular editor, by far, is VSCode. Moreover IDEs occupy 50% of the top-10 most popular editors. IDEs are very popular and I have no doubt debuggers are as well.
From my understanding of the article it reads like the author is mainly working with code solely authored by himself. Things start to look differently if you work with code bases that were authored by many developers and have a low test coverage, then a good debugger can save you some headaches. Java is not my favorite language by far, but the debugger integration in Intellij is just excellent and really helps to understand convoluted code. Also, you do not have to read any manual to start debugging Java code with most IDEs and that’s why their adoption is almost 100% in the Java world. I guess if we had such good debugger integration for other languages than more developers would use them.
I used to rely heavily on a debugger, but golang changed that for me. A fast automated test and some well placed printf’s are generally good enough to diagnose the issue.
That may be true for some kinds of issues. Sometimes, though, you can’t easily add more print statements or the problem is not easily reproducible. Sometimes the debugging modifications actually change the behaviour of the program enough that you don’t experience the issue; e.g., by changing the timing around a race condition.
Debuggers are not all classical single-stepping affairs, either. Sometimes they are post mortem debuggers, inspecting core dumps. Sometimes they are tracing tools like DTrace, which is effectively a sort of programmatic debugger.
Most debuggers are really bad at helping you find a bug when the failure is distant from the cause. If I hit an assert then it’s easy to fire up a debugger and go and look at the state and understand what’s wrong, but going from that to the place that introduced the incorrect state is often much harder. A tracing framework, even something ad-hoc like printf + grep, makes it easier to see what happened in the past that cause a failure now.
Ideally, you want time-travel debugging with watchpoints, but that generally works only for self-contained tests that don’t do I/O. Windbg is great if you have such a test (single-threaded, no network or user input, crashes at the end, root cause is somewhere much earlier): you run it, poke the state to find the incorrect value in some object, set a watchpoint on that address, and then run time backwards to find the last store to that address.
That’s great. Logging definitely helps, but there are plenty of times where I don’t know where to place the logging because I don’t actually know what I’m looking for.
For example (Gonna use Python here because speak confidently about what you know, right? :) when I’m trying to debug why a decorator isn’t working right, if I’m doing something wrong with passing around the partials it’s gonna be awfully hard for me to properly place a print statement to figure that one out.
I suspect actual hours of experience or deliberate practice accrued plays in here as well. I don’t know how many years you’ve been programming. I’ve only really honest to god been working at practicing the craft of software development for about 5 years. I did 30 years of very simple procedural scripts before that but it’s not nearly the same thing.
I love the false dichotomy of “no IDEs, no debuggers, no code completion” vs. “pimp my IntelliJ to 11”. I’d argue that you need both. Programming has both strategical and tactical aspects and those affect your tools and setup. While I believe you should definitely get your strategical skills on point first, there is value in the tactical ones too.
Let’s start with strategy. This is the ability to find your way around a big code base, identify the key components, and reason about design and correctness. Here we want to make software do what we want instead of doing what is “right” because the tool told you so. Debuggers, language servers with code completion don’t help much at this stage. In addition projects on the innovation border usually don’t have those tools available. If you want to work on the cutting edge, you need to master the basics that work everywhere: Vim/Emacs, ctags, regexes, print debugging.
Tactics is where you shine at your current task. You or your lead has given you a job that needs to be done quickly. You know what you have to do and want to do it with minimum hassle. There is nothing wrong in opening up that IDE, navigating to the file you’ve opened hundreds of times already, and changing the code there, while the language server guides your fingers and protects you from errors. I recently joined a Go team and adopted a new VS Code based workflow. Barring some annoyances with the Vim plugin there, it’s been great so far.
People that are good at the strategy part can be incredibly slow at mundane tasks, yet be productive overall simply because they know what needs to be done and avoid unnecessary rework. They should still learn the new tools both because they can get better with them and because they can improve them. On the other side of the spectrum IDE masters can be lightning fast at certain type of tasks and completely fail at others. Just remember the last time you spent a day in the debugger or mindlessly . after service/manager/util variable names and scrolling the list of methods. My approach is to go for the strategy part with the right 20% of tactics that take me 80% on the way to IDE mastery.
I do not use a debugger … Stepping through code is a slow, tiring process.
I think this says more about the state of debuggers than anything else.
I never use code completion. If the editor provides it, I disable it.
I agree that code completion that creates a pop-up that blocks other code on your screen and continuously updates in real time is annoying, and I never have that enabled; I find it to be incredibly distracting. However, simply having the option to auto-complete by pressing (for instance) the tab key is very useful, and I find it strange that you’d want to go out of your way to disable that, especially when working in a large project.
However, I often spend a lot of time reading a project’s documentation. If the documentation is missing, I might read the source code instead.
The whole point of features like tab completion is to make this easier on the programmer, and to reduce cognitive load. Documentation is obviously very useful, but often times using other features like tab completion or LSP hovering can save a lot of time by cutting out the stuff you don’t need.
The whole point of features like tab completion is to make this easier on the programmer, and to reduce cognitive load. Documentation is obviously very useful, but often times using other features like tab completion or LSP hovering can save a lot of time by cutting out the stuff you don’t need.
This is precisely the right way to look at tab completion. That said, there are alternatives to it that make it possible to live without it. A well-written grep or ack command in the source directory can often be as useful, and occasionally even more useful.
The problem is that such a command is rarely tied into the editor by default. I think Plan 9’s plumbing system offers a very elegant solution by making it possible to perform actions on selected text based on the contents of the selection, regardless of editor support.
On UNIX, I have a Perl script called dwim, which does approximately the same thing. If I select (in any program) a function call like function(arg, ... and press Alt-Q, dwim runs the equivalent of
$ cd source-dir
$ grep -n '^function(' *.c | head -1
sourcefile.c:34:function(int argument) {
$ xterm -e vi +34 sourcefile.c
… opening vi at the definition of function in a new xterm window.
The value of autocompletion is, I suspect, tied very closely to the quality of the API that you’re working with. If your naming conventions are such that you can always make a pretty good guess about the name of the API, then autocompletion is fantastic. If they are inconsistent then you probably need to go and look things up in the docs for any API that you haven’t used recently.
Having worked on large code bases (500k+ loc) with a lot of models (20-30) I can’t imagine life with a good quality language server…
I’m not sure if I envy the author or if I’m afraid of them.
It’s most likely they use tools like grep and find which easily work with any language, but yes, LSPs are significantly changing the usefulness of autocompletion.
This is very true, and built tooling around it. My largest codebase was 10mm lines of code written in a Mainframe language, that couldn’t leave the clients hardware; so we wrote some simple tooling to help with finding things, and basically built a map around things.
Whilst I still don’t use an editor that provides those sorts of things, I do use tools like ssadump or
go guruto help give me the lay of the landHaving worked on small code bases I can’t imagine how much I’d have to be offered to agree to work on a codebase over 100kloc.
How do you know if somebody does not use a debugger/line numbers/syntax highlighting? They are going to tell you!
Seriously though, what is that? Trying to show how smart you are? I use the excellent debugging facilities of Intellij for java, python and js almost daily and would not want to miss them. I have debugged hairy classpath issues in datacenters on other continents with my IDE. It is a wonderful tool. The thing is though, that unlike Mr. Professor here I can’t do green field development, but have to work in big messy production code bases.
Sorry, but this really annoys me.
So here’s an example from personal experience. I program with extremely limited syntax highlighting. Everything is in black font, except for comments which are (a fairly bright, almost garish) green. It’s limited enough that I’ve had coworkers ask how I work without syntax highlighting, so I’ll claim to qualify as using “no syntax highlighting” :)
I have a not all that rare, but uncommon enough corneal disease. It reduces my visual acuity. The low contrast themes that seem to be perpetually in vogue (think Zenburn, Solarized, Gruvbox) can have elements that contrast so poorly with the background that I would need to crank the font up to a huge size to really see and read them. And if I don’t make the font uselessly big, I find myself working harder to read the thing someone tried to hint away from me with a low contrast color choice - talk about irony.
When I have attempted to yak-shave my way to a color scheme that I can see well, I’ve found that what it tells me doesn’t actually help me in any meaningful way: I don’t need to highlight “function”, I know I’m in a function because I trust my editor/style enforcer to set the right indentation, because I jumped to the tag, because I navigated by balanced expression - whatever. And because I’m an easily distracted person, the visual noise from a screen filled with colors denoting data types, control structures, function calls… it’s just too much cognitive load. So I turn it off – with the exception of comments, but that’s easy for my brain, “black is live, green is dead”.
I can’t defend the others, but that doesn’t mean they are indefensible. Of course, it’s also quite possible that those choices are ascetic cargo culting of the bad old days too.
This makes a lot of sense to adapt to a unique setup based on what works for you personally! A lot of “I don’t need syntax highlighting” talk feels more like “I don’t need this and neither should you” which comes across as a superiority complex on top of just not understanding how the typical visual cortex processes color.
I strongly agree with the low contrast color schemes, I can’t stand them either. I am not arguing that everyone should use any of the things I mentioned, I am just annoyed by people that try to show off by not using them and the article came across like that. To each their own.
I’ll use an IDE when it doesn’t crash within five minutes of me using it.
Seriously, every couple of years, I attempt to use an IDE, and without fail (starting from the late 80s mind you) I have not had one that did crash on me. And I wasn’t trying to load millions of lines of code into the thing—no, generally, just a single simple file and in five minutes, poof—there goes the IDE down in flames and forget it, I’m not wasting my time. I move back to my previous editor (back in the 80s to mid-90s that was PE from IBM, and from the mid-90s to today it’s joe because I now work mostly in Unix). They work. I don’t need an IDE per language, nor do I need a few gigabytes just to run the environment and by now, it doesn’t get in my way of editing.
As for debugging, I can get by without one, and since I tend to play around with languages from time to time, a debugger might not even exist for the language I’m using. And oh, hey! At work I too have to deal with a big, messy production code base spread across three languages!
Sorry, but programmers who have to use an IDE annoy me. Get off my lawn!
Could you perhaps point me to a write up or a config/scripts repo with a good Joe setup? Just curious if I’m missing on something good here. :)
Sorry, I use the stock installation, no customizations. And I think I use three different versions (different computers) but I don’t recall for sure since all the versions I have work the same.
Thanks, now you got my interest :) I’m always on the lookout for tools that just work with their default config.
I agree that IDEs are very useful. But they’re also very slow. I have a license for IntelliJ IDEA via my university and have been very impressed with it. But it takes a non-trivial time to start even on my rather powerful desktop PC. And when I program on UNIX, I usually use hardware from the early 2000s. My favorite editor is (n)vi. On Windows, I usually use Notepad2.
Would I like the tons of useful features that IDEs provide? Sure. But if I have to choose between useful features and low latency, I’ll personally choose low latency. I find I get by pretty well without the features. Vi’s ! and | commands are able to make up for much of the lost functionality.
Not to mention the immense, confusing complexity of the IntelliJ GUI…
Sure, but an IDE is meant to be started once a day (or kept running all the time) It is the tool you are going to spend all day in, so I think it is fine if it takes a bit to start.
Luckily my employer gives me hardware that is less than 15+ years old..
I prefer more than one level of undo tbh. vim it is for me.
Any expert tool will be complex. A 3D modeling, CAD or photo editing tool will not be simple and obvous either.
Most vi implementations have multiple undo. Unlike Vim, however, most don’t have the Ctrl-R binding. Instead, you press . (period) to continue undoing, then u again to undo the last undo, then . to undo the previous undo, and so on.
Eh, I think Photoshop has a pretty good interface, despite being an expert tool. For the most part. I’m quite comfortable in it despite knowing very little about it.
Ctrl-R is redo, not multiple undos though: https://vimhelp.org/undo.txt.html#CTRL-R
well, then scratch the photo editor from the list. My point still stands.
Yeah, I mean that Vim uses uu for “undo two changes” and ^R^R for “undo two undos”, whereas many other vi implementations use u. for both (depending on which “direction” you’re currently going). uu is “undo one change and then undo the undo”, which makes people think that vi doesn’t have multiple undo.
Or perhaps other companies could learn something from Adobe :-)
In any case, I agree as others have noted that this whole discussion really is about employed programmers vs people who program their own stuff.
Or … different people work in different domains and benefit from different approaches? I’ve spent a lot of years debugging interactions between systems where logging, tracing, pcap, and other log-oriented tools have been more useful to me than debuggers. I’ve also spent lots of time debugging customer reported problems in on-premise installations that I don’t have access to - so robust logging becomes a supportability requirement.
People like the author kinda dive me nuts. I wish I could be so skilled:
In short, this person codes with a tooth pick and tweezers and is probably orders of magnitude more productive than me :)
Maybe? I wouldn’t confuse asceticism for skill, or a confidently written narrative for authority or productivity.
I think of myself as having a fair amount of programming experience, and I can’t imagine fixing understanding problems without debugging and instrumentation tools. I don’t buy the argument to authority the author makes about debuggers and the outsize personalities that have said they don’t use them.
I also can’t imagine writing Rust without using rust-analyzer for completion. It’s just nice and I don’t understand the value in avoiding it.
Don’t let exuberant manifestos diminish your own drive!
Thanks very much that’s super refreshing to hear.
I sometimes wonder if the ascetics are actually more numerous or if they’re just more likely to write up their preferred tool set than the scads of “cold dark matter programmers” who like me will take every bit of help they can get thank-you-very-much including code completion, IDEs, and debuggers, and anything else that will help me visualize and clarify my understanding of complex code.
Mostly the latter. Whenever you have this feeling, of being out-of-touch with the world around you, don’t hesitate to look at statistics that show what developers at large actually use. The 2019 Stack Overflow Survey shows that the most popular editor, by far, is VSCode. Moreover IDEs occupy 50% of the top-10 most popular editors. IDEs are very popular and I have no doubt debuggers are as well.
From my understanding of the article it reads like the author is mainly working with code solely authored by himself. Things start to look differently if you work with code bases that were authored by many developers and have a low test coverage, then a good debugger can save you some headaches. Java is not my favorite language by far, but the debugger integration in Intellij is just excellent and really helps to understand convoluted code. Also, you do not have to read any manual to start debugging Java code with most IDEs and that’s why their adoption is almost 100% in the Java world. I guess if we had such good debugger integration for other languages than more developers would use them.
Totally agree.
My day job is for a MegaCorp and I mostly work on legacy Python code bases with many objects and thousands of lines of code.
I used to rely heavily on a debugger, but golang changed that for me. A fast automated test and some well placed printf’s are generally good enough to diagnose the issue.
That may be true for some kinds of issues. Sometimes, though, you can’t easily add more print statements or the problem is not easily reproducible. Sometimes the debugging modifications actually change the behaviour of the program enough that you don’t experience the issue; e.g., by changing the timing around a race condition.
Debuggers are not all classical single-stepping affairs, either. Sometimes they are post mortem debuggers, inspecting core dumps. Sometimes they are tracing tools like DTrace, which is effectively a sort of programmatic debugger.
Most debuggers are really bad at helping you find a bug when the failure is distant from the cause. If I hit an assert then it’s easy to fire up a debugger and go and look at the state and understand what’s wrong, but going from that to the place that introduced the incorrect state is often much harder. A tracing framework, even something ad-hoc like printf + grep, makes it easier to see what happened in the past that cause a failure now.
Ideally, you want time-travel debugging with watchpoints, but that generally works only for self-contained tests that don’t do I/O. Windbg is great if you have such a test (single-threaded, no network or user input, crashes at the end, root cause is somewhere much earlier): you run it, poke the state to find the incorrect value in some object, set a watchpoint on that address, and then run time backwards to find the last store to that address.
That’s great. Logging definitely helps, but there are plenty of times where I don’t know where to place the logging because I don’t actually know what I’m looking for.
For example (Gonna use Python here because speak confidently about what you know, right? :) when I’m trying to debug why a decorator isn’t working right, if I’m doing something wrong with passing around the partials it’s gonna be awfully hard for me to properly place a print statement to figure that one out.
I suspect actual hours of experience or deliberate practice accrued plays in here as well. I don’t know how many years you’ve been programming. I’ve only really honest to god been working at practicing the craft of software development for about 5 years. I did 30 years of very simple procedural scripts before that but it’s not nearly the same thing.
I love the false dichotomy of “no IDEs, no debuggers, no code completion” vs. “pimp my IntelliJ to 11”. I’d argue that you need both. Programming has both strategical and tactical aspects and those affect your tools and setup. While I believe you should definitely get your strategical skills on point first, there is value in the tactical ones too.
Let’s start with strategy. This is the ability to find your way around a big code base, identify the key components, and reason about design and correctness. Here we want to make software do what we want instead of doing what is “right” because the tool told you so. Debuggers, language servers with code completion don’t help much at this stage. In addition projects on the innovation border usually don’t have those tools available. If you want to work on the cutting edge, you need to master the basics that work everywhere: Vim/Emacs, ctags, regexes, print debugging.
Tactics is where you shine at your current task. You or your lead has given you a job that needs to be done quickly. You know what you have to do and want to do it with minimum hassle. There is nothing wrong in opening up that IDE, navigating to the file you’ve opened hundreds of times already, and changing the code there, while the language server guides your fingers and protects you from errors. I recently joined a Go team and adopted a new VS Code based workflow. Barring some annoyances with the Vim plugin there, it’s been great so far.
People that are good at the strategy part can be incredibly slow at mundane tasks, yet be productive overall simply because they know what needs to be done and avoid unnecessary rework. They should still learn the new tools both because they can get better with them and because they can improve them. On the other side of the spectrum IDE masters can be lightning fast at certain type of tasks and completely fail at others. Just remember the last time you spent a day in the debugger or mindlessly
.afterservice/manager/utilvariable names and scrolling the list of methods. My approach is to go for the strategy part with the right 20% of tactics that take me 80% on the way to IDE mastery.I think this says more about the state of debuggers than anything else.
I agree that code completion that creates a pop-up that blocks other code on your screen and continuously updates in real time is annoying, and I never have that enabled; I find it to be incredibly distracting. However, simply having the option to auto-complete by pressing (for instance) the tab key is very useful, and I find it strange that you’d want to go out of your way to disable that, especially when working in a large project.
The whole point of features like tab completion is to make this easier on the programmer, and to reduce cognitive load. Documentation is obviously very useful, but often times using other features like tab completion or LSP hovering can save a lot of time by cutting out the stuff you don’t need.
This is precisely the right way to look at tab completion. That said, there are alternatives to it that make it possible to live without it. A well-written grep or ack command in the source directory can often be as useful, and occasionally even more useful.
The problem is that such a command is rarely tied into the editor by default. I think Plan 9’s plumbing system offers a very elegant solution by making it possible to perform actions on selected text based on the contents of the selection, regardless of editor support.
On UNIX, I have a Perl script called dwim, which does approximately the same thing. If I select (in any program) a function call like
function(arg, ...and press Alt-Q, dwim runs the equivalent of… opening vi at the definition of function in a new xterm window.
The value of autocompletion is, I suspect, tied very closely to the quality of the API that you’re working with. If your naming conventions are such that you can always make a pretty good guess about the name of the API, then autocompletion is fantastic. If they are inconsistent then you probably need to go and look things up in the docs for any API that you haven’t used recently.
Thought I would post my own programming setup: https://gavinhoward.com/2020/12/my-development-environment-and-how-i-got-there/