Legendary Productivity And The Fear Of Modern Programming

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. The greatest programming minds are capable of using software to multiply massive integers that are bigger than the universe.

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 of programming. 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 programming pioneers, 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.

 

But it can get really comfortable (or boring) really fast if you stick to just one set of tools and domain. So, after mastering one definitive domain, most of them have experience in switching contexts, which helps them open their minds and see things in a different way.

For instance, John Carmack switched from creating video games to Oculus for virtual reality. LIkewise, Rob Pike moved from Plan 9 to Go. Andy Hertzfeld transitioned from writing the original Mac system software in assembly to writing the Google+ Circle Editor in JavaScript. “But rarely do the greats ever try to juggle multiple platform at the same time,” Tang said in a follow-up email. Delving into new domains after mastering one helps you see things in different levels.

Visualizing The Program In Your Brain

Nearly every programming legend points to the importance of visualizing solutions and being able to hold programs in your head. There’s a lot of productivity lost when you dive into code or start testing without first developing a mental model of the solution.

Carmack’s ability to hold gaming concepts is among the most remarkable, considering just how massively complex the virtual world of gaming is. “A video game’s program is actually more complex than that of space shuttles sent to the moon and back,” he said in an interview. Paul Miller helps put his work into context. When manipulating light beams to create a virtual world, he renders an image at least 30 times a second to prevent the game from breaking. This adds up to a trillion calculations per second. Meanwhile, Disney’s Pixar takes 10 hours to render a single frame. In video games, you’ve got just milliseconds to make an impact.

Given the extensiveness of video game programming, Carmack says, “being able to clearly keep a lot of aspects of complex system visualized is valuable. Having a good feel for time and storage that are flexible enough to work over a range of 10 orders of magnitude is valuable.”

Interestingly enough, Knuth, Norvig, Dean, Pike, Torvalds, Thompson and Hansson have all at one point said they’re believers of having a strong mental model, focus and visualization. It’s all about the ability to see the solution before diving into the problem.

The best concrete example comes from Norvig. He once was tasked to write a Sudoku-solver program. From the get go, he knew from his AI knowledge that the combination of field of constraint propagation and recursive search would solve the problem. Meanwhile, another programmer tested all sorts of code on his blog, but never really solved anything. It’s perfectly possible to write correct, tested code without correctly approaching the problem.

Herein lies the key to approaching the problem correctly. “I think it’s useful to imagine the solution, to see if it’s going to work,” said Norvig. “It’s useful to see if it feels comfortable.”

There’s Joy Inside The Black Box

In Coders at Work, Knuth expresses a major concern for the future of programming if young programmers are simply assembling parts without studying them. The neatly packaged boxes might be a good short-term solution for speed, but programmers will lack the grand visualization that’s necessary for true progress in programming. Plus, it’s just not as fun to copy/paste commands without knowing the fundamentals of why and how it’s happening.

“If the real case takes a certain time, t, then the complex case takes time 4t. But if you’re allowed to open the box, then you’ll only need three real matrix multiplications instead of four because there’s an identity that will describe the product of two complex matrices,” Knuth explains.

In fact, the very purpose of Knuth’s most famous work, The Art of Programming, helped programmers learn how and why data structures worked. “So my book sort of opened people’s eyes: ‘Oh my gosh, I can understand this and adapt it so I can have elements that are in two lists at once. I can change the data structure.’ It became something that could be mainstream instead of just enclosed in these packages.”

Comparing it to mathematics, it wouldn’t be fun to simply get the right theorem for the right problem each time. The joy comes from trying various theorems, visualizing what might work and getting that thrill when it finally does. Norvig shares this concern and stresses that programmers need to ask more questions before copy/pasting black boxes.

Sure, the code might have worked once, but what are the failure cases? Is it consistent? Are there other scenarios for expanding functionality? How can you understand it better? Simply relying on prepackaged boxes to carry out a command can be tedious and mundane. It’s more fun to problem-solve, think critically and learn the mechanisms of why code strung together is performing in a certain way.

Thompson is downright fearful of modern programming because it’s made up of layers upon layers upon layers. “It confuses me to read a program which you must read top-down. It says ‘do something,’ and you go find ‘something’ and it says ‘do something else’ and it goes back to the top maybe. And nothing gets done. I can’t keep it in my mind — I can’t understand it.”

While frameworks, APIs and structures might make programmers feel more productive, true productivity comes from unpacking the containers and truly understanding what’s inside. Only then can you build upon your knowledge and continue to push the limits of what human beings can achieve.

The greatest engineers who have brought us this far in software grew up in an entirely different era of computing — packed inside rooms filled with terminals, carrying mental models of new algorithm-based programs. Newer generations of programmers are born into a more fragmented world. The programs today are far too large to carry in our minds. Plugging in black boxes can get you to a certain point — very quickly — but the greatest programmers will always be bored with redundancy. True greatness comes with consistent drive to seek new problems with like-minded programmers, be able to see the floor before the roof and stay curious about what’s inside the black box.