On June 11, 2015, Bloomberg Businessweek published What is Code? a 38000 word article on the history, mechanics and culture of coding. The story generated significant notoriety for its author Paul Ford, a writer, product strategist, and programmer who was later awarded the National Magazine Award in 2016.
We recently chatted with Paul for our inaugural Meet The Experts, an interview series featuring prominent voices within the technology community. Paul shares the backstory behind What is Code, his thoughts on hiring, and what he thinks every developer should be reading (hint: you can't access it on the internet.)
Tell us how “What is Code?” came together. How did you expect folks to react to it?
[Bloomberg] asked me to write a wraparound big essay of around 6000 words to go in a special issue around technology. So I did the right thing. I turned in like 3000 words.
And they went the opposite direction. They said, “Great. How about some more words?” And so I kept going, and it was like a game of Chicken. And finally, they just sent me an e-mail. They said, “Guess what? We’re going to cut all the other articles, and it’ll be just you.”
And all I could think at that moment was, I just made so many enemies. I just had ten writers get their pieces cut, and then I’m about to write about technology for a mass audience for the nuttiest, crabbiest group of human beings on the face of the Earth, namely developers, of whom I am one, right?
So I was in a state of terror, and they just perched me in Bloomberg’s offices and said, “Here, get typing.” [After I finished], there was a brief period where I thought, “Uh-oh, what have we done?” And then it just caught fire, and it turned out that there was just an audience of people who really wanted to understand.
It was a sweet moment. I’ve never been part of anything in pop culture before. I never had anything explode, so that was interesting.
The story is written from the vantage point of middle manager interacting with a development team that he or she doesn’t fully understand. Did that idea originate from personal experience?
I work as a consultant and I have a software development firm. I’ve been the person saying [to business decision makers], “Oh, you just got to destroy your entire world and everything will be great.” I’ve [also] been on the other side as a middle manager, so I have a lot of empathy for folks in this pickle of having to spend an enormous amount of money on an abstraction that they don’t understand.
Throughout the article, you humbly downplay your coding abilities. That said, did you feel like writing this article made you a better programmer?
I feel that I became a better explainer. Soon after that piece came out, I started this company Postlight with a cofounder, and I have been working with some very good engineers for the last two years. They are very modular thinkers. They are very systematic, and they are incredibly focused on accelerating the development process.
[On the other hand], I have always been an exploratory programmer, so I learn to understand the world.
Thanks for bringing up Postlight. As you know, Thinkful is a new type of school which provides 1-on-1 learning with industry experts to deliver top tech talent to companies like yours. What qualities do you look for when hiring developers and engineers and how does that impact your hiring process?
To be clear, I don’t directly hire engineers. I meet them all before they come into our company, and I have veto power, but I am not in charge. The team hires the team because we learned really early on that it is not good for the cofounders to just jam human beings into the system. They need to come through, no matter who they are. So I don’t do the early filtering, but I’m pretty involved in the whole process.
It’s tricky because you don’t want to filter people out if they have talent. For instance, you could say, I want to look at people with Github repositories because you can look at their code. But then that cuts out anyone who doesn’t contribute to open source who could be really busy, or have kids or just not have time or not have that inclination.
There is no particular one thing you should do, but the most important thing in our world is to be able to look at code and see problem-solving ability and good code-based social skills, right? Is it clear? Is it commented? Does it show signs of someone who is working at a high intellectual level and ambitious to communicate?
What’s your opinion on white board interviews? There has been some talk recently about how they can be sort of discriminatory for people who may not necessarily have the resources to study up on certain things.
We don’t do whiteboarding. The work isn’t like that. There’s no point where I ever say to somebody, “Run to the whiteboard and write out a quickstart algorithm.” It’s completely unrealistic.
I don’t care if somebody’s using a manual. I do care if somebody’s going to have a good enough sense of the syntax of the language that they don’t have to look up how to indent in Python or if Javascript forms need brackets. I mean, the basic stuff, the basic syntax, they should have some command.
But, you know, there is going to be a new library in the next six months that overrides the old library that everybody is using, and you’re going to have to learn that, too. Honestly, someone who can read and write documentation well is more valuable to me than someone who can put algorithms on a whiteboard.
When we’re hiring, we have people build sample applications. We try to keep it something that can be done in hours, not days, and that will be relatively challenging and interesting to anybody who would really wants to do this job. So it’s a lot of that.
Whiteboard interviews is just one of the many big topics of conversions taking place in technology and web development. How do you stay up to date on the others?
There’s the thing everybody reads, right? Like everybody reads Hacker News. [However], the best thing to do is get the hell away from the Internet. No, really, like read the manuals.
The actual advice that any developer should follow is learn how to read the specifications, standards, and default documentation for the language that you’re using.
So books and manuals > the internet. What books are you reading and do you have any recommendations for our students?
It depends. I’m in a relatively unusual position in that all the books that Jeffrey Zeldman, [founder of A List Apart] produces just get mailed to me automatically. So I get to see and have access to all that stuff without thinking too much about it. But I would start there. A List Apart books are great for front end practitioners, people focused on CSS and design. It’ll get them started.
In the world of React, some of O’Reilly’s stuff is still great. [Stay away from books with titles like] “25 React Components You Need to Know” that just sort of clog everything up.
One of the great things about going back to old programming textbooks is that they don’t assume anything that people don’t know. You get a sense that the reader is understood to be like a relatively bright person who might be doing something like writing code to control a giant refrigeration system. So it’s a very kind of professional, practical style of communication without a lot, and it gets you the basics.
So everybody who is serious about programming should read books like The C Programming Language by Kernighan and Ritchie. That book has 7400 votes on Goodreads and a 4.4 rating.
Finally, we’re excited to learn that you are writing a book. What’s the plan for publication? Is it something that we can expect soon?
No, no. I’d like to get a draft done in the next couple of months. Then book publishing will probably be nine months after that, so probably a year.
We'll make sure to circle back with you then. We’d love to help you spread the word. Thanks for chatting Paul.