Legendary Productivity And The Fear Of Modern Programming [TechCrunch]

This article originally appeared on TechCrunch

JavaScript master Douglas Crockford once said that software is the most complex thing that humans have ever created. It’s made up of intricate bits and bytes pieced together like virtual puzzles. These insurmountable calculations help us achieve extraordinary feats, like routing human beings to the uncharted craters of Mars. By the very nature of the burgeoning computer science discipline, “we’re dealing with things that are on the edge of what humans can handle and more complicated than ever before,” said renowned computer scientist Donald Knuth.

While no one programming legend can possibly accomplish any big feat solo, there are programmers worthy of fame for their supreme productivity. Every so often, leaders of new revolutionary tools make an explosion in the field that reverberates across generations of new programmers.

But what’s even more interesting is that some of the highest-achieving programmers — who can make sense of such unfathomable complexity — can’t foresee a lucidly bright future ofprogramming. Several accomplished computer scientists share a grave concern of the shift toward our more fragmented web. Tools that act as layers, like frameworks and packages, are created to help programmers be more productive, but some experts fear they’ll actually have the opposite impact long-term.

If the foundation of the modern world is built on software, then deconstructing the toolkit of today’s software leaders can help us not only become better programmers, but develop a better future. Contrary to popular belief, greatness isn’t exclusive to unreal legends. Culture critic Maria Popova puts it most eloquently when she says, “Greatness is consistency driven by a deep love of the work.”

After researching stories on and conducting in-depth interviews regarding seven programmingpioneers, from computer scientist Donald Knuth to Linux’s Linus Torvalds, we uncover productivity patterns common to achieving greatness and pitfalls of which to steer clear: There’s never been a widely used programming tool that was created by just one lone wolf in a cave. Sure, Jeff Dean is the trailblazer of the famed distributed computing infrastructure upon which Google towers. Peter Norvig may be immediately associated with JSchema. David Heinemeier Hannson’s pride and joy is the Ruby on Rails framework. But each of these creators had support for their groundbreaking inventions.

Teamwork is the foundation of an empire that lone wolves simply can’t sustain. It’s why Google, home of world-renowned engineers, doesn’t tolerate lone wolves on campus. It’s the antithesis of “Googliness,” and software development in general, for two core reasons.

First, the mere proximity to other engineers fuels greatness. When Rob Pike worked at Bell Labs, well before making waves on the Unix team, he recalls fond memories of hovering around clunky minicomputers with terminals in a machine room in the Unix Room. “The buzz was palpable; the education unparalleled,: he said. “The Unix Room may be the greatest cultural reason for the success of Unix as a technology.”
Folks like Ken Thompson and Dennis Ritchie (authors of C Programming Language) would code, sip coffee, exchange ideas and just hang out in the Unix Room. It was this necessity of convening in a physical room that helped turn Unix into what it is today. Since the proliferation of PCs, however, proximity to each other isn’t as rigid in modern programming. Going out of your way to meet with smart engineers, however, is a timeless essential contributing to greatness.

Just ask Jeff Dean, the famed Googler who often is referred to as the Chuck Norris of the Internet. As the 20th Googler, Dean has a laundry list of impressive achievements, including spearheading the design and implementation of the advertising serving system. Dean pushed limits by achieving great heights in the unfamiliar domain of deep learning, but he couldn’t have done it without proactively getting a collective total of 20,000 cappuccinos with his colleagues.

“I didn’t know much about neural networks, but I did know a lot about distributed systems, and I just went up to people in the kitchen or wherever and talked to them,” Dean told Slate. “You find you can learn really quickly and solve a lot of big problems just by talking to other experts and working together.”
Second, every great coder, with however pristine a track record, must check in their code for a peer review. Pivotal Labs, the company behind the software-scaling success of Twitter, Groupon and a dozen other high-growth Silicon Valley startups, requires the freedom for any coder to look at any code. It’s simple: If code is too dependent on one person, your business is susceptible to dire wounds.
Even the great Guido van Rossum checks in his Python code, and Thompson checks in C code. Linus Torvalds, author of the biggest collaboration Open Source Software project in history, says he actually judges coders — not by their ability to code — but how they react to other engineers’ code. As a bonus, reading others’ code also can help you become a better coder. You often can see things in the source code that are left unsaid in the office.
Knuth would wholeheartedly agree. “The more you learn to read other people’s stuff,” he said, “the more able you are to invent your own in the future, it seems to me.”

When Collaboration Goes Awry

Collaboration is generally a solid learning tool, but can be catastrophic when injected at the wrong time. Hansson has seen too many Open Source Software (OSS) projects fallen victim to premature collaboration. That’s why, for the first 1.5 years of RoR’s life, Hansson had commit rights to the framework. And it took another 4.5 years before he felt comfortable collaborating with another framework to produce RoR version 3. Even then, it wasn’t easy for him.
“I’ve seen plenty of open source projects being pulled in a thousand different ways because you allow collaboration to happen too early before the culture and vision is established enough so that you can invite enough people safely into the project without them spoiling it,” he says in a Developer’s Life podcast.
Plus, the truth of the matter is, many programmers simply enjoy blasting through code alone. Solo coding is faster, short-term. You don’t have to worry about communication mishaps. And things are generally more uniform. Engineer Ben Collins-Sussman once asked a room full of programmers:

• How many of you work solo? …Crickets…

• How many of you LIKE to work solo? Nervous laughter and raised hands spread across the room.

Collaborating is a necessary evil for many of the greats, like Norvig, who is now Director of Research at Google. Norvig makes the observation that too much collaboration is also not as effective. “If you’ve got two good programmers,” he says, “it’s better for them to work independently and debug each other’s work than to say we’ll take 50% hit just for that second set of eyes. 10% of the time it’s good to sit down and have that shared understanding. But I think most of the time, you’re not going to be as effective.”
For collaborating on a project that lacks a clear vision, unlike that of Hansson, it’s good to figure out what the problem is together. Once you have an idea, great programmers divvy up the work; leave them alone to burn through the code and sync up during review. The best collaboration happens by creating a solid feedback loop, where you can catch one another’s errors before you’re too far into the project.

John Carmack, known for creating Doom, was also very wary of adding more programmers to his process of achieving his vision of great games. There was a time when Carmack wrote the majority of the basic program, he says.

Now, we’ve got lots of situations where, if something is not right, it could be like, “Oh that’s Jan Paul’s code, or Jim’s code, or Robert’s code.” It’s not so much a case where one person can just go in and immediately diagnose and fix things. So, there is a level of inefficiency.
Again, there’s a limit to what a lone wolf can do. Doom 3 required a lot more features, which meant more programmers. Carmack found this to be a double-edged sword. So, it’s manageable, he says — and necessary — in achieving a grander vision.

Jack Of All Trades And Master Of One

Most — if not all — of the seven legendary programmers had at least one thing in common: They mastered one well-defined domain, primarily using one language to carry out their work. Jonathon D. Tang pointed this out in a recent Hacker News comment, and it rings true. Knowing your language inside out is key to optimal performance. So, “read the reference, read books that not only show you the mechanics of the language but also debugging and testing,” Norvig advises. Being able to memorize the common calls for your language of choice can help expedite productivity.

Enjoyed this piece? Subscribe to our free newsletter to get new articles in your inbox.