Gather round, folks, and listen to how I singlehandedly made my own development experience miserable for the past several months.
First, a bit of context. I’m a long time IntelliJ user (Webstorm, PyCharm, Android Studio, CLion, now IntelliJ IDEA for everything). I understand there are good reasons to prefer other IDEs but, for me, it’s still well worth it. I’m pretty sure it’s just muscle memory and preference-over-performance[1] at this point and I’m not trying to start a flame war here, obviously.
I’m also the kind of person who hates bloat. Whenever something installs a “Open on startup” daemon or status bar widget on my OS, I tend to disable it. For example, I own Parallels on my Mac, but I don’t have the Parallels daemon running. I have Docker installed but it’s not running unless I’m using it. I own MS PowerPoint but the various Microsoft background apps are disabled. Likewise for Adobe, Waves Inc, and Zoom. If it was possible, I’d disable Google’s helper apps as well (but I’m using Google Drive). I understand the desire of app developers to keep their own daemon running at all times and, at the very least, check for updates. But I hate to see so many different things consuming UI space and memory and CPU just for this reason alone.
Anyway, I’m guessing that, at some point, I found out that JetBrains has a similar daemon, “JetBrains Toolbox”, and I disabled it as well. Since it doesn’t show up on my Login Items in System Preferences at all (not as enabled nor as disabled), I assume they have some other mechanism of running it. So I promptly forgot all about JetBrains Toolbox.
Then, a few months ago, I started encountering a frustrating bug in IntelliJ:
In short, the issue was that after encountering an exception or a breakpoint, the IDE would show the correct file and correct line, but it would open the source file in read only mode. So on every exception and every breakpoint, I’d had to navigate to the file myself if I wanted to make any changes (or even go to definition, for example). It was a major pain in the ass.
At first I filed it at JetBrains’ tracker. They said it doesn’t belong there. So I tried github.com/flutter/flutter/issues. It took a while for the people on the team to look at it. I kept working around the issue for the duration. I was totally understanding of the fact that IntelliJ is not the focus right now, so I wasn’t expecting swift resolution (and the team made it clear that I shouldn’t hold my breath).
Anyway, last week Jaime Wren looked at the issue and couldn’t reproduce it. That made me curious. Somehow, I was acting under the assumption that this is a bug affecting many, if not all, IntelliJ users. It showed up for me after an update of IntelliJ to a higher version. So I assumed it’s something that IntelliJ upgraded and the Dart plugin hasn’t adapted to yet.
Turns out it was the other way around. I was unwittingly on an old version of IntelliJ IDEs. The IDE itself never told me so because it defers to JetBrains Toolbox to update. I was on IntelliJ IDEA 2023.3.2. When I finally upgraded today, I downloaded 2024.3.1.1. So that’s a full year behind.
The facepalm is strong with this one.
Anyway, I hope this cautionary tale helps at least one of you to avoid a similar problem in the future. Even if you’re like me and hate update daemons, you still ought to bite the bullet when it comes to your daily driver software, such as your IDE.
If you’re reading this and you’re from one of the OS vendors (Apple, Microsoft, Google), please, I implore you, figure out a way that makes software on your platform up to date without the need for developers to build their own update mechanisms. The current system clearly isn’t working. I realize that some of these daemons have ulterior motives, but I have a feeling many really only exist because the developer wants to keep their app up-to-date and running smoothly, and the existing OS tech doesn’t give them the functionality they need.
The end.
From the book “Universal Principles of Design”:
↩︎Increasing performance does not necessarily increase desirability.
• People often believe that a functionally superior design—the proverbial “better mousetrap”—is good design. This is not necessarily correct.
• The reasons people favor one design over another is a combination of many factors, and may have nothing to do with performance, but with preference.
• Preferences may be based on innate tendencies, cultural biases, aesthetic or emotional considerations, or legacy practices and conventions.
• Success in design is multivariate. Consider both performance and preference factors in design to maximize the probability of success. Beware the trap of creating a superior product in one dimension, but having it fail … (etc. etc.)