Software Developers Always Want to Go Faster

Lately I’ve been thinking about inconsistencies or ironies in things developers say. I realize that’s pretty unusual for me, and you’re probably surprised that I would write about irony, or even recognize it when I see it. I can’t explain it. It’s just one of those things, you know.

In any case, I’m thinking about irony in the sense of a definition I found via Google: “a literary technique, originally used in Greek tragedy, by which the full significance of a character’s words or actions are clear to the audience or reader although unknown to the character.”

So, a lot of developers say they want to work fast. They like to use keyboard shortcuts when they use an IDE, rather than the mouse. They like to define snippets they can drop into place while writing code. They like this and they like that. It’s all good.

Many of those developers are particular about the way their desktops are configured. They want a certain configuration because it helps them go fast. They’ll spend hours, days, or even longer customizing the look and feel of their desktops and their tools; especially their favorite IDE. And no other IDE will work. It has to be their favorite one.

When they have to pair with someone or use a generic workstation in a mobbing session, they often complain loudly about the screen resolution, color schemes, IDE option settings for editor tabs and distraction-free modes, font sizes, fonts (even down to custom kerning), keyboard layout and distance between keys, position of special keys on the keyboard, and numerous other details that differ even slightly from their preferred configuration.

They need to have the tools set up according to their personal preferences so that they can work fast enough to make up for all the time they’ve spent complaining about the way the tools are set up.

Personal Preferences

When such developers write articles, blog posts, or tweets about the importance of having a particular configuration so that you can work fast, there’s an underlying assumption that everyone shares the same preferences about how to work.

Many developers who care deeply about the look and feel of their desktops like to set up a development environment, customize it to perfection, and then use it for an extended time for multiple projects. That way, the look and feel and the keyboard shortcuts are always the same. That degree of consistency helps the developers work fast.

We all have opinions. I’ve expressed mine on the subject of using the same development environment for multiple projects in the past. My preference is to create a pristine environment for each project, to avoid any chance of leftover configuration or unwanted libraries being present.

The funny thing is I do it that way for the same reason as other people spend time customizing their desktops: So I can go fast. I might have a different notion of what “fast” means, but the rationale is not dissimilar.

When you work that way, it causes you to develop a very different view about customizing the environment. If I took the time to install and configure everything just so every time I created a new VM for a project, I would spend quite a lot of time doing that instead of working. To me, that’s the opposite of going fast. So, I’ve learned to be tolerant of differences in the default settings of various operating systems and different development tools for things like screen resolution, fonts, font sizes, and color schemes. While many of my colleagues will install their favorite IDE before doing anything else on a fresh environment, I’ll use the default text editor that comes with the distro to perform the initial configuration.

What You Work On

Another factor that plays into your decision to spend time customizing your desktop is the nature of the work you do. Many of those who spend a great deal of time customizing their tools are employed in a team that supports a single application. They work on this application over a long period of time. They only ever use a single IDE and two or three languages; for instance, C#, JavaScript, HTML and CSS. They do all their work inside of VisualStudio or VSCode. For them, customizing the tools in a way that streamlines their work flow makes perfect sense.

But everyone doesn’t work on just one application for an extended time. Some of us work on different projects for different clients, using different operating systems, programming languages, devices, and development tools. We would never be able to remember a custom set of key bindings for any one of the IDEs or editors we use. We have to stop and think about what key bindings are in effect based on which IDE we’re in, what operating system we’re using, and what sort of keyboard we’re using at the moment.

So, what’s fast in one situation may not be what’s fast in another.

Keeping Your Tools Out of Your Way

All this customizing of tools is aimed at enabling a developer to work fast while using the tools. While refactoring a chunk of code, the developer needs to focus on the task at hand and not be distracted by trying remember how to make the tools work. The features of the tools have to be in the developer’s muscle memory.

That’s consistent with my view about tools. I think a tool should help you achieve some goal in a way that doesn’t require you to think about the tool itself. If you always use (for instance) resharper in VisualStudio, then you’ll want to get the keystrokes under your fingers so that you don’t have to think about them consciously while you’re working. You think “extract method” and your fingers just do it. If someone asked you what the key bindings were, you might not even be able to remember them consciously.

