Guest post originally published on Rookout’s blog by Noa Goldman, Product Manager at Rookout
There comes a time in every developer’s life (or daily routine, we’re not here to judge) where they have to go and fix a bug. Back in the days when I used to be a developer, I distinctly remember how each time I would go face to face with a bug, my favorite method to fix it was to add log lines. I mean, why not, right?
I – and every other developer in existence, I’m sure – hated debugging, what with all the time it took to reproduce the bug and debug locally while trying to duplicate production in my local machine. I was constantly trying to save myself more time and avoid the whole process and believed that logging would be the way to achieve this.
I added log lines everywhere. Imagine Oprah giving out presents on her show? That’s more or less how I set log lines. “And this line of code gets a log and this piece of code gets a log”, well, you get the picture. You probably think I’m overexaggerating, but unfortunately, I’m not. Instead of reproducing locally, I wanted to be able to tell a story. It would be a story that would be faster to understand and which would take me to the cause rapidly.
The experience of an over-logger
Unfortunately, my system didn’t work. Instead of telling a story, I found myself surrounded by a crazy amount of logs which only confused me more, and eventually, I had to reproduce the bug locally again anyways.
Every time I went back to my logging tool, I had to then look for a specific log that would tell me the bug’s story. But suffice to say it was less than easy, and the time I spent looking for an informative log was taking way too long.
The easiest part of log maintenance is adding them wherever you want them. The harder parts come when you have to follow them and clean up after yourself. This was yet another thing I hadn’t thought of before embarking on my log-happy journey. I realized that it’s not just about adding the logs. Eventually, as with code, logs also need to be rewritten. When variables, logics, and code are changing – so too are logs. All this maintenance work didn’t suit my debugging attitude well.
To make it even worse, and as if maintaining them wasn’t enough, the costs definitely were. The amount of money my team needed to spend in order to keep all these logs up and running was extravagant. Spending money on different log tools and purchasing more and more storage simply so that we could have a place to store all our logs just wasn’t worth it. All of this money was spent on paying for logging tools, but it didn’t actually save any of the developers time or effort.
I found that I, and all the developers around me, were becoming fatigued by the endless amounts of logs and the effort it took to write and maintain them, when all we wanted was to simply get the information we needed to get to the source of the bug.
As is with most things in life, I learned a lot through experience. Logs are much like ingesting the right amount of caffeine- just enough and you are invincible, able to conquer any bug in your path. Too much, and well, you’ll be reduced to a twitching mess of a human, wondering where you went wrong.
Why logging is beneficial
Don’t get me wrong, you definitely shouldn’t stop logging. For any developer team, logging can oftentimes be a lifesaver. As a manager, you need to make sure that your team is walking into it with fully open eyes and understand that it’s not going to be the magic key that unlocks all of their code’s secrets.
How to optimize logging
In order to maximize your team’s logs for the best results, I recommend that you make sure of the following:
- When collaborating as a team, not all devs are familiar with every part of the code and not all team members will know right away where they should start debugging. Placing logs from time to time in the right areas can be extremely helpful for your team.
- Logging should be well planned. You don’t log because you can, you log because it helps the team to onboard. Logging, when done right, tells the story of the app.
- Think twice and plan ahead. Logs within the team need to be managed right, by being implemented under a strict standard and placed in familiar areas. Imagine your team of developers. Whether they are junior developers or seniors with 10 years of experience, it’s probably not their first logging rodeo. Each developer came to the team with a different logging method, but that doesn’t mean that one is necessarily better than the other. It’s simply a matter of taste.
Keeping track of how logs are implemented, how they are written, and maintaining a standard within your team will get you organized and help to tell a story that will eventually save your team a significant amount of debugging time.
Why meaningful logging is the most important kind
Meaning is everything when it comes to logs- if you can’t understand them, you won’t be able to get the information you need to debug. Imagine that there’s an emergency situation: your production environment is on fire and you have to fix it now. You have one buoy: your logs. And everything is dependent on how much your team can understand and gain necessary knowledge from them. Keeping your team in sync and structuring their habits to write meaningful logs can make the difference when it comes to how fast your team can solve a bug.
This can be done by deciding on a team standard together. Make sure that together your team comes up with all the meaningful flows that you will want to see while debugging or when checking that everything is on track with your app. When doing so, think of the important variables or certain states that you want to be presented immediately, without your team having to go the extra mile and look for them. The best way to find these variables is to think of a time when you had a bug you had to solve fast. What were the values which helped you to understand the issue fastest? Those are the variables to employ.
Logs are meant for the whole team. It’s important that when writing logs, whoever is doing so is keeping in mind their audience and who these logs meant for. This will help them to adapt their logging language and create logs that are easy for others to understand. No more misunderstood logs, and many more bugs crushed.
When to add logs
Teamwork is important. What is being logged as a team needs to be decided together. Much like writing logs or deciding on a log’s location, defining what should be logged is a key decision. When managing a team of developers, it is important to define important factors together in order to them while the application is running.
The decision should be made according to what is known to be a trouble-making area. Any critical flows that may happen within the app and can be predicted ahead of time, should be logged and captured. The key is to be able to avoid fires. When used wisely, logs are helpful in preventing damages ahead of time.
Only troubleshooting is not fun
Predicting fires are certainly one of the most important needs when logging. However, there are other reasons to add logs. Certain logs can be added for business or management reasons, such as keeping track of specific events like signing in or users editing their account.
It can also be used for profiling and timing certain areas of the code. Statistics can be taken from logs within the application, logging when certain things are happening can help the team detect behaviors and insights.
The Logging Life
So really, why are you logging if you’re not actually using the logs? It’s a question that is becoming more and more prevalent the more we realize that logs just aren’t the be-all and end- all that we used to believe they were. Don’t cast them aside just yet, but perhaps it’s time to consider employing tools that can get you that data you need to debug easily and efficiently, without needing to bash your head against the wall while you attempt to do so.
Live production debuggers, such as Rookout, do just this. Instead of writing endless log lines to be able to go back and get the information you need, set a non-breaking breakpoint and get the data you need instantly. It’s really as simple as that. So take the time for another coffee, grab a chocolate, and have a happy debugging session.