i don’t “believe” in logs, generally.
what i mean is, for developers, logs should be seen strictly as a story for ops, not a development tool. i understand why ops needs to see logs. ops is a customer just like any other, and what they need, we can supply. but i see far too many developers use the log all day long during development.
everyone from time to time does “print” debugging, of course. no technique on earth can entirely supplant it, cuz geekery is actually hard. many developers, though, use a log as a permanent debug printer, and that’s a terrible way to live.
under normal development, your program isn’t doing “bad things” except in the new area you’re working in.
i often speak of two modes: coding-on-target, coding-on-experiment. normal development is always a mix of these.
first, cuz i generally have tests when i’m coding-on-target. the tests are quite good at telling me what just happened.
second, cuz i’m working in a very small scope. i don’t need a log cuz the scope is too small for logging info to even matter, unless, of course, i’m not using a small scope, in which case i’m screwing up, and i don’t need a log to tell me that.
when i’m not coding-on-experiment, all bets are off, of course. i may or may not have tests. i may or may not be running the whole app. but even then, i don’t want to use the log. why? cuz the log is full of noise. full of it. it tells you 10,000 things more than you wish.
have you ever turned, say, a Spring-based app’s log to ‘debug’ to look at something? hope you’ve got a lot of time and very good eyesight.
so, no. as a general rule, when i need to print-debug, and as i say, everyone needs to from time to time, i use print, not a log.
in IDE’s that put the log output in the program window, like eclipse, i turn off the log. if you’re using the log every day, you’re working testlessly, or you’re shipping too many bugs, or you don’t yet know how to structure code.
my advice to noobs: turn off the log and find another way to tell what’s going on. it will be hard for a while, so take care of yourself, but the long-game answer to not knowing what’s going on is never “tell me everything that is going on”.
the long-game answer involves a lot of behaviors that, once learned, will make you far more skilled as a developer.
what skills? well, lemme take a few shots. i’ll prolly under-describe, but these will give you clues, anyway.
hopefully that will give you some ideas.
start where? start by turning off your log. start hating print-debugging.