About the Author

As cheesy as it sounds, a development environment is a highly personal thing. Especially so if you invest time and effort to customize it, to make it really yours – which is exactly what this book is for. That means it makes sense for us to get to know each other a bit before diving in. I hope knowing where I’m coming from will also help put some of my opinions and conclusions in context. They may not always make sense for you – and that’s alright!

One of my axioms (values?) is never to waste anyone’s time. I’m not very altruistic about it, that also includes my own. I get annoyed when I – or anyone – needs to spend more time doing something than they’d strictly have to, in an ideal world. So far, that’s not unique.

Where it gets weird is what I think about how much time things should take in an ideal world. It usually depends on how often you do something. For something that’s as common as opening a terminal, cd-ing or whatever to your project, and starting its unit tests? I want that whole thing to take somewhere around 2 seconds tops. Switching to documentation / editor / e-mail? O(1), a single shortcut. It shouldn’t matter how many windows you have open.

I’m most at home with tooling, infrastructure, Linux, and backend code, but I tinker with a lot of software things. I learned monads. Three times. Know them? Hell no. But there’s just something inherently fun in taking a piece of technology, learning it, then bending it as far as it will go. Wonder if I can make React talk to that Bacon.js stream? Speaking of JS, how does Emacs handle JS embedded in HTML? React DOM elements in JS embedded in HTML? How about a script tag in a React DOM element in JS embedded in HTML? Will that break syntax highlighting? How about in Vim?

A big chunk of that tinkering necessarily went into the development environment itself. Let’s see if I can give you the result of that tinkering, without you needing to spend the same hours – after all, we all hate wasted time.