Take Time to Develop Fast

Developers love developing.The swiftness and simplicity of building something people actually want to use is intoxicating.

On the other hand, no one started coding because they liked long build processes and fighting with text editors. Yet many companies fail to realize how taxing their poor development workflows are on developers.

Facebook has been attracting top talent by promoting its hacker culture and the ease with which anyone can push code to production. Yahoo, meanwhile, is regarded as having terrible developer tools and has lost many employees as a result; ex-employee Sriram Krishnan prioritized improving their tools as a way to attract better developers in his letter of advice to new CEO Marissa Mayer.

As an example of how something can go very wrong, I spent my first few hours of a past job waiting for Visual Studio to install. When it finally had, I was shocked to realize that it wasn’t possible to build directly from source. I had to spend another day working with IIS configuration and Visual Studio debugging before I could even start writing code. Now realize: to avoid the time needed to set up and maintain a machine image, they’re wasting 10 hours for every new hire.

Projects such as Chris Granger’s Light Table show that developers are willing to pay to improve the time from idea to feedback. And Bret Victor is lauded for his talk Inventing on Principle,, where he proposes a number of improvements to the responsiveness of editing code.

Even so, many of us are unwilling to put in the small amount of upfront effort needed to save lots of menial work later on. Nonetheless, there are several things you can do early-on in the process that may seem time-consuming, but that will save ten times the amount of time later.

Set Up Your Environment

Do research and make an informed decision about which editor and shell suit you best. (I like Sublime Text and zsh, respectively.) Spend an hour customizing settings to your liking. When you’re done, commit your settings to GitHub. I’ve probably saved at least two hours just from the improved tab-completion in zsh over the last few years.

Research Life-Long Technologies

You should have a strong opinion on every major area of software development — from serialization formats (“XML is bloated and it’s difficult to debug”), to version control (“with Git I won’t lose work even if I’m developing on a plane”), to keyboards (“I like the BlackWidow Ultimate: it doesn’t have proper buckling springs, but it’s backlit and I like to code in dark rooms”).

For those without the benefit of working for a small startup with a daily voice in operations, take the time to learn about how to best use the tools you’re given. I’ve spent hours cleaning up bad Git merges that were actually simple mistakes in a few commands.

Be warned: It’s easy to get sucked into this point. I’m specifically talking about things you’ll be using throughout your entire life. Your text editor is going to be a common feature of almost any app, but your database might need to change in a month if it turns out that your customers want something different.

Research isn’t fun. Ninety percent of the time it’s better to spend your time developing. If you already know a technology pretty well – use it! If you find yourself spending more than five minutes thinking about which database is going to perform best for the sort of queries you need to run, you’re probably doing it wrong. (This notion in particular is much more applicable to startups. If you’re in a large company, you might scoff at the idea of not considering your database carefully. However, databases are a lot less of an issue when you aren’t certain about the future of your product.)

Set Up A Deployment Process

For a while at TapIn.tv we would manually run our Javascript through requirejs and Google Closure Compiler, upload changed files to Amazon S3, and then send invalidation requests to CloudFront from the terminal.

One day I was in a rush, and realized it took me ten minutes to deploy updates to our site. I spent two hours the next day setting up an automatic process. Assuming we release more than six times, that’s time well spent. Even our QA can be automated, thanks toRainforest.

Write Configuration Scripts

If I need to start working on our API, it’s as simple as ssh’ing into a machine and running “touch backend-api dev”. Our provisioning scripts are stored in an init.d directory alongside the projects in Git, so they’re easy to update. Compare that to the time cost of manually installing a lot of packages and cloning everything from git manually. Now consider that I do this several times a week.

(Several tools are pre-built to do this — Chef and Puppet are two of the largest — if you have no specific need to roll your own.)

Remember, as always: software development is an art. These are tips, but none of them are hard rules.

This post was originally published on August 17, 2012 on the TapIn.tv blog, which has since been shut down and turned into Framebase. The cover image is the one used on that blog, in memory of a product which never quite took off.