Workman's Tools

My current gig has a pretty gnarly codebase, which is par for the course: it’s a fight against entropy after all. So, you need tools to help you tame the mess and figure out your way through it. The electrician has his multimeter, tape, pliers; the plumber has his wrench, snake, plunger.

I have to admit, I have not really used IDEs for any extended amount of time, on the codebases I’ve handled. If I were honest, it’s probably because in the common case, the sizes of these codebases are relatively small— the largest codebase I handled, if I recall correctly, was in the order of about a million lines of code; not tiny, by any means, but I think fairly manageable: at one level of abstraction above, it’s only about a few thousand classes, and in most cases the design of the system allowed for you to keep chunks of the entire design in your head while working.

So if not IDEs, what do I use? I’ve used GNU Emacs since college, and although it’s a pretty powerful programmable text editor, I hesitate to recommend it to new developers. Sure, there’s a bunch of things you can do inside Emacs to wrangle your code to shape: I’ve used those things. I’ve used replace-regexp to do parameterized replacements, I’ve used string-rectangle to insert common text prefixes across multiple lines, I’ve written my own elisp to do some gnarly editing. I have by no means mastered Emacs, and there are a lot of things I am still doing fairly manually that I can probably automate with a bit of elisp, or by using some package in ELPA.

I honestly don’t know why I hesitate recommending Emacs, I just do. I haven’t thought about it too deeply. Maybe it’s the fact that using Emacs feels so different, I struggle to even describe it. And by no means is different a bad thing, but when the rest of the industry is moving towards usability and user experience, about discoverability and such, Emacs is such a step sidewards. Sure, modern Emacs has a lot of affordances for its capabilities, including better integration with modern graphic environments. But underneath it all, you can still sense that Emacs is a product of a time when the main interface was the text terminal over what would now be an abysmally slow link.

I use Emacs out of sheer inertia. I’ve used it for the whole of my career now, and it’s simply much harder for me to disengage some muscle memory from it.

I am also definitely not averse to dropping down to the shell to accomplish a lot of my tasks, and I am a product of when I started my computing life. For a while now, my shell of choice was bash(1), being as it was the default Linux shell on a lot of distros, including the ones I first cut my teeth on. Recently, I switched to zsh(1), primarily for some affordances I couldn’t quite get on bash(1), and secondarily because I needed a better prompt. As zsh(1) and bash(1) aren’t too different from each other, I didn’t find it too difficult to switch.

I use the shell a lot, and I often have a terminal open, and I use iTerm2 as my terminal emulator of choice. I have at least two terminal windows open, one for general housekeeping stuff, and one for my current project; I’d have a terminal window up for ssh sessions as well. In the terminal window for my project, I usually run builds and do file management operations¹; I also often tail logs here for e.g. the web server for the system I’m building.

Going back to my current gig and its gnarly codebase: I needed a way to visualize the dependencies between classes, as I suspected that some classes could be smushed together. So, I looked for a class dependency graph viewer for Java, and found several, with a few of them being commercial products. I decided on using this particular app, and it’s been a good enough fit for what I need, at least for now.

Anyway, my usual approach would probably have been to bash together (heh) a shell pipeline with grep and what-not to extract a dependency list for each file, then generate a graph using dot(1). But that would have taken much too long, and if someone’s already done it, then I’m not above not reinventing the wheel.

That being said, I don’t discount IDEs. There are times when it’ll be faster for me to just use the IDE to get a particular job done, and I usually do, especially when performing a refactoring on a codebase that I didn’t create. If the tool can do it for you, then let the tool do it for you. In fact, in Java projects like this one, I would often keep Eclipse open and use Eclim inside Emacs: sometimes, I would even just run Eclipse headless. But as I said earlier, I prefer to do all my editing in Emacs.

---

Previously: Figuring Out My Voice