Session-based Logging

To trouble-shoot software, logging of some kind is essential. But for most systems, it is simply not possible to log everything that happens. Many systems and logging frameworks let you limit the amount of data by giving a logging level (e.g. error, warning, info, debug) and by specifying where in the code logging should be done. An alternative way of limiting the data is to use session-based logging. You then get all data pertaining to a specific session, but nothing for any of the other sessions. Continue reading

Finding Bugs: Debugger versus Logging

One common reaction to my post on writing debuggable code was: you don’t need logging, just use a debugger. While there are cases where a debugger is the best option, there are many reasons why having proper logging in place is superior to using a debugger for trouble shooting. Continue reading

TDD, Unit Tests and the Passage of Time

Many programmers have a hard time writing good unit-tests for code that involves time. For example, how do you test time-outs, or periodic clean-up jobs? I have seen many tests that create elaborate set-ups with lots of dependencies, or introduce real time gaps, just to be able to test those parts. However, if you structure the code the right way, much of the complexity disappears. Here is an example of a technique that lets you test time-related code with ease. Continue reading

Automatically Include Revision in Log Statement

When there is a problem with your software, the first thing you usually ask for is a log showing what happened (provided you write debuggable code), and the version of the software that was running. But it is easy to have the revision of the software automatically added to the log. Continue reading

7 Ways More Methods Can Improve Your Program

A lot of code I come across consists of relatively few, but long, methods. The code does what it is supposed to do. However, it could be improved a lot. Refactoring to use more methods can produce better structured programs that are easier to understand, easier to modify, easier to test and easier to debug. Below are 7 reasons why using more methods can be a good idea.

Continue reading

LinkedIn – Good or Bad?

I have read a couple of blog posts about LinkedIn recently. “Is LinkedIn Cheating Employers and Job Seekers Alike?” is criticizing LinkedIn for charging job seekers to appear “at the top of the list” when applying for a job. “LinkedIn Spam (?) and Recruiters: A Guide for Geeks” has some good advice on how to interact with recruiters on LinkedIn. These among others made me ponder the question: Is LinkedIn good or bad? (and Betteridge’s law notwithstanding, the answer is not “No”). Here is my take: Continue reading

Great Programmers Write Debuggable Code

All programs need some form of logging built in to them, so we can observe what it is doing. This is especially important when things go wrong. One of the differences between a great programmer and a bad programmer is that a great programmer adds logging and tools that make it easy to debug the program when things fail.

When the program works as expected, there is often no difference in the quality of the logging. However, as soon as the program fails, or you get the wrong result, you can almost immediately tell the good programmers from the bad. Continue reading