Marc Andreessen wrote this popular, oft-cited article that first appeared in the Wall Street Journal back in 2011. You won’t need to read the whole piece to get its gist, though; Andreessen’s succinct headline is enough to glean his point—
It may have been only slightly prescient then, but today, Andreessen’s words have become gospel for the tech community as a whole.
Unfortunately, the word according to Anderssen hasn’t traveled very far outside the tech industry. What’s more, his foretelling can be seen as a tale of things to come if industries don’t get in the game:
“More and more major businesses and industries are being run on software and delivered as online services—from movies to agriculture to national defense. […] Over the next 10 years, I expect many more industries to be disrupted by software, with new world-beating Silicon Valley companies doing the disruption in more cases than not.” [emphasis ours]
If industries and organizations alike don’t heed this warning, they’ll quickly find themselves disrupted and displaced by a tech company. After all, it happened to hotels with Airbnb. It happened to taxis with Uber and Lyft. And it will most certainly happen to your organization.
Adapting to this threat, however, doesn’t require a whole rewrite of your business model. Rather, it can be as simple as adding a prophet of Andressen to your payroll—a developer.
Modern-day machinists
Let’s define what a developer is—or rather—what a developer can be for your organization: a modern-day machinist. The similarities are, after all, uncanny.
Consider when factory machinery breaks; it’s the machinist left to investigate and solve the problem. Whether it’s a matter of replacing the defective part with some off-the-shelf components, or milling a new cog out of a slab of aluminum, the machinist is ultimately responsible for fixing the system.
In the case of a developer, the problems they solve typically involve connecting pre-existing pieces of code—the machinist’s equivalent to ordering an off-the-shelf component—or coding a unique function entirely—the equivalent to milling a new part.
Both developer and machinist are ultimately responsible for “hacking” a solution into place.
The lazy man works once
It’s not just the hard skills a developer possesses that makes him or her a great hire (read, the actual ability to code). Rather, it’s the soft skills he or she brings to the table. More specifically, however, it’s their laziness.
In fact, Larry Wall, creator of the Perl scripting language, defined a developer’s unique type of laziness as a virtue:
“The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it. Hence, the first great virtue of a programmer.”
Yes, developers have the intrinsic skills of programming, but they also know the subtler skill of finding system efficiencies—a trait that’s become increasingly important in these highly-competitive times.
A lazy developer, then, will only work once—just enough time it would take to automate their workflow.
Learned from the best
Universities not only teach this laziness to developers, they pride themselves in doing so. It’s a core part of the computer science curriculum, after all. It goes by a different name there: abstraction. Here’s how Harvard defines it:
“Complex details that may not be of interest are abstracted away so that the programmer works with only what is necessary to him. Abstraction is a key part of computer science, and more life in general.”
Abstraction is how developers can build upon the work of those who came before them. There’s no need to re-invent the wheel when a developer sits in front of a computer to code. The hard work’s been done by someone else. The industrious developer merely needs to find the right resource to get the job done.
And those resources are aplenty for the developer.
Resources such as GitHub, the largest development environment that also boasts a large repository of shareable and editable code, to API libraries that allow developers to extend the functionality of a program by “calling into” another program. The developer has these, and many other tools, readily available in their tool box.
In reality, then, hiring one developer is like hiring a world of developers at your organization. For that price, can you afford not to hire a developer?
