Since the beginning of time, back to before humans invented fire, there were two traditional ways to debug applications: one way -after having invented hieroglyphics, of course - was by reading log lines and the other was by using the common debuggers that surrounded a cave dev’s cave. It’s safe to say that society has progressed since then and, luckily, so too has traditional debugging.

You wouldn’t expect an architect to build a skyscraper with just a hammer and a ladder, right? Then why do we sometimes look at developer tools as something ‘extra’, or as a ‘nice to have’, and simply assume that all that a developer needs is a laptop and an internet connection? A skyscraper is built in a fraction of the time and to a much higher quality if the team has access to top of the line equipment.

As R&D managers, we want to make sure our developers are happy and efficient. We want to ensure that they have the bare necessities they require to develop the best applications, whether it be the right desktops, the right headset, the right brand of coffee, and as many cookies as our budget can afford.

The R&D team at every company is made up of a variety of personalities- developers, tech leads, team leads, you name it. The Product team is also quite a diverse group and is usually made up of creative UI/UX designers and product managers. When you throw them together, you get a meaningful relationship that creates magical features for top-notch products.

Over the last few days, I have been hard at work writing an up to date comparison of Kubernetes tooling (check out the first and second posts if you haven’t already, which cover tools that help you reproduce issues locally). Going through the sprawling Kubernetes ecosystem and curating the knowledge that would be the most interesting to fellow developers and engineering managers has been no small task. That’s why section 3 will cover the heart of cloud-native development: the IDE.

Over the last few blog posts, I have covered critical elements of developer tooling for Kubernetes and how things are looking in 2021. As we continue to dive into that discussion, we must not forget the process of building container images. Of course, most of us create our images by writing Dockerfiles and building them with the Docker engine. And yet, more and more teams are adopting newer alternatives.