5

I was in a job interview with a vp r&d today.

I would like to ask it here, even though it is, in my opinion, too broad as a question.

One of his questions went something like:

"How do you make sure your code works?"

This question struck me as a bit strange, so I explained how I debug (divide and conquer, debugger, prints, unit testing).

He then continued:

"What if the problem only comes once a day?"

I said I would use a log.

He then asked

"What would you put in the log?"

"How can you make sure that when you get the log, you would be able to find the problem quickly?"

I sat there quietly, not knowing the answer he was looking for.

The question seems over-broad to me, and I am sure with some specific context I would have been able to come up with something.

Maybe it's actually a viable question and I just have a knowledge gap, or I just don't get something…

My question to you:

Is there any standard methodology for logging?

What answer could he have been waiting to hear?

closed as too broad by amon, Telastyn, Doc Brown, 17 of 26, Robert Harvey Mar 27 at 20:20

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    @Gulzar: not every question has a home in the SE network. Reddit may be a better place. FWIW, I would guess the interviewer wanted to hear the words "stack trace". – Doc Brown Mar 27 at 19:48
  • 1
    @Gulzar actually it would work better if you just edited out the interview part. It's a touchy issue with us. The logging question is a valid one. – candied_orange Mar 27 at 19:48
  • 3
    @DocBrown none taken. But I do think knowing the critical principles behind designing a good logging system is very much on topic. Sorry if I'm just hearing the question I want to hear. I've spent a lot of time fixing poorly thought out and overly ambitious logging systems. – candied_orange Mar 27 at 19:55
  • 4
    @CandiedOrange I once got the question "How do you make sure your code works?" My answer: "I test it." They weren't impressed. – Robert Harvey Mar 27 at 20:21
  • 3
    @RobertHarvey 'I once got the question "How do you make sure your code works?" My answer: "I test it." They weren't impressed.' What were they looking for. More detail? What other answer could there be? – JimmyJames Mar 28 at 15:01
12

How do you make sure your logs are sufficient?

My 11th grade English teacher has the best answer for this question:

Know your audience.

Think about who will be reading this. What they will and wont know. Think about what they need.

When you log, log with intention. There should be a point to everything you capture. You should be thinking about the use cases your logs will be put to. You should have clear ideas here. Otherwise you give up and just log everything.

To much logging is worse than not enough. I've been on teams that couldn't control this and created beasts that filled up our largest hard drives every few days. Worse the torrent of data kept normal users from being able to figure out what was happening to the system.

When you log think about who you're logging for. They are your audience. Do not overwhelm them. Keep what you show them clear, brief and useful.

Conversely, insufficient logging is easy to fix. Add logging as you find you need it. This only works though if you are iteratively developing. That is, you write it, use it, learn from it, and rewrite it. Some people just call this testing.

For that to work you have to put yourself in the mind of who will use the log. This can be end users as well as maintenance programmers. Your log might inspire searches of the code base. It might inspire searches on google. Give them enough keywords that they can find appropriate results.

Also, it can be useful to know the state of the system. Sure give me a break point and a reproduceable error and I can learn that myself but I still hate seeing "File not found" with no mention of the expected file name. Give me the fully qualified name and I'll know where to put the file to fix this problem.

"How can you make sure that when you get the log, you would be able to find the problem quickly?"

Make sure you log something that can be used in a search. You don't have to dump a full stack trace for every log entry. Not everything you log is consumed by a programmer anyway. But what you log should be something someone could look up in something.

When logging an error, a stack trace might be appropriate but logging covers more than errors. Class and method name are sometimes enough, usually right next to the date-time stamp. Even without those you can still provide a way to find what created this log entry by ensuring use of a unique word or phrase that can be found by searching the code base. I've used this one plenty.

Pro tip: don't break up the searchable phrase by word wrapping it in the source code. People aren't going to know where to put "\n + " in their search string.

  • Great Pro tip. Never realized it really (though I have faced that problem myself when I was searching code from an exception message) – user7 Jul 3 at 3:39

Not the answer you're looking for? Browse other questions tagged or ask your own question.