There’s a beautiful irony to our medium. While scripting really great code is difficult, once we’ve written that exquisite code, we can redistribute it to the rest of the world easily, without any loss of fidelity or quality. Great code doesn’t lose its intrinsic worth once a lot of other programmers have their hands on it. Quite the opposite, in fact.

As a community, programmers help out other programmers all the time. We can expedite many of our processes by pulling something off the shelf that our colleagues have built for us.

Building Apps Is Like Going to a Walmart

For instance, we can write more maintainable style sheets by using Sass before converting it to CSS. We have jQuery and CoffeeScript at our disposal; they are elegant frameworks that sit on top of JavaScript and hide all of its onerous syntactical nuances. Need a JavaScript plug-in to display images in a lightbox? There are at least thirty, written for jQuery specifically!^[16]

Many younger developers have never had to write a raw SQL database query because object-relational mapping (ORM) tools and code generation frameworks do the tedious labor of transitioning data from a relational database to objects for us. Need an ORM tool? There are hundreds of open source and proprietary solutions.^[17]

On the web application level, development frameworks like Rails and Django let us develop database-driven web apps while shielding us from most of the plumbing between the UI and database. Instead, we have the luxury of working within their softly cushioned walls.

For any task, large or small, on any level of the development stack, we can almost assuredly find a tool someone else has beautifully written to satisfy our needs. In most cases, it makes sense to use those tools. Even if they don’t perfectly give us the functionality we want, even if we need to slightly bend our own preferences to conform to them, it’s usually worth the time spared from building our own.

For instance, I’d never consider building my own continuous integration system. Jenkins (formerly Hudson) does it perfectly. I’d never, in a million years, write my own database syncing tool. I’ll gladly spend a few hundred dollars on a tool like Red Gate than figure out all the edge cases involved in merging database schemas on my own. For most development tasks, I’ll leave it to a piece of code written by people with much greater expertise in that domain.

To that end, building applications today feels a bit like going to a Walmart; maybe the open source movement is more like a Goodwill store. We can throw all these great toolsets into our cart, hit the checkout line, and go. Once we get home, we can unwrap all these great bits of code, stitch them together with a helping of our own, and give life to an application. We can get to running software really, really fast today.

The Backlash of a “Fast Code” Culture

Let’s be thankful that using these tools doesn’t cause the same public backlash as using “efficiency frameworks” in other industries. So long as our applications are designed and perform well, the material we use underneath goes unnoticed by the user. That’s not a luxury that every industry has.

Take the food industry, for example. Back in the 1950s and 1960s, fast-food was hip. It was futuristic. It was progress. It fit the lifestyle of a nation that predominantly traveled by automobile and wanted a quick yet still satisfying way to enjoy food “on the go.”

Yet a few decades later, those mystical magic food units began to fall out of favor. The quasi-automated nature of making such food has led to a major obesity epidemic in our society. Poor animal living conditions, hormones, and pesticides are, unfortunately, requirements to mass producing food at a low price. And besides all of those reasons, a culture simply fell back in love with real, handcrafted food.

Fortunately, we don’t have that problem with “fast code.” In other words, a renaissance in writing-every-bit-of-code-from-scratch-again seems unlikely. Leaning heavily on prebuilt libraries and frameworks to rapidly get applications up and running is very much here to stay.

But a backlash does loom. In each of these frameworks, much of the critical forethought has been extracted from us intentionally. What’s left are very quick, high-level methods to solve otherwise complex problems. All those lightbulb moments of brilliance that their original creators discovered are now buried somewhere well beneath the programming interface.

With all the luxuries we have today with myriad efficiency platforms, we can quickly lose our appreciation, interest, and understanding for what’s going on under the hood.

And that’s a dangerous place to be.