Oh, the Places You’ll Go When You Leave Your IDE – InApps Technology 2022

There are many points of dispute in the software engineering world. Which coding language is best? Which cloud vendor, IDE (integrated development environment) or source control management tool are easiest to use and more powerful? What is the best way to debug — breakpoints or logs?

We feel strongly about these questions, and many of us have preferred options. In some cases we turn into fanatic zealots when one of these questions is raised, and if you ever thought to yourself “that’s exactly what a tabs-over-spaces person would say,” then you know what I mean.

But despite our differences, there seems to be one point of absolute, timeless, undebated truth: Developers never want to leave their IDE. Dev tool vendors know this and undergo significant efforts to keep their users and customers happy, safe and warm in the comfort of their favorite IDE. But is this statement always true? Let’s find out together.

I would like, if I may, to take you on a strange journey. A journey of discovery and of questioning absolute truths. A journey into dangerous, far away places. A journey outside your IDE. You might want to bring an umbrella.

Why the Obvious Truth Seems Obvious and True

If you’ve ever written code for a living, you are probably familiar with the safe and warm feeling of opening your favorite IDE. And it’s very likely that you’re just as familiar with the frustration that happens every time you are forced to leave your IDE. Your IDE shows you the most important thing: your code. The thing you are writing, the thing you are working on, the thing you are troubleshooting. Everything is code and code is everything. So, obviously, the way to view and edit code is in my IDE, right?

Quick! Get back to your IDE!

Anything that takes your eyes off your code is dangerous and frustrating. Viewing a defect description or a user story, getting a Slack message or an email, checking the status of the CI automation and trying to figure out which tests have failed — these are all examples of actions that take a developer’s eyes, mind and focus off the code they are writing. The mental effort of a context switch and the loss of valuable minutes or hours that were spent on attempting to grok the current state of the application are losses that a developer is trained to avoid at all costs.

Configure and Run your Docker application from the comfort of your IDE.

Popular solutions in the dev tools and DevOps domain have known this for a while and have worked hard to approach developers in their home environments by providing an IDE plugin. A quick browse through the IntelliJ or VS Code plugin marketplaces reveals a number of familiar brands, proving that many vendors have decided to meet their users by integrating into their favorite interface.

Sowing the Seeds of Heresy

Like many universally accepted truths, cracks in our conviction started appearing once we took a deeper look at how we and how our customers really work when we build production-first applications. Some of us prefer to use the Github web interface when we submit or review a pull request. Most of us prefer to get the full story behind a user story or defect, or to add our comments to a support ticket in an external interface. And all of us don’t even hesitate before switching tabs to check out the build status, to learn why automation tests have failed this time, to change something in our Docker configuration or to check the state of our production environment in our favorite APM dashboard.

Yes, some of these tools and workflows have their IDE-plugin version — or, in some cases, a CLI alternative — with varying degrees of success across a multitude of IDEs and supported languages. But when the problem is complex and when solving it requires a specialized tool, developers don’t hesitate to use the best-of-breed solution and avert their eyes from their IDE.

Resolving the Cognitive Dissonance

So we have learned that developers never leave their IDE, except when they do. When a task is not pure coding and when the alternative tool brings enough value, developers are willing to make the extra mental effort of switching tabs or windows, and even learning to use a new tool. At Rookout, we made it our mission to make this transition as smooth as possible, by on one hand reducing friction and giving an IDE-like experience wherever possible, and on the other hand making sure to give enough added value in our web IDE to ensure that using our tool is worth the minimal effort and learning curve.

Reducing friction and providing an experience that is as close as possible to an IDE was no easy feat. In fact, it is an ongoing effort, and we keep improving our experience with every ounce of feedback we get from our users. Going for a dark color scheme and using the right font was easy enough. Providing an IDE-like structure, where the code takes the center stage, the repository and folder structure are on the left-hand side, and debug snapshots or log console are at the bottom — these things were quite straightforward as well. And of course, the core of the Rookout debugging experience, setting a breakpoint next to a line of code, was a given. However, please don’t ask us about what color the breakpoint should be. We’re not opening that can of worms again.

If I didn’t need to tell you that this is an IDE, then I just proved my point.

We faced more significant challenges when we tried to emulate features that give a developer a deeper understanding of their code. Syntax highlighting, showing variable values in context and providing advanced search and navigation capabilities were all tricky to implement at times, but they were worth the effort. Seeing our users intuitively search with ctrl/cmd+shift+f or by right-clicking a variable or function and choosing “go to definition” made us realize that we made the right call.

From Reducing Friction to Adding Value

Ultimately, our beliefs were reaffirmed that when it comes to debugging in production and/or debugging high-scale distributed apps. In those cases, the IDE experience has its limits. Selecting an environment or a subset of servers and containers is not something you expect to do in an IDE. Ensuring that you are viewing the correct version of the code and that you are setting your breakpoint on the right servers and making sure that the breakpoints you set do not collect sensitive data or throttling your log collection to prevent a performance hit, these things are just not native to an IDE experience.

These are the areas in which we felt our web-based IDE could provide that extra value. By tailoring an experience that fits cloud native, production-first use cases, we have built our IDE to be imperative, something that was hard to replicate in an IDE plugin.

A familiar IDE experience, enriched by the power of a cross-browser Web app.

Breaking free from our own dev dogma, we found additional areas in which we can provide additional value to the traditional IDE. Visualizing data that was received from debug snapshots, creating a Debugging Heatmap, displaying Agile Flame Graphs and Dynamic Tracing Timelines — these were all experiences that could not be replicated in an IDE plugin. And since we provide a web-based software-as-a-service experience, we can provide a rich experience with high quality without worrying about supporting a multitude of IDEs, versions and form factors, or about our customers facing issues that were resolved in a newer version of the plugin.

Final Thoughts

One point I intentionally neglected to mention so far is that we do have an IDE plugin. We have developed an IntelliJ plugin, providing basic functionality and allowing our users to set non-breaking breakpoints and view live debug snapshots and dynamic log lines in the comfort of their own IDE. So far, the overwhelming reaction from our user base is that the IDE plugin seems like a good idea when a developer first takes on the challenge of debugging in production. However, as users learn about the complex challenges of cloud native, production-first debugging, and they realize the benefit of the rich experience provided by our web IDE, most of them opt to leave their IDE after all.

Which leads me to double-down on our first motivation, which is to provide a vital solution to our developers as a SaaS product with a web-IDE interface. Should technology evolve to enable all of these deep and rich capabilities, then we will revisit the IDE plugin solution. Until then, we will keep on providing the best debugging and monitoring experience to our users.

InApps Technology is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.

Lead image via Pixabay.