Level-up your logs

Powerful application logging in just a few lines of code. Take charge of your data and gain insights into what your users are doing.

Tag: meta

Why LogDebug Exists, and Other Tales

I’ve been a professional software engineer for nearly 15 years, and in every major product I’ve built, my process has remained fairly consistent. After setting up my development environment and spinning up a new project inside version control, I usually start an iterative development process that involves writing a feature littered with debugging log statements and adding lines of code slowly as I chug forward. Once I’m happy that the feature works as intended, I go through the code and delete most of the debugging print statements. I always end up leaving a few important log messages in, but often comment out those lines of code so that my development console isn’t cluttered when I move to the next feature.

It ends up looking something like this:

var app = require('express');
var router = require('express').Router();
router.get('/', function(res, req, next) {
	console.log('New request received at ' + req.url);
	return res.json({ success: true });
app.use('/api', router);
console.log('Starting server on port 8000');

It doesn’t matter what programming language I’m using or what style of project I’m working on, this workflow has been a constant friend throughout my professional career. I love rapid, iterative development with results visibly printed at every step along the way.

As a government contractor, most of the projects I’ve worked on had a development cycle of less than half a year, so I’ve settled with whatever methods each language provided, whether that’s NodeJS’s console.log() or Unity3d’s Debug.Log().¬†On the few occasions that I’ve worked on longer, more in-depth products, we always seemed to eventually end up with a robust logging framework.

One memorable position early in my career had me working for five years on a mature product that had an extremely robust logging and error management system. On that product, our system trapped all system errors and created a helpdesk ticket with all relevant details and then sent an email to the team. We could also quickly throw variables into an associative array and have those be displayed in a nicely formatted table at the bottom of every page.

In December of 2015, I was working on a NodeJS data processing project and realized that I had probably written 10 different logging frameworks over my 15 year career. While nothing I’d ever developed had been particularly robust or overly challenging, it was still several months of wasted effort when each framework had been added up. Worse, in all the projects that I hadn’t iused a logging framework I’d suffered through the inefficiencies of printing to a command line.

There’s Got To Be A Better Way

I’ve always been passinoate about the process of building software products. I’m always on the lookout for new tools, frameworks, and methodologies to make software engineering into a better career. I decided to start putting together a robust logging framework that I could use to drop in at the start of every project. After a few nights of prototyping, I came up with something functional that I think could be extremely useful to other developers, so I called up my friend Kari and pitched her on my idea. A month later and here we are, just a few short weeks away from launching our logging API-as-a-Service product.

With LogDebug, you add the library to your project and let our service handle the logging. We have a few features built that I think add some really cool capabilities that I haven’t seen before in a logging framework and I’m going to write about those features over the next few weeks.

Kari is hard at work building the customer-facing front-end while I work on writing the documentation and building some more language-specific libraries. Sign up for our pre-launch mailing list and we’ll let you in before anyone else (and probably throw you a life-time discount too).