Identifying your Motivation

Different people will have different reasons for optimizing a development environment. One thing’s for sure: whatever the first links in the causal chain, the last item is always “therefore, I want to reduce the friction of my development environment”. Put it differently: I want to do my work more quickly, fight less with the environment. I want to make the environment support my workflow, as opposed to changing my workflow to suit the workflow of the tools at hand.

Unfortunately, as they say, there are no free lunches. Just as energy doesn’t come from nothing, that speed improvement, that time saving, also needs to come from somewhere. You can think of it as the law of conservation of development time. Or maybe it’s really just conservation of energy – put in energy to improve your environment, and you’ll need to spend less energy later to do your work.

Either way, there’s a critical realization hiding here. In terms of invested energy, your development environment is a bit like a savings account – you can put in energy now, and realize the saved time days, or weeks, or months later. Better yet, any improvement you make keeps on giving. It doesn’t run out.

What also helps is that all time is not made equal. You have your work-time and free-time, obviously, but there’s also crunch-time, off-time, tea-time, outage-fixing-time, hacking time, time for side projects, time for cooking, and time for sleeping. The art of improving your development environment is founded on finding time you can spare (be that off-time, hacking time, or sleep time) and investing that so that you can be more efficient when time is at a premium (like recovering from an outage).

Remember to have fun as well. Since you’re doing this in time you can spare, it’s OK to go down more rabbit holes than usual. No need to justify it, just let go and geek out!

So fine, good, we say we want to do work more efficiently when we’re low on time. What does that look like? For one, it means minimizing mental context switches. Every time you need to think about how to accomplish what you want, you experience a micro-context switch. You go from “I want to know which server is generating error logs” to “is the server name field 3 or field 4 in the access logs?”. You go from “I want to rename this function” to “does this IDE properly refactor this language?”

A related, but not equivalent, idea is staying in the flow. Context switches obviously kill flow, but so does the wrong kind of frustration. A problem needs to be challenging enough for you to stay in the flow, but the half-second input lag of your terminal should not be that challenge. Conversely, there’s a satisfaction to the well-choreographed dance of meet problem – deploy right tool – meet next problem – deploy the next right tool – meet next problem.

All that is a long way of saying: we want to minimize the time and number of actions needed to get from “I know exactly what I want to do” to “what I wanted to do has happened”. Note that this does not solve the problem of “I don’t exactly know what I want to do”. Only analyzing the problem and examining the available tools can do that. Having a wide array of tools ready to use definitely helps, though.

When you know what you want, but not how to get there, having more efficient tools can also help. Imagine you can think of five ways to refactor a piece of code. The refactorings are not conceptually hard, but they need a lot of code to be moved around. If your IDE can do most of that work in a few clicks, you’re quite likely to try all five ways, and choose the one that’s actually the cleanest one. Similarly, you might try all of them if you’re extremely efficient in using the text editing functions of your IDE or editor. But you’re quite likely to call “good enough” after the second one if each refactoring takes an hour, because your tools don’t support you.