But what if you don’t? I mean, what if you don’t always use resharper in VisualStudio, or some other specific thing, like IntelliJ IDEA or Eclipse or whatever? What if you switch among different environments and different tools fairly often? What’s “fast” then? The mouse? Probably not.

IDE Not Always Needed

FWIW I’ve found it useful to leave the IDEs aside and work in a text editor. I’ve been getting used to Vim recently. The advantage for me is that no matter what language I’m writing in and no matter which of the mainstream operating systems I’m working on, the key bindings and the look and feel are the same. The Vim plugins I’ve selected behave the same way on all platforms. I don’t have to re-train my muscle memory to switch among IDEs like Android Studio, Arduino Studio, RubyMine, PyCharm, or what-have-you.

In most cases, the things the specialized IDEs add amount to a visual wrapper around libraries, and shortcuts for creating source files containing common boilerplate relevant to the particular language. You can stick the libraries in the appropriate folder yourself, and you can define “snippets” using most good text editors.

I’ve discovered other advantages, too. I’ve come to appreciate the work flow of continuous testing. In the world of IDEs, continuous testing is supported here and there but not everywhere. You can use Infinitest for Java in IntelliJ IDEA. You can use Autotest for Ruby in RubyMine.

If you “always” use one of those tools then it doesn’t matter if other tools support continuous testing. I’ve found it quite convenient to run Vim and a terminal window side by side (or one above the other) and have a “watcher” running in the terminal window to kick off microtests whenever it detects a change in the production or test source directory trees. Using something like guard (a Ruby gem) for most languages, or a tool that comes with the language, like sbt for Scala, I can enjoy continuous testing support for any programming langauge, not limited by support that may or may not be present in any given IDE.

One more advantage, even if it’s a minor one: The keyboard shortcuts supported by IDEs are an afterthought. IDEs were invented in the age of the graphical user interface. They’re designed around mouse usage. Keyboard usage is a secondary design element. There are things you need to do inside the IDE that are easier and faster with the mouse than without it. So, to work fast you need a combination of mouse and keyboard.

The venerable text editors, Vim and Emacs, were designed around keyboard usage from the beginning. Using a keyboard-only setup feels natural. There are no times when you wish you had the mouse, because using the keyboard is inconvenient. So, if you truly believe a keyboard-only work flow is best, you’ll probably like working with an editor instead of an IDE.

IDE Sometimes Better

One thing you lose when you move to a text editor instead of an IDE is built-in assistance with refactoring. Good IDEs have at least some support for a few basic refactorings. This is often very helpful. Using Vim, I don’t have that. On the other hand, in the normal course of work we tend to apply only a short list of basic refactorings. All of them are pretty quick and easy to do without built-in IDE support, and a good deal of the refactoring we want to do involves manual modification as well as IDE-supported steps. So, it isn’t a great loss, in the grand scheme of things. But it’s still worth mentioning as a “downside.”

You can check out the difference in work flow yourself. Paul Hammant has posted a refactoring experiment on his blog. You can try it using an IDE and a text editor, and get a feel for the differences yourself. That’s more effective than just reading.

There’s more than one way to approach the challenge Paul presents. For the purpose of comparing an IDE-based workflow and an editor-based work flow, I suggest you read through the challenge carefully and map out the stragegy you want to use. Then, follow exactly the same steps with the IDE and with the editor. As you work, notice the times when the type of tool seems to offer good help while staying out of your way, and the times when the type of tool seems to cause you extra work. Then you can make a personal judgment about which seems more effective on balance, given the way you prefer to work.

The purpose of Paul’s refactoring experiment is to explore different strategies for refactoring the starter code. I’m suggesting re-purposing the experiment to explore differences in work flow between an IDE and a text editor. To that end, it’s important that you carry out the refactoring in the same way both times.

Where’s the Bottleneck?

Notwithstanding all these pleonastic niceties, the truth is the speed with which a developer operates the keyboard is not the constraint in any software delivery process. No matter how you configure your desktop and no matter how proficient you are with keyboard shortcuts, those things are unlikely to have any measurable effect on lead time. So, don’t overthink it or worry about it.