What I learned by reading Businessweek's incredible 38,000-word article on code Posted by Damien Biddulph on Mon 22nd Jun 2015
Bloomberg Businessweek has devoted an entire issue to a single article: Paul Ford's "What is Code?"
I read the whole thing online this afternoon, and it's remarkable. I could see it being taught in journalism classes years from now, like Gay Talese's "Frank Sinatra Has a Cold" or John Hersey's "Hiroshima."
It takes something both very important and hard to understand, and makes it understandable to an audience of smart but nonexpert readers. It does this incredibly well. It mostly feels like fun, not work.
It also contains the best use of interactive elements in a story that I've ever seen. The demos aren't just there to show off. They're embedded in the story and make it better — anybody who lived through desktop computing in the 1990s will laugh out loud at the Java "demo."
But it's long! 38,000 words or so. It took me 82 minutes to read. (Yes, the article keeps track of your activity and tells you how long it took you to get through it.)
You should read the whole thing anyway. But if you don't have time right this second, here are some highlights.
You might have heard of "frameworks" — what are they? For each language, there are multiple "frameworks," which let programmers do specific tasks without having to rewrite the exact same code over and over again. So, for instance, you might use a framework to create graphics, or build web pages, from a particular programming language.
Microsoft's skill is translating computer science into business. The essay touches only very briefly on Microsoft, claiming the company has lasted so long because it knows how to "take the sheer weirdness of computer ideas and translate them for corporations, in the language of Global Business Leadership."
Programmers are angry. Because the industry is changing so fast, their skills may already be outdated by the time they finish learning them. Also, because all code is mostly wrong and requires a ton of redoing and testing and debugging. Imagine if every time you spoke, there was a nontrivial chance that some of the words would come out slightly wrong and as a result the other person wouldn't understand you at all and you'd have to stop and fix it and say it again. That's programming.
The 10x programmer may be a myth. There are some programmers who are noticeably more productive than others, but some studies have suggested the "10x" programmer — one who can do ten times the work of another in the same period — is probably not real. Even if they do exist, they're probably running their own company or at a big software-first company like Google. They're not working for you, unless you're a 10x kind of manager at a 10x kind of company.
The best programmers are artists, not stenographers. Anyone can learn to write code. Creating the code is the easiest part of it. The best programmers see the big picture better — they're quicker to see their mistakes, and understand the broader consequences of what they're doing before they have a chance to screw anything up too badly. There's so, so much more to it, though. Now go read the whole thing-->