Rails Test Prescriptions Blog

Keeping Your Application Healthy Since 2008

Control Your Development Environment And Never Burn Another Hamburger

Everything I know about the world of fine dining I know from watching Top Chef and from eating at Five Guys. But I do know this: chefs have the concept of mise en place (which does not mean Mice In Place), which is the idea that everything the chef is going to need to prepare the food is done ahead of time and laid out for easy access. The advantages of having a good mise en place include time savings from getting common prep done together, ease of putting together meals once the prep is done, ease of cleanup. Again, I have no idea what I’m talking about, but it seems like the quality and care that a chef puts into their mise en place has a direct and significant benefit on how well they are able to do their job.

You probably know where I’m going with this, but I’m becoming increasing convinced that one of the biggest differences between expert and novice developers is control over the environment and tools they use. I came to this the hard way – for a long time I was horrible about command lines, it was actually something that kept me away from Rails for a little bit. It’s not like I’m Mr. Showoff Bash Script guy these days, but I know what I need to know to make my life easier.

Let me put it another way. Once upon a time I read a lot of human factors kind of materials. I don’t remember where I read it, but I read once about an expert short-order cook at a burger joint. His trick was that he would continually shift the burgers to the right as he cooked them, such that by the time they got to the end of the griddle, they were done. Great trick (though admittedly you need to be a bit of an expert to pull it off). Not only did the cook know when things were done without continually checking, but it was easy to put on a burger that needed a different amount of doneness simply by starting it farther left along the griddle.

What does that mean?

The name of the game in being an expert developer is reducing cognitive load.

Try and list all the things you need to keep in your head to get through your day. Think about all the parts of that you could offload onto your environment, so that you can see them at a glance, like the short order cook, and not have to check. What are the repetitive tasks that you do that can be made easier by your environment? What can you do so that your attention and short-term memory, which are precious and limited, are focused on the important parts of your problem, and not on remembering the exact syntax of some git command.

This is not about which editor you use, but it is about picking an editor because you like it and understand how to customize it, not because all the cool kids use it. If you are going to use Vim, really learn how to use Vim – it’s not that hard. But if you use Vim, and don’t learn the Vim features that actually make it useful, then it’s not helping you, and it’s probably hurting you. Is Vim (or TextMate, or whatever) making your life easier or not? Vim drives me nuts, but I’ve seen people fly supersonically on it.

I’m getting a little cranky about seeing people’s environments – I’m not normally a big You’re Doing It Wrong kind of guy, but, well, I’m getting a little bit cranky.

If you’re doing web development, there are probably three things that you care about at any given time: your text editor, a command line, and a web browser. Every man, woman, and child developer at my fine corporation has a laptop along with a second monitor that is larger than a decent surfboard. If you can’t see at least two of those three things at all times, try and figure out how much time you spend flipping between windows that you could be seeing together. If you are running Vim in a terminal in such a way that you can never see an editor and a command line at the same time, I think you can probably do better.

If you use Git, for the love of God, please put your git branch and status in your shell prompt. RVM status, too. And it’s not hard to add autocompletion of Git branches, too. Or, go all the way to zsh, which has fantastic autocompletion. Again, reducing cognitive load – you can see your environment without checking, you can type complex things without knowing all the syntax.

Use a clipboard history tool. I use Alfred, which is generally awesome as a launcher and stuff, but it’s not the only one.

Use some tool that converts frequently used text to shorter easier to remember text. Shell aliases do this, I also use TextExpander, which has the advantage that TextExpander shortcuts are usable in SSH sessions.

The thing is, I don’t know what the most important advice is for you. You need to be aware of what you are doing, and strangely, lower your tolerance to your own pain. What do you do all the time that is harder than it needs to be? Is there a tool that makes it easier or more visible? How hard would it be to create or customize something? Are you the cook who can look at the griddle and know exactly when everything will be done, or are you the guy constantly flipping burgers to check?


4 responses to “Control Your Development Environment And Never Burn Another Hamburger

  1. yachris February 17, 2012 at 3:09 pm

    Wow, flashback. I worked with a (really pretty productive) guy for a while, back in my Java days, who used one of the ancient text editors for Windows. He loved it, because started instantaneously, and it did syntax highlighting… but nothing else.

    It was *amazing* (in a horrible way) watching him, when changing to a different object, go through the following steps:

    * Find his windows file window, and dig around in the filesystem to find the right file.
    * Look around to see if he had an editor open already, and if he didn’t immediately see it, he’d just double-click the file to open a new one (unsurprisingly, this would get minimized when he wanted to find another file, so…)
    * Use the “Find” command in the editor to get to the class name/method/whatever he was looking for. And if it matched a bunch of other strings, well, hit F3 until you find it!
    * Do some work.

    So when I mentioned Eclipse, and how much more productive I was in it, and showed him how choosing “Find Declaration” from a variable/method/class/whatever took you *right to that declaration*, in whatever file it was in, he was impressed.

    Of course, he would never *use* Eclipse after I installed it for him… took to long to start! He could never get used to *not* closing the “editor” when he was done editing a file.

    So, as I say, he is a pretty productive programmer. But not fun to watch…

  2. Pingback: Community News: Tips, Tricks and more | New Relic blog

  3. szeryf February 29, 2012 at 8:29 am

    I agree. In the same vein, if you use shell a lot, invest a little time in aliasing the most commonly used commands into 1-2 letter shortcuts. For example, I use “st” = “svn status -u” or “git status” (depending on which repo I work) and many, many others. You can also use shell functions to automate common tasks, e.g. I have a function that adds to SVN all new files, then executes commit with given message, runs some cleanup tasks and plays a nice cheering sound file 🙂

    You can find a shell one-liner to list the most used commands from your history. Speaking of history, learn shortcuts like Ctrl-R, $!, !*, !! etc.

    Invest some time in learning advanced features and shortcuts of your favorite editor/IDE. If it’s programmable, learn to program it and automate your common tasks. If it’s not programmable, maybe it supports macros and/or templates. Learn and use those. If it’s not programmable and does not support macros or templates, find something else 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: