Mark Geller

Recently I began reading “Coders At Work, Reflections on the craft of programming,” by Peter Seibel. The format of the book is based on the earlier work by Jessica Livingston, “Founders at Work,” in which Ms. Livingston interviewed founders from a dozen or so successful startups on the details of their approach to starting companies.

In Coders, Peter Seibel interviews 15 of the most well-known and respected coders from various disciplines, ranging from relatively younger coders leading the development of scalable web technologies such as Brad Fitzpatrick and Jamie Zawinski to the gods of the craft including Donald Knuth and Peter Norvig.

For any product managers or founders starting web-based companies, I would recommend Coders At Work as required reading. Even if you never plan to write commercial code yourself–although you ARE writing some functional Python apps at least, I hope!–reading this book will give you greater insight into the issues and approaches of your technical partners. It will increase your credibility with your team members, partners, and investors and give you a better basis to identify and manage the technical risks of your project, and maybe a greater ability to create innovations that move your product or your company forward. Here are some of the salient points I have noticed through the first 5 interviews:

• In the past two decades, as software development has become more de-centralized and collaborative (and as processors have gotten faster), writing highly readable code has become at least as important as writing code that is particularly fast or intricate.
• There is no single programming language that is best for all tasks–newer coders should learn several languages to understand the strengths and weaknesses of each.
• Coders are not interchangeable, even the best programmers are better at some things than others. For example, someone who is a genius at developing core libraries may not be as strong for building user interfaces–it is important for engineering managers to make sure developers are working on projects that leverage their strengths.
• Many of the top developers consider writing code as essentially a different form of literature–and the ability to write precise and accurate prose is at least as important as advanced computer science for becoming an excellent  and highly productive coder.
• The development of technology does not necessarily move only forward over time to greater productivity and usefulness–sometimes there are significant detours on the way. For example, the trend toward (and, recently, away from) user’s running private environments on their own individual PCs in many ways slowed or reversed earlier progress that had been made in allowing users to interact socially with each other and provide security from viruses and other attacks. Some of the concepts we think of as recent innovations were actually invented in languages 20 to 30 years ago and are only now re-emerging in usable form.
• One of the best ways to build an application is to start with the API (application programming interface), that provides the interface through which your own program and those of others will interact with your main code. Create the use cases for accessing your code through the API first to confirm the design, then build out the main processing functionality.

There are some sections that delve into greater technical detail for sure, although even skimming these will give you a greater context for understanding development. For example, while reading the interview with Brad Fitzpatrick, who created LiveJournal and is now a top coder at Google, I first came across the Perlbal and Memcached technologies, which Fitzpatrick developed out of necessity to scale LiveJournal, and that now have become the de facto standard for scaling web services of all kinds (including Facebook). The very next day I was reading the (excellent) overview on Djangobook.com on how to scale a Django-based web site and there was a detailed section on implementing memcached.

In any case, even if you skim the technical sections, this is a great book for getting a better feel for the issues and dynamics of building and running scalable software technologies. If you want to build better software and have a better time doing it, I recommend it.