Want to become more technical in just 5 weeks? Find out how the Skiplevel program can help.

I've talked a lot about the 4 core skills in technical literacy including broad awareness of the availabilities in technology and how we can use them in creative ways to solve product problems. Logging is another one of these availabilities in technology.

The Lowdown on Logging

Logging is an essential part of software development and no app is deemed “shippable” until proper logging is setup. So yes, that timeline you’re working with developers on includes the time they’re spending setting up logging.

Logging allows your team to monitor what’s happening in your app, and how your application is being accessed and used. In programming, logging means to record in real-time an application’s information, system performance, and/or user activities into detailed “log files”.

Without logging we’re essentially shipping a piece of software blind without any visibility into the health of the application and system once it’s live. And this is a big no-no because what if critical bugs happen? Or leadership wants to know when peak traffic is, and who your visitors are?

If logging is done well, it allows your team to quickly debug errors, and get business insights around visitors and how the product is being used.

Sounds interesting…… tell me more!

The process of logging processes different log files based on what info is being recorded. These log files are organized into dates and hours and then stored on server(s) somewhere. It’s up to the developer’s discretion which log files a system should create, but there are 3 basic log files every system should have: access logs, debug logs, and system logs.

Access logs

Access logs allow us to monitor who is accessing your app and what is being accessed. This can provide us with important business insights like the demographic of users, and peak app usage.

Debug logs

Debug logs are exactly what they sound like — they help developers debug errors and in general provide information about what’s happening or clues to why an error happened. Typical debug log files label each log entry based on the criticalness of the information: INFO, WARN, ERROR, FATAL, DEBUG (See example below).

System logs

Since all applications are built on top of an operating system, it’s important to also monitor the health and status of the OS via the system log, or syslog. System logs log everything from OS startup, failures, errors, restarts, and shut downs.

How does logging affect my role as a PM?

Logging affects your product and role broadly in 3 ways:

• Longer dev implementation timeline
• Improve time to fix critical errors
• Source of information for business insights

Longer dev implementation timeline

The most obvious way logging affects your product roadmap is the time and energy it takes for dev teams to implement logging–a process that includes setting up infrastructure, deciding what info and how to log, how to store log files, and how to access logs. Because logging is essential to building software, there isn’t really a way around the added timeline.

However, allowing devs enough time to set up logging properly can save valuable time in future iterations of the product and later parts of the software development lifecycle (SDLC).

Improve time to fix bugs and critical errors

The first step developers will take to debug errors is figure out where in the code or system the error is happening and what the root cause of the error is. In order to do this, developers will narrow their search to specific log files to get a picture of what the system was doing at the time of error. If log processes are not set up efficiently, the time to fix bugs and critical errors is higher affecting your company’s bottom line and customer satisfaction.

Source of information for customers and business insights

Log files are a treasure trove of information about customers and this information can often be used to solve business and product needs.

Here’s a real-life example from my time as a dev:

I recall an instance when I worked on the internal documentation software at Amazon where logging was a solution to a business critical need. Amazon’s security policy had changed and the policy critically affected Windows users. The change required action on the part of Windows users who used our product within a specific time frame. In order to comply with Amazon’s policy change, our product manager needed to reach out to these affected users. The only way for us to identify the users affected was for us to query access log files. In this situation, communicating with our product manager about the solution and the complexity it involves was difficult since our PM had little knowledge of logging or software maintenance practices.

The bottom line

I often talk about how product requirements affect technical requirements as much as technical requirements affect product requirements, and logging is just another example of this reality.

While you don’t have to understand the specifics of the technical details of logging implementation, it’s important to know what it is and add it to your toolbox of available technologies for solving product problems.

Positive feedback is feedback too!

We often think of feedback as “critical feedback”, but positive feedback is just as important! Team cohesive and effective teamwork ultimately comes from a place of positivity and a sense of forward/upward momentum. It’s difficult to have these when just focusing on critical feedback. You want to know what you’re doing right along with ways you can improve. So as much as possible, ask for positive feedback like “What did you like about [x] that you’d like to see me continue doing?” and “What was your favorite part about [x]?”

If you want to level up your technical skills and your ability to communicate and collaborate with engineers, enroll in the Skiplevel program. The Skiplevel program is a comprehensive, on-demand course + community that helps you become more technical without learning how to code.