Coders at Work by Peter Seibel
Today, I finished reading the book Coders at Work by Peter Seibel and I found it really enjoyable. Coders at work is a series of interviews with great programmers and computer scientists. If you are somehow a technical person, needs some inspiration or just aspire to be better, I highly recommend you the book.
You will find information about their careers, their thoughts on the software profession and industry and how they consider programming. Programming is art, craftsmanship, science or engineering?.
They also talked about code readability, debugging strategies, testing, language design, job interviews, computer science books worth reading, teamwork, problems at work, how they got into programming and even hobbies.
Here is the list of the fifteen people interviewed. I summarized their main contributions and creations.
- Jamie Zawinski (Lisp hacker, early Netscape developer, Mozilla contributor, XEmacs and XScreenSaver creator ).
- Brad Fitzpatrick (Memcached, LiveJournal, Perlbal and MogileFS creator, Engineer at Google working in the Go programming language).
- Joshua Bloch (Ex Java architect at Google, Ex engineer at Sun Microsystems, “Effective Java” book author, Java Collections framework creator).
- Joe Armstrong (Erlang and Open Telecom Platform creator).
- Simon Peyton Jones (Haskell programming language co-creator, architect and lead developer of the Glasgow Haskell Compiler).
- Peter Norvig (Director of research at Google, ex head of the Computational Sciences Division at NASA, JScheme co-creator).
- Guy Steele (Common Lisp dialect and Scheme programming language co-creator, “The Hacker’s Dictionary” book author).
- Dan Ingalls (Smalltalk designer and exceptional contributor, Squeak co-creator, Lively kernel creator, Ex distinguished Engineer at Sun Microystems).
- L Peter Deutsch (Lisp hacker, Ex Chief Scientist at PARC, Ghostscript creator).
- Ken Thompson (Unix co-inventor, Bell Labs, B programming language creator, UTF-8 encoding definition, Distinguished Engineer at Google, Go programming language co-creator).
- Fran Allen (Ex programmer at IBM Research, Compiler expert, first woman to win the “Turing Award”, Fellow of the IEEE, IBM and ACM).
- Bernie Cossel (Ex MIT and BBN great programmer, Arpanet IMPs designer, DOCTOR creator, master debugger).
- Donald Knuth (“The Art of Computing Programming” author, TeX and MetaFont creator, Computer Science major contributors).
If I had time, I will be writing the most interesting things they said. For now, I will write some quotes from Brad Fitzpatrick, one of the interviews that I really liked the most. He’s really funny and a common-sense person. Here we go…
Here are some of the Brad’s words that I consider really interesting to apply in our everyday programmer’s life:
– I like programming because it was just always fun.
– One of the interview questions I give people is: Write a class to do arbitrary, bigint manipulation with multiplication and division. If I did it in high school, they should be able to do it here.
– Anytime I do something clever, I make sure a have a test in there to break really loudly and to tell others that they messed up.
– I had to force a lot of people to write tests, mostly people who were working for me. I would write tests to guard against my own code breaking, and then once they wrote code, I was like, “Are you even sure that works? Write a test. Prove it to me.” At a certain point, people realize, it does pays off, especially maintenance cost later.
– Java has gotten faster and the JVM has gotten a lot of smarter.
– I personally, don’t find it that annoying to manage memory, at least in C++ with like scoped pointers.
– The original Memcached was written in C and I rewrote it inside Google in C++ to work with Google infrastructure and to add it to App Engine.
– I think it’s important to know the whole stack, even if you don’t operate within the whole stack.
– You have to plan for the day when your data doesn’t fit into one database.
– I definitely try to find an excuse to use anything to learn it. Because you never learn something until you have to write something in it. You have to live it and breath it.
– It’s one thing to go learn a language for fun, but until you write some big, complex system in it, you don’t really learn it.
– I get frustrated if people don’t understand at least the surface of the whole stack.
– If you’re the one responsible for the cost of buying servers, it helps to actually know what’s going on under the covers.
– Python it’s perfect, it’s a great intro to programming, there are so many layers and layers of bullsh*t that it gets rid of.
– In college, half the classes I totally loved. I didn’t have the vocabulary to describe what I was doing. Formal CS education helped me be able to talk about it.
– I’m kind of sad I left college and I felt I only did half studying, because so much of it I really knew.
– My friends and me still forward each other papers around, neat papers from academy and industry. But it’s more interesting to read the industry ones, because you know they did it to solve a problem.
– I design software starting with interfaces between things. If it’s storage, I try to think, what are the common queries?. Then I write dummy mocks for different parts and flesh it out over time. I always start with a spec.txt in the design.
– Always try to do something a little harder that is outside your reach. Read code.
– I was sending patches to Gaim, the GTK messenger thing and other Open Source projects. After looking at others people code, I was starting to see patterns. “Oh OK. I understand the structure that they’re going with”. I see how this pays off.
– In the Open Source, When I fix a bug in a product, the first thing I do is send a patch and just say: “What do you guys think of this?”.
– Sometimes I read code for fun. I checked out Android source code for no real reason. The same with Chrome; when it went Open Source. I mirrored the repo and just looked around. I did the same thing with Firefox and Open Office. Some program you’ve been using and all of a sudden you have access and you might as well look.
– It’s really important to have a style guide and respect the style of code written in all files and the whole project than to do it your favorite way.
– Pair programming it’s pretty fun. It forces me to sit down for solid hours and work on one thing and other one forced me to not be bored and finish.
– A friend had some Iptable rule that on connection to certain IP addresses between certain hours of the day would redirect to a “You should be working” page. Sometimes, I think I really need it.
– In Google, nobody owns a code, there’s one massive source tree, one root, and one unified build system across all of it. And so anyone can go and change anything. But there are code reviews, and directories have owners, always at least two people. To make a change you need:
- Someone to review it.
- To be certified in the language. (Readability).
- Approval above from somebody in the owners file.
– At night, there’s no noise and no interruptions, and I can do whatever.
– I have a learning in Human Resources, that some people just do what they’re told and don’t really have a passion for excellence. They’re just like: “Done, next assignment”.
– I recognize a great programmer by looking for people that have done a lot of stuff on their own. Somebody who was passionate about something and had some side project.
– I love Strace (Debugging tool), I don’t think I could live without it.
– If there’s something weird going on, I’m like: OK that function is too big, let’s break that up into smaller parts and unit-test each one separately.
– Having users is a key to getting contributors. More users find more bugs and find more use cases.
– You pick Open Source projects, because you trust and respect the maintainer. He’s awesome, fun, friendly, attentive and really cared about his code.
– Whenever I write something to automate my life, it always pays off.
– Most important skills for a programmer:
- Thinking like a scientist, changing one thing at a time.
- Patience and trying to understand the root cause of things.
- Try to figure out what’s going on. Learn how to write things incrementally, so that at each stage you could verify it.
– Communication is an skill, apart from programming, a programmer should develop. Written communication style goes a long way.
– I wrote a solver for a board game, that was a fun hack.