I just finished renovating the Rookout Breakpoint Editor area. It's the place within the Rookout app that lets you set a breakpoint condition, hit limit, time limit, variable collection depth, and other settings.

You know the saying, “by developers, for developers”? Well, at Rookout, we take that quite literally. Developers are the heart and soul of Rookout. As developers ourselves, especially as ones who have had our heads stuck in code for many years, we look to make fellow developers’ lives easier. There are countless tools that are available to developers. Whether they enable easier workflows, improve quality, aid in collaboration, and so on and so forth - the sky's the limit.

As the world is adapting to new and unforeseen circumstances, many of the traditional ways of doing things are no longer. One significant effect of this is that the world has gone almost completely virtual. Whether it’s Zoom happy hours and family catch ups or virtual conferences, what used to be in-person has digitized.

I recently remembered that about 13 years ago I was fully certified with the “Works on My Machine” certificate program. Although I went through the entire evaluation process as was required by Joseph Cooney in this blog of his, to be honest, I didn’t quite like how his certificate looked. So, I decided to go the extra mile - well, really, the extra few steps- in order to get the revised certificate issued by Jeff Atwood’s version.

Nowadays, the term ‘remote debugging’ instills fear into even the bravest of dev hearts. Palms sweaty, knees weak, and arms ready (to code) they dive into what they’re sure will end in much pain and possibly a few broken pieces of code. This scenario and these feelings are common to devs everywhere, where many opt to take the trusted path of debugging on their *own* machines.

Working with Rookout customers, I have noticed a significant pattern in how they describe engineering routines in the days before our software became a part of their daily workflow. It shows up in various engineering tasks such as developing new features, reproducing and fixing bugs, or even just documenting the existing system and how to best utilize it. It is also consistent across industries and tech stack.

In the age of discovery, navigators changed the world. Their unique skills won them fame, riches, and glory, as well as the ears and support of kings and emperors. The rulers of old who knew the importance of investing in these skilled frontier men rewarded their nations with the longest and wealthiest golden ages they’d ever seen. Nowadays, in the age of data, developers are the new navigators.

The metaphor of software viruses to biological ones is deeply ingrained, easily seen in the fact that biological viruses are at least the namesake, if not the inspiration for computer viruses. Can we take this analogy and reapply it in reverse? Is it possible to learn more about how we can combat biological viruses, such as the raging COVID-19 epidemic, by leveraging concepts, mindsets, and ideas that evolved in the software engineering and cybersecurity worlds?

Software developers and software architects have, for a very long time, stood on opposite sides of the “whose is better” competition. They have completely different beliefs, with each vowing that theirs is the correct one. Some swear by Java as the holy grail of backend; some worship Go as the right solution to all your backend problems. But, really, is there one right answer? Apart from the tools that you use, the architecture you will be using differs from company to company.

If you take a long hard look at the DevOps movement, you will find it actually divides neatly into two sub-movements. The bigger and often noisier of the two is about technology, advocating for the latest and the greatest tools and techniques, be they Cloud, CI/CD, Serverless, or Containers. The smaller sister, however, is much different, stemming from Management Theorem and focusing more on processes.