If it hasn’t been obvious before, I am a heavy Emacs user. I started using Emacs around 2003; there have been brief forays into other tools and IDEs, but I’ve always seemed to go back to using Emacs – partly out of sheer inertia, and partly out of the high cost to my personal productivity from using an entirely different toolset. Every year of using Emacs means that cost is actually higher for me, and a part of that cost is quite subjective: I simply don’t like having to relearn a new set of tools just to work on code, and Emacs keybindings in other apps are a poor substitute in a lot of cases, at least for me.
I’d like to emphasize though that this works for me: I wouldn’t foist Emacs on anyone, to be quite frank. But, I’m not alone in its use for code wrangling, especially in a large organization as Amazon.
That being said, Emacs is somewhat supported by the tooling in the organization, albeit not in my team. My team (and a lot of other teams, if my observations are representative) have standardized on the use of IntelliJ IDEA as the tool of choice, and it is more or less an uphill battle to be using a tool that no one else in the team uses. I have to admit that in my first few weeks, I tried to use it for slinging code. The mental gymnastics where too much; I expected certain affordances (such as Helm, or the various rectangle commands), and trying to learn the differences were actually slowing down my navigation of the codebase.
One alternative I initially set up was to configure Emacs as an external editor for IntelliJ: I could use IntelliJ for most of the grunt work, and then switch to Emacs to edit. I found out quickly that switching between the two was a pain point, and not having quick syntax checking in Emacs was troubling, having lived with flycheck for years now (and flymake before that). I then explored the use of an LSP server plugin for IntelliJ, which exposes IntelliJ’s features (completions, refactorings, etcetera) to an LSP client, in this case Emacs. I quickly found out that when the author of that plugin says it’s alpha quality, it is alpha quality. A lot of things did work, but a lot of things just were too finicky for day-to-day driving, at at least for the codebases I needed to work on.
I then tried JDEE, after years of
switching away from it – I learned that development on it was picked
up after years of languishing, where it now is being actively
developed on. That was a bad
idea. The whole reason for my abandoning JDEE, I now remember, was how
I hated how it did syntax coloring, and how it sometimes locked up the
whole of Emacs while doing syntax checking, in this case via
flymake-jdee, which was not helpful to my productivity.
In the interim, I discovered that there’s a community of Emacs users within Amazon, and I was able to touch base with them. They helpfully pointed me to some internal resources that made things a little amenable, including internal tooling that made using Eclim work pretty nicely. They also pointed me to a bunch of other internally-maintained Emacs tools.
If anything, in a lot of cases, when you’re faced with such an uphill struggle to get your own set of tools to work in the environment you’re in, it does pay to ask around. You’re not the only person who’s tried stuff, and I might have saved a bit of time if I reached out to the community much earlier. Lesson learned.
And, by tapping to such a community, I also get to pick up some tips from the battle-hardened veterans who have already solved the thorny issues of integrating their tool of choice with the rest of the ecosystem within the company.
Who knows? Maybe one day I’ll get to contribute back some elisp
that’ll make Emacs work better for other developers in the company.
Previously: Vocabulary