The Churn

Robert Martin recently wrote an article on the unprofessionalism of “always moving to shiny new tools.” If you haven’t read it yet, I’d suggest you go there and read it first:

We need to choose a language, or two, or three. A small set of simple frameworks. Build up our tools. Solidify our processes. And become a goddam profession.

I think he is by and large on to something here. For example, the one thing that stopped me from adopting Hacklang by Facebook, and the technology that became HHVM was IDE support. When Robert Martin mentions toolset, and availability of refactorings I can’t help but agree. These tools are invaluable to my process of becoming “more lean” within a language ecosystem.

In my search for a leaner approach to cutting code, I create Live Templates (if I am to use the Jetbrains/IntelliJ parlance) for just about any boilerplate I encounter. Furthermore, I learn the best ordering of keyboard shortcuts that I need to use to extract/rename/move the code so that IntelliJ smoothly takes over from manual typing as much as possible. Think of this part of my job as moulding the shape of the code, and the interface it provides to the outside world.

I know many software engineers (that I highly respect) who prefer to use a simple text editor, without these refactorings available. If I was in this type of environment I would optimise my language, use of frameworks, libraries and my application architecture so that I did not need to lean on an IDE. I would likely choose a language that did not require boilerplate, and I would likely not write as many “low level” unit-tests.

In my IDE environment, I optimise my choice of language, my use of frameworks, the libraries I pick and the application architecture so that my IDE can provide me with more helpful automations.

“Do you think that makes you a faster, more productive Software Engineer?”



No. I don’t think so.

“What do you mean?”

I mean, that I don’t think my decisions and choices around toolset make me faster or more productive or better.

“Why not use a simple text editor then?”

I think that the speed (and reliability) of your test suite is the primary impactor upon productivity.

“Wait what? What does that have to do with choosing an IDE?”

I choose to use an IDE, because I want to build and maintain a fast test suite, one that runs in a matter of a few minutes.

“I still don’t get it.”

In order to have a fast test suite, I need to write a greater proportion of lower level unit-tests. This means I need a more complex architecture that can provide an interface to those lower-level tests.

“So your IDE is a way for you to refactor that interface quickly.”


“Do wish you could avoid the more complex architecture, and still have a fast test suite?”

Every day. I hope that someone, someday will show me an architecture or build a language and accompanying toolset that makes this possible. At the moment, I don’t see how it is possible.