Logging Beats Remote Debugging
Key Points
- The speaker’s habit of using source‑level IDE debuggers for remote server code proved inefficient, revealing that PC‑style debugging doesn’t scale to production environments.
- A veteran server developer advised replacing interactive debugging with comprehensive logging, emphasizing that “logging is king” for both development and production troubleshooting.
- Effective logs must be high‑quality, capturing full parameter values, state information, and detailed exception data to enable rapid issue isolation without stepping through code.
- Incorporating assert statements to validate expected input and output states further enhances debuggability, leading to the conclusion that source‑level debugging should be abandoned in favor of well‑instrumented, log‑driven code.
Full Transcript
# Logging Beats Remote Debugging **Source:** [https://www.youtube.com/watch?v=-lqMeBPtbKc](https://www.youtube.com/watch?v=-lqMeBPtbKc) **Duration:** 00:03:32 ## Summary - The speaker’s habit of using source‑level IDE debuggers for remote server code proved inefficient, revealing that PC‑style debugging doesn’t scale to production environments. - A veteran server developer advised replacing interactive debugging with comprehensive logging, emphasizing that “logging is king” for both development and production troubleshooting. - Effective logs must be high‑quality, capturing full parameter values, state information, and detailed exception data to enable rapid issue isolation without stepping through code. - Incorporating assert statements to validate expected input and output states further enhances debuggability, leading to the conclusion that source‑level debugging should be abandoned in favor of well‑instrumented, log‑driven code. ## Sections - [00:00:00](https://www.youtube.com/watch?v=-lqMeBPtbKc&t=0s) **From IDE Debugging to Logging** - After moving from PC to server-side development, the speaker discovered that remote source-level debugging is impractical and that relying on robust logging is essential for diagnosing production issues. ## Full Transcript
welcome to Lessons Learned a series
where we share our biggest mistakes so
you don't make the same ones today's
lessons come from my time transitioning
from PC development to server side
development
so I was asked to debug a problem on
server side
after having done many years doing PC
development
and in PC development when I would do
debugging I would typically connect
directly to
the local PC and use an IDE Source level
debugger
and when I started doing
server-side programming I carried that
same habit across where I would connect
to a remote server with a debugger
Source level and try and solve a problem
but it caused me a lot of grief it
turned out it was really ineffective and
ultimately
it was my debug approach that needed to
change
and what convinced me to do that is one
of the developers who'd been doing
server side programming for most of his
career pulled me aside and said your
approach simply doesn't work it doesn't
scale and it's not very realistic for a
production environment instead you need
to do logging
yeah
in fact he argued logging is keying is
King you simply need to always use that
and don't even waste your time with
Source level debuggers now first I'm
thinking that's ridiculous I mean that's
the whole purpose of having an IDE is
being able to save time being able to
make a quick change and see the result
Etc
but he argued that having one way of
solving problems for development and
another way for production is really not
very efficient you should use the same
skills the same tools all the time
and then he argued that for code to be
debuggable it must have several things
of course what I just mentioned it
should have logs
and those logs need to be really high
quality logs not just an error occurred
but it needs to include all the
parameters and all the state would be
necessary to track down the problem and
especially for exceptions
for exception code you should throw up
not just the error but also what was the
state of all the parameters that were
associated with that
and along the same line
you want to have assert statements in
the beginning and end of your code which
asserts expected States and parameters
so you can debug that much more quickly
that way you can pull the logs and
examine the logs and not spend time
transitioning between an IDE and code
and logs for a production environment
in fact he would argue you should just
abandon Source level debug
it took me a long time to be convinced
that was in fact true but over time I
learned that having quality logs and
making code that is made to be debugged
is really the key to being a developer
that can solve problems more quickly and
have developed skills that apply not
just to development but also for
diagnosing problem in production