Jon is an experienced, results-driven engineer who writes great code. He is confident and experienced at managing the unexpected.
Updated Jun 13, 2022
As a new project spins up, we spend time pinpointing requirements, defining the architecture, choosing a tech stack, and cementing a team structure and communication tools. An engineer can feel antsy to get started building.
We, the engineers, often want to show something solid to the client right out of the gate.
I posit that getting logging for the app set up right away can reap huge benefits as the project progresses.
The impetus for these thoughts comes from learnings in a recent Elixir project. The thoughts and comments below are Elixir centric, but could and/or should be applied to any project.
Save Time and Money
I believe that TDD (test-driven development) can save a lot of time and money down the road by smashing bugs before they get deployed. BDD (behavior-driven development) can help keep the work focused on the actual requirements. But these are for a different article.
On the same “time and money saver” tip as tests, logging can be a huge boon early and, definitely, later in the app development. Good logging can help us see what is actually happening in the app in live situations.
Testing with incorrect assumptions can lead to false positives. Whereas logging tells a story without assumptions.
If a nasty bug does get deployed (which happens), good logging can help in tracing the issue faster. A lot of time (and thus money) can be spent tracking down a bug. The faster that the root cause can be tracked, the faster a fix may be implemented.
Catch Bugs Before Stakeholders
Some logging systems allow for sending alerts for various logs or log levels. If logging is implemented early, alerts may be implemented to notify developers of issues as soon as they start coding. This can allow the development team to be in front of bugs and potentially smash them before they might affect stakeholders or users.
Nudge Towards Better Error Handling
Having good logging in place can create a path for better error handling within code. As we write processes in code, we know that there are points where things may fail. We may be more inclined to handle the errors properly if there is a logging path already in place.
Types of Logging
Browser Console Logging
Logging to the console in a web browser can be very useful for catching bugs in a web client. One thing to be careful of is to only log meaningful information. Too much “noise” in the console can make finding useful information very challenging.
A server side app cannot log to the browser console. But, similar to the browser console, logs may be output to the terminal (stdout). Again, logs should be meaningful avoiding too much “noise”.
Logging to External Services
There are quite a few external logging services available. Many allow not only the capture and storage of logs, but also some great search features.
Logging to an external service may also allow for access to APIs that could help in generating reports and data from the logs.
Logging to File
Logging to external files may be a solution instead of an external logging service. The saved log files may be mined for reporting and data. One caveat is that the files must be stored and the storage may become quite large (and possibly expensive) in short time.
Elixir Logging Tools
Logger - The logging application that comes built in to Elixir.
json_logger or ink - Ensure your logs are output as JSON (structured logging). This can make searching them much more doable. This is also essential when outputting logs to some external logging services.
It doesn’t take a huge amount of time or effort to get logging set up early in a project. The benefits initially and down the road certainly outweigh the time and energy spent.
In Elixir there are libraries available that help structure and output logs that can be set up very quickly.