Some comments on logs

During my whole career, I underestimated the importance of logs. I was always aware of the importance of logging key events to track and solve issues, but I never paid enough attention. In the mobile world, we tend not to log much. We prefer to use analytics to track key metrics and assess the feature’s success. Additionally, we use tools like Crashlytics to identify crashes and gain more insight into existing issues.

Although it might be enough for the frontend app, it is not enough for the server-side. In the startup world, where we need to iterate very quickly, tracking what is going on in the app is crucial. This could help us make the right decisions at the right moment, eliminating the need for time-consuming debugging and guesswork about potential issues. I think that at the beginning of the journey with the product, it is best to hook up a logging tool and log as much as possible. In Node.js, we can log every call with some details about it (being careful about the privacy, of course). In the first few months, we’re likely to have low traffic, so we can push a lot of logs and monitor them to see what gives value. Active monitoring of the logs is the key here. We need to examine the current situation and iterate on our logging process to make the most sense of it. Since many tools and platforms have their own set of logs, we can consider ways to monitor all essential parts and react quickly when necessary.

As I mentioned earlier, in my projects, drawing from my mobile development experience, I underestimated the importance of proper logs. Reflecting on my startup journey, I’m confident that I would have a better understanding of the product’s quality if I had delivered it with the right amount of logs to monitor regularly. I am sure that the time invested in logs is way more important than the time invested in very detailed unit tests. Unit testing is critical. I don’t want to underestimate its value. However, in the startup environment, which is developed over the weekend and after hours, we need to use our limited resources very wisely and not spend them on things that have less impact on the actual product. I love the confidence that comes from spending the whole day in TDD mode and ending up with high coverage. However, not everything is easy to unit test without proper abstraction. Adding the abstraction, separating the domain, and hiding all side-effect interactions into the implementation details is very important. Still, sometimes in the startup mode, we do not have the luxury of proper planning and driving it in the DDD way. So we make shortcuts, I guess everybody does. I believe it is okay, but we need to control the outcome. If we cannot rely on the proper test suite, we need logging capabilities to help us deal with the problem.

Of course, having great logs in a big ball of mud won’t help us make our software good. So composing from the small pieces, isolating experiments that might be thrown away, and logging as much as we can is something I would recommend for every early-stage startup. It would be challenging to determine how these elements would function within a large team developing a mature product. Still, based on my experience in the mobile world, they would undoubtedly be beneficial.

In summary, I believe it is always a great idea to log. At the project’s outset, log as much as possible. Then, use active monitoring to reduce the logs, preventing them from overwhelming us with unnecessary information. This approach also enables you to group logs into buckets, making it easier to manage them effectively as the project expands.