Learning about a command-line debugger and command-line profiling tools would be helpful for those that find themselves in the past. IDEA and Visual Studio have had these things integrated for decades. I find the likelihood of knowing how to use a debugger or profiler is inversely proportional to the amount of time someone spends in the terminal.
It's astonishing how many developers rely on logging/print statements for debugging. The learning curve of using a tool like PDB or GDB is just too steep for most people.
Logging and print statements are phenomenally useful debugging aids. I think people get too caught up in what a debugger can give them and forget how much value you can get out of logging as well.
I'm perfectly happy to fire up LLDB and step through a program, but my go-to first step is frequently to add logs, and one of the reasons is that it's often just plain faster. It's kinda like the binary search of debugging: Sure, I could fire up the debugger and step through the long, complicated, probably multi-threaded algorithm... or I could add some log statements, reproduce, and rapidly narrow down exactly where I should spend my time in the debugger.
If you've got a project with a particularly painful compile time for simple changes (which seems like a whole different issue...) or an issue where setting up a reproduction environment is difficult, then sure, fire up your debugger and set up your breakpoints appropriately. But I think debugging via logging gets a bad rap when it's frequently a completely rational first step.
Logging is also less likely to disturb the rest of the program, in my experience (JS). If I want to figure out in what order a set of things executes, I could just add some `console.log('hello')`, `console.log('helloooo')`, `console.log('does this even get called?')`, etc's around and see how they get spat out, or I could add a bunch of breakpoints, mess with the ordering of the event loop, and spend a bunch of extra time manually stepping around.
> It's astonishing how many developers rely on logging/print statements for debugging.
One reason is that you don't switch contexts if you insert a print statement in your code. I personally find that to be the least distracting way to debug.
I’ve tried using GDB and respect those who can, but when I am debugging my short term memory is generally full trying to understand the program code and trying to remember GDB commands clobbers that.
In something like VSCode (/any other IDE) you can just hit a keybinding or click the little button just to the left of the line to add a breakpoint; all the runtime info is shown in the sidebar and the debug console is shown where your terminal normally is; and the process to run is often the same as the process to debug. So context switching isn't as big of a deal. But still, print statements definitely have their place.
> It's astonishing how many developers rely on logging/print statements for debugging. The learning curve of using a tool like PDB or GDB is just too steep for most people.
On the other hand, since I can’t hook up a debugger to production, it’s also very useful to be able to understand my applications log output (especially tracing/debug statements) to triage the situation as quickly as possible.
Also any time I’m debugging USB or Bluetooth LE protocols, I’m relying on some kind of Wiretrace-like packet logger.
Debuggers have their place but they aren’t the end-all be-all of debugging.
> While reading the log4j manual, I came across this excellent quote from Brian W. Kernighan and Rob Pike’s “The Practice of Programming”:
>> As personal choice, we tend not to use debuggers beyond getting a stack trace or the value of a variable or two. One reason is that it is easy to get lost in details of complicated data structures and control flow; we find stepping through a program less productive than thinking harder and adding output statements and self-checking code at critical places. Clicking over statements takes longer than scanning the output of judiciously-placed displays. It takes less time to decide where to put print statements than to single-step to the critical section of code, even assuming we know where that is. More important, debugging statements stay with the program; debugging sessions are transient.
The browser dev tools of various browsers are debuggers and are very widely used - I'd guess completely independently of amount of time spent in a terminal.
Other factors, post-C, are probably things lots of languages don't have good debuggers or good debuggers take a while to materialize, debuggers are less necessary in managed-runtime languages, etc.
You just type "binding.pry" wherever you'd like to stop the application and in your terminal, it will open a Ruby shell where you can access the program state at that point in your code.
Testing and debugging is still a weak spot for me.
I did a bit of dorking around with web development on my own, decided to change careers, needless to say the boot camp didn't cover any of that and the 3 dev company I ended up with we're still trying to wrangle together good practices and pull old code into the future to the point that we're not doing nearly as much testing as we should... so I'm left to my own devices.
Even my usual web resources don't really cover much in the way of JavaScript / Node debugging outside "here is how you set something up ... k bye!".
The quality of debuggers varies hugely, especially since different languages support different debugging features (e.g., conditions vs exceptions vs neither). Logging works pretty much the same everywhere.
I have never used a language that doesn't support visual debugging from the editor except maybe embedded c. Considering the complexity of "logging frameworks", logging is not always as easy as it may sound.
I take logging in the general sense to mean “print”, which is pretty easy.
I’ve used lots of languages without usable (visual) debuggers. I was probably programming for 10 years before I saw a debugger that didn’t crash the OS half the time it was invoked.
It's astonishing how many developers rely on logging/print statements for debugging. The learning curve of using a tool like PDB or GDB is just too steep for most people.