I have been managing R&D teams for the past 14 years or so and have learned many lessons along the way. Some of the best lessons have come about in the moment when your software meets the real world and you find that you need to debug remotely. Part of them were learned from my own battle scars and some were taught to me by my peers and employees.
As organizations place focus on innovation and digital transformation across enterprise IT, we continue to see increased adoption of containers and microservice application development patterns. Containers have brought developers new levels of flexibility and portability, but oftentimes still leave developers with questions about the best way to configure and build those containers.
Our ongoing goal at Rookout, the Live Debugging company, is to turn the debugging of live, remote applications into something that every developer can easily do as part of their daily workflow. Recently, we have taken this challenge one step further. What if we could make it so developers were also able to solve performance issues on a daily basis as well? Some recent additions we made to the Rookout platform are the first step towards turning that vision into a reality.
Learning a new language is always a joyous event. From the first innocent google search, through the first “hello world”, to always being surprised when the classic text is somehow printed to the screen/command line console/browser tab/local text file. The entire time your mind is quickly soaking in new ideas and concepts, new syntax and phrases, and new ways of doing things. Some of them can be compared to the languages you already know. Others are brand new.
Production debugging, as the name suggests, takes place when one must debug the production environment and see the root cause of this problem. This is a form of debugging that can also be done remotely, as during the production phase, it may not be possible to debug within the local environment of the application. These production bugs are trickier to resolve as well, because the development team may not have access to the local environment when the problems do crop up.
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?
As engineers, we continuously aim for perfection. The drive to deliver the perfect product sometimes defines how good we are as engineers. We often discuss and fine tune the term and the essence of our product’s perfection. Some claim that a perfect product is one that handles all the edge cases, works flawlessly, and can do everything.
As most developers know, their code doesn’t always behave as they expect it to and they’re not quite sure why. This is most apparent when it comes to debugging their software. In order to figure out what the problem is, developer teams must go through a very long process in order to get the data they need to understand the problem. This can involve unnecessary wait times, unproductive hours, and a lot of wasted resources.
