Dirk's employer bought some software from a vendor, and the vendor promised that it was a cutting edge system, which was pushing the boundaries of technology. Digging through the API documentation, Dirk definitely found some unusual innovations, like the way it tracked log levels:

[FlagsAttribute]
public enum TraceEventType
{
    NoTracing = 0,
    Critical = 1,
    Error = 2,
    Warning = 4,
    Information = 8,
    Verbose = 16
}

Your boring old software treats log levels as, well, levels. A message exists on a level, you filter for a certain level, so if you only want Error messages, you won't see Debug messages, but if you Debug you'll also see Errors.

This cutting edge system lets you decide what message you want to see, because message levels are bitmasks. You want critical information? Look for 9. You want only critical warnings, whatever that may actually be? 5 it is. And does a 6 tell you that the warning was an error, or that there was an error outputting the warning?

And yes, most methods that involved logging let you log a message with any integer combination, and most that involved filtering logs let you filter with a bitmask. Unfortunately, not all of them did, and the behavior of "filter by bitmask" was inconsistent, as most of the logging engine assumed you wanted to filter by levels, so a filter of 17 might, in some cases, only show critical messages.

Such is the path of true pioneers: their brilliant idea is held back by systems that are entrenched in the "old" way of doing things. Or maybe someone just didn't really understand how log levels and enums were supposed to work and just made a bitmask by accident.

[Advertisement] Continuously monitor your servers for configuration changes, and report when there's configuration drift. Get started with Otter today!