Coders at Work - Reflections on the Craft of Programming

Peter Seibel interviews fifteen programmers about their careers. The concept is based on Writers at Work, a collection of Q&A interviews with novelists.

Key points from the book:

  1. Read good code to improve
  2. There are no silver bullets
  3. Testing is useful for protecting complex code
  4. Knuth is referenced everywhere, use The Art of Computer Programming to improve understanding
  5. Structure and Interpretation of Computer Programs is the best book for learning to program

Jamie Zawinski

Known for leading Lucid Emacs, developing Netscape on Unix and being a prime mover behind the original Mozilla project.

At the end of the day, ship the f… thing! It’s great to rewrite the code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.

  • Lucid was a good environment because you could believe a colleagues when they say “We should do it that way”
  • At Netscape they had six months to beat the competition, they joked “We’re absolutely 100 percent committed to quality. We’re going to ship the highest-quality product we can on March 31st.” Not using C++ or threads let them ship the product on time.
  • Confident no software team has had dinner at home and slept during the night while delivering a big piece of reasonable quality software
  • Programming is like writing a story to express a concept to a very dumb person who has limited vocabulary
  • Clues to complexities of modules only appear after beginning to write code
  • Testing would have slowed them down, get it right first time to beat the competition
  • Use English words to describe variables then say in comments something that is not there already like purpose, use or range of inputs
  • Structure and Interpretation of Computer Programs for teaching programming
  • Design Patterns was useless, programming via cut and paste

Brad Fitzpatrick

LiveJournal founder.

  • Uses a spec.txt for initial planning
  • Consider interfaces first, identify the common methods, RPCs or queries.
  • Always protect clever code with tests
  • Suggest patches with “What do you guys think of this?”
  • At Google to check in you need a review, to be certified in the language (know style guidelines) and approval from one of the owners
  • Favourite interview question “given two decimal numbers as strings of arbitrary length, multiply them”
  • Could not live without debugging tool Strace. Think like a scientist and patiently change one thing at a time to understand the root cause of things.
  • Recommends Higher-Order Perl (blown away by end)
  • App Engine is a great intro to programming, Python plus one button to publish to web

Douglas Crockford

Creator of JSLint and brought JSON to public eyes. Now works on YUI.

  • A lot of JavaScript’s heritage comes from Scheme (closures)
  • Lisp and Smalltalk have brilliant ideas that are finally being factored into modern languages
  • Programmers are optimistic and they need to be
  • Code reading counters team confusion and helps weak programmers, an hour of code reading is worth two weeks of QA
  • Readability of code is now first priority, judge programs by their ability to communicate with the human reader
  • Continue statements are a sign of badly thought through code
  • Google Gears can be used for JS background processing
  • Social systems have to evolve on top of the new network infrastructure, right now the network does a poor job of necessary components including identity and security
  • Professional programmers should read Knuth

Brendan Eich

Creator of JavaScript, worked on Firefox.

Because, like the Spanish Inquisition, no one really expects floating point.

  • Dave Ungar’s papers on Self influenced design of JavaScript
  • Now JS developers make a top-level function to get a namespace, instead of the global object there should have been lexical bindings
  • Migrate to better languages but there is no silver bullet like Brooks says
  • Test-driven development is valuable, so is static analysis
  • Code now riddled with fatal assertions
  • Allergic to ivory-tower design and design patterns, Norvig wrote how design patterns are flaws in the language
  • Debugs with GDB watch-point facility on addresses or bisects with printfs, now uses Chronomancer, Replay and Helgrind — he attempts to hire Valgrind hackers
  • The worst bugs are multithreaded ones
  • Skeptical of rewrites and how they correspond with business objectives
  • Can learn a lot reading other people’s code
  • Liked Brian Kernighan’s books, Knuth, Adele Goldberg book
  • Inspired by Pirsig’s Zen and the Art of Motorcycle Maintenance

Joshua Bloch

Led design and implementation of the Java Collections Framework.

  • Make programs readable, a program is essentially a work of literature (Knuth), and use a dictionary
  • Don’t repeat yourself
  • It is easier to optimize correct code than to correct optimized code
  • Get use cases and write a skeletal API, write the code that uses the API before you write the code that implements it (ensure API method is used), you cannot get an API right until you have tried to code to it
  • Use test-first programming and refactor the APIs instead of refactoring the implementation code underneath the APIs
  • With an API, when in doubt, leave it out
  • Assertions of what must be true are too valuable to lose, always include them (even as comments)
  • Get yourself in the meanest and nastiest mood that you can (Knuth)
  • Complexity is at least quadratic in the number of language features
  • Casting is generally a bad thing, they can fail and make your program ugly
  • Writing even small programs correctly is incredibly difficult — see blog entry Nearly All Binary Searches and Mergesorts Are Broken
  • You can make a system with obviously no deficiences or no obvious deficiences (Hoare)
  • When you lose sight of who your customers are, you’re dead meat
  • Everyone should read Design Patterns and Elements of Style, also The Elements of Programming Style and The Mythical Man Month have stayed current
  • Design process is in talk How to Design a Good API and Why It Matters
  • The more things you learn and the younger you learn them, the better off you are
  • Always had one or more colleagues to bounce ideas off, feedback is critically important

Joe Armstrong

Creator of Erlang.

  • Gluing things together does not have to be complicated but there is no disconnect between gluing and the black-box innards in system architectures
  • When you program tired, you throw it all away the next day
  • Beware of slight spelling errors in variable names – use personName and listOfPeople, not personNames
  • Write test cases then write the code
  • If you want to understand C, write a C compiler, ditto for other languages
  • Explicitly required branch matching after reading about Dijkstra’s guarded commands
  • All errors will be within three statements of the place you last changed the program
  • Pair programming is good with two programmers of similar ability, who both are figuring out what to do
  • Spend a day a week learning new stuff, 20% a day compounds to knowing twice as much as colleagues over 4 years, also read Hamming’s paper
  • Code is beautiful when you cannot remove anything
  • Wants to read Structure and Interpretation of Computer Programs to his kid

Simon Peyton Jones

Lead architecture of Glasgow Haskell Compiler.

  • With research, “Just start something, no matter how humble” (John Washbrook)
  • “Functional program is the way of the future” (John Backus, inventor of Fortran)
  • Importance of laziness explained in John’s Hughes paper Why Functional Programming Matters
  • Read Programming Pearls, Writing Programs for ‘The Book’, Purely Functional Data Structures, SICP, Compiling with Continuations, A Discipline of Programming (obviously no bugs)
  • The paper The Computer Scientist as Toolsmith (Brooks) is useful for remembering that we are concerned with building things

Peter Norvig

AI expert, Head of Research at Google.

  • In industrial programming, must learn about having schedules and keeping people happy (team members, customers, managers)
  • Programmers need bravado but to be really good, you have to test against the failure cases
  • A good programmer must make progress then improve on it (in life too)
  • Recognize when there is likely a known solution
  • Heathrow failure mode impressed Norvig, off-site computer produced print outs of all flights during power failure
  • Provide the solution that makes the most sense, normally cannot afford to do the perfect solution (diminishing returns after 80%, Pareto)
  • Mars Climate Orbiter needed closer communication with outsourced team (output/input units differed)
  • Often ends up rewriting, throwing away a couple of hundred lines of code, to fix bugs
  • Does not know PHP and JavaScript
  • Knuth is good to know everything but often you want to know if A is better than B or just the asymptotic complexity
  • Getting a 1 in one of your interviews ia good indicator for success at Google
  • Sally Goldman has a practical take on algorithms

Guy Steele

Programming polyglot that contributed to Common Lisp and Scheme.

  • Becoming a student member of ACM was very important
  • Reads code by picking an interaction and following the debug trace, source of TeX is well-thought-out and well-debugged, also George Hart’s VRML polyhedra
  • Languages are now too big to design/implement at once, and have to develop through evolution
  • Huffman encoding problem with programming languages, making something more concise makes something else more verbose
  • State purpose and reference source algorithms in comments
  • Learned how to sort from the Aho, Hopcroft and Ullman algorithms book, lots of interesting aspects found in Triple-I Lisp

Dan Ingalls

Smalltalk’s father.

  • Thinks web should be static content on top of graphics rather than the other way round
  • Browsers will change and provide other languages than JavaScript
  • Set up projects for immediate gratification, find the first piece of success that is achievable
  • Have a clear picture as a team, then you can have confidence in the work teammates are doing
  • Smalltalk debugger allowed you to save entire state and send to another machine on a different architecture
  • Recommends Val Schorre’s META II paper, the LISP 1.5 book

L Peter Deutsch

Prodigy, worked on Project Genie, author of Seven Fallacies of Distributed Computing, wrote Ghostscript.

  • To be a technical master you need to 20000 specific cases to call at will
  • You can understand the physical world in aggregate but not software
  • Concerned about XP because it is documentation phobic — is it maintainable and supportable?
  • Mistake making Ghostscript pixel-orientated not plane orientated because of zero acquaintance with the printing industry
  • Requirements always change in unexpected directions
  • Well-designed objects are reusable and pay for themselves down the road
  • Theorem proving has failed to improve software because it is too difficult to formalize the properties of the program that you want to establish
  • Once offended by anything done badly but realised this mindset was child-like

Ken Thompson

The original UNIX hacker.

  • Wish he had taken typing
  • Writes down data structures before writing code
  • Codes as simply as possible and very often that suffices for all time
  • Interviews candidates by asking for details of their most interesting program
  • Yacc is wonderful and Lex is horrible
  • Cannot live under constant extreme deadlines (80h/100h), they are normally continual and you have less enthusiasm after each one

Fran Allen

First woman to win Turing award, developed Static Single Assignment intermediate representation.

  • Learn a new language by taking an existing program and studying it
  • Encourage young people not to jump into management, get a reputation for technical work first
  • Need involvement of women in technology to make products for all areas of society
  • Computers will make people far more creative (Isaac Asimov)

Bernie Cosell

Developed Interface Message Processors on the original ARPANET.

  • Rewrote code to fix bugs instead of understanding it
  • Write lots of programs to become a good programmer
  • Achieve at work by studying at the weekend to learn faster
  • Design reviews are a good use of senior talent, double-check parts they think are correct and give insight on parts that are not
  • Programs ought to make sense, there are very few inherently hard problems

Donald Knuth

Author of The Art of Computer Programming, wrote TeX and METAFONT.

  • We will always have bugs if we stretch our capabilities, people jumping on silver bullet bandwagons will always be disappointed
  • If you understand how inventors made discoveries, their process can assist your discoveries
  • Reading source code is worth it for what it builds in your brain, Bill Atkinson’s programs are now publicly available thanks to Apple (well-documented, pioneering graphics)

See also