The author is a Forbes contributor. The opinions expressed are those of the writer.

Loading ...

Loading ...

This story appears in the {{article.article.magazine.pretty_date}} issue of {{article.article.magazine.pubName}}. Subscribe

I just read an interesting post by Noah Lorang, data analyst for 37signals, the influential development shop behind the web application framework Ruby on Rails and project management software Basecamp. In Why I learned to "make things", Lorang tells of his transformation over the past two years at 37signals from being a person with technical skills like Excel and the ability to "muddle my way through SQL queries," to someone who built the first version of a dashboard that "twenty months and more than 3,000 commits later," is used daily by half of the company and has its own iOS app.

How did he go from having technical skills that were "just enough to acquire, clean, and analyze data from a variety of common sources," to being an actual (if somewhat inefficient) 'maker'? He started from where he was.

Where Lorang was meant that he could cut and paste snippets of code, like click tracking in Google Analytics, into an existing website. He did just that after six or seven weeks on the job and logged his first GitHub "commit." As a data miner he also knew how to use a package called "R" for Excel that enables data analysis and visualization. This was a technical tool for his actual job. So when, after being on the job for more than a year, he realized that it would be really useful to have a "single page dashboard on our support caseload," he built something quickly in R. All of the company's apps are built with Ruby on Rails, but using R was what he already knew how to do.

Once he had built it, a systems administrator expressed an interest in "integrating various third party data sources into a single dashboard," and they started working on the proper dashboard app in Rails. By actually building something, however crude, Lorang was able to enter into a conversation about "making" that led to the actual making of a really useful application. If he had waited for one of the developers to have the time to do it for him, it all might have never happened.

He summarizes what he learned from the experience into two succinct bullet points:

It can be faster to do it yourself, "Business intelligence is about much more than statistics or machine learning—there’s a full “stack” involved from data acquisition to storage to reporting to testing. If I couldn’t do that, someone else would have to"

It helps to speak the same language, "people [at 37signals] engage with something that you’ve made differently than something that you’ve written or presented. Before I could actually make things, I felt like an outsider—who was I to provide advice to these people who actually made things?"

Lorang makes it clear that by "no means am I an especially good developer: my code isn’t always idiomatic, and I still get someone to review anything of substance in our customer facing applications." But in two years he is able to say, "I’ve written client and server-side instrumentation frameworks, released an open source timeseries data storage system, and deployed a Hadoop cluster with Chef." If you understand that, you must be a bit of a developer yourself!

The point is that all of this came from his own initiative. "I didn’t learn to make things because someone told me to or it was a job requirement," Lorang writes. "I could have done a credible job of what I was hired to do without ever delving into reporting or instrumentation myself, but I decided that I could do a better job and help the company more by learning to do some new things that I’d never imagined doing." Imagine this same scenario playing out in all kinds of companies all across the world and you can perhaps imagine the productivity that will be unleashed as code eats the world (to paraphrase Marc Andreessen.)