DFectuoso.com

Number: 2 of 36 of 2010

Title:

Coders at work reflections on the craft of programming

Author: Peter Seibel

Link: Amazon

Score: 11 where 10 is super great.

Comment:

This book, for me, was life changing.

Its definitely a very long book, and it contains a couple of controversial point about complex and abstract topics of programming, code, algorithm, systems, platforms and everything related with bits and bytes. Normally this would be “bad” but it comes from some of the top programmers of all times, interviewed by one of them.

The questions are great, and the answers are just incredible interesting. It motivated me to be a better programmer in all the layers that this profession has to offer. From well written code, to testing to algorithm, to life balance and how to change the world.

It would be fool of me to try to explain or summarize everything in this book, the only thing I will do is expose some of my favorite quotes and recommend it to everyone that loves code and programming.

Quotes:

This are the quotes that I marked as interesting, polemic or just worth tattooing to remembering daily, of course they are taken out of context so you know what that means.

About the importance of shipping version 1:

Seibel: Over engineering seems to be a pet peeve of yours.

Zawinsky: Yea. At the end of the day, ship the fucking thing!

About quality and shipping:

(Zawinsky: ) … One of the jokes we made at Netscape a lot was: ‘We are absolutely 100 percent committed to quality. We are going to ship the highest quality product we can on March 31^st’

About open source and how to approach a community:

(Fitzpatrick: ) I find that is the best way to start a conversation. If you get on a mailing list and you are like ‘hey I want to add feature X’ the maintainer is probably going to be like: ‘ Oh fuck, I am so busy, go away, I hate feature X’. But if you come to them and you are like ‘I want to add feature X. I was thinking something like the attached patch’ which is totally wrong but you say, ‘But I think its totally wrong. I am thinking the right way might be to do X’ which is some more complex way, generally they will be like ‘Holly crap, they tried and look, they totally did it the wrong way. Maybe that pains the maintainer. They are like ‘ Oh man, I can’t believe they went through all that effort to do it. Its so easy to do the right thing,’ and then they reply.”

About code reading (in public) as code review:

(Crockford: ) I think an hour of code reading is worth two weeks of QA

About good code:

(Crockford: ) By good code, I mean it is going to be readable. …. Almost as important as being correct …

About refactoring:

(Crockford: ) Six cycles – whatever the cycle is between when you ship something. If you are on a monthly delivery cycle then I think every half year you should skip a cycle and just spend time cleaning the code up

About focusing in the details(of all the code) after refactoring:

(Bloch: ) I think people who say, ‘Oh it is not worth the time; it is just the name of a variable’ just don’t get it. You are not going to produce a maintainable program with that attitude

About good software:

(Bloch, quoting to a Tony Hoare) One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

About programming level and knowledge:

(Peter Norvig: ) And part of it is an educational problem, but if you have a bunch of programmers who don’t understand what a monad is and haven’t taken courses in category theory, there’s a gap

About optimizing:

(Steele: ) It is easy to become too fixated on optimizing something just because you can, even though it is not what you need to work on

About academia and industry:

(Ingalls: ) I hate to see computer science departments that feel their role is to prepare people to work in an industry and the industry is going that way and therefore we have to teach our students that way

Some start big (and young):

Seibel: Do you remember at all how you designed?[when you where 15] your PDP-I Lisp

Deutsch: I am smiling because the program was so small. Have you seen the listing? It is only a few hundred lines of assembler

About code reliability down the plumbing:

(Peter Deutsch: ) I do know that the further down in the plumbing the software is, the more important it is that it be build by really good people. That is an elitist point of view, and I am happy to hold it.

About correctness and testing:

(Peter Deutsch: ) My PhD thesis was about proofs of program correctness. I don’t use that term anymore. What I say is you want to have your development system do as much work as possible toward giving you confidence that the code does what you intent it to do

About debugging:

(Ken Thompson: )Mostly I just print values. When I am developing a program I do a tremendous amount of printing. And by the time I take out, or comment out, the prints it really is pretty solid. I rarely have to go back. …. Because when you print you actually see what it is as opposed to it being a particular value, and you print a bunch of stuff that aren’t invariants. It is just the way that I do it. I am not proposing it as a paradigm. It is just what I have always done

About optimizing:

(Ken Thompson: ) Ninety-nine percent of the time something simple and brute-force will work fine. If you really are building a tool that is used a lot and it has some sort of minor quadratic behavior something you have to go in and beat on it. But typically not. The simpler, the better.

About programming principles:

(Cosell: ) I really believed that computers were deterministic, that you could understand what they were supposed to do, and that there was no excuse for the computers not working, for thing not functioning properly. …. Really what I was, was a very careful programmer with the arrogance to believe that very few computer programs are inherently difficult.

About what to do after refactoring:

(Cosell: ) If you knew then what you know now about the fact that this piece of code is broken, how would you have organized this piece of the routine

About programming now:

(Knuth: ) I am worried that it is becoming too boring because you don’t have a chance to do anything much new. Your kick comes out of seeing fun results coming out of the machine, but not the kind of kick that I always got by creating something new.

About reading code:

(Knuth: )don’t only read the people who code like you.

Ideas:

When I look at what Progrium is doing with web hooks and simple APIs as a way to create building blocks that we can all use to create some wonderful, secure and simple  stuff, I cannot stop myself to note Ingalls quote somehow related:

(Ingalls: ) It should be like the Internet all the way down. We worry about where we have security and various sorts of security mechanism in programs and there are all sorts of thing wrong with tem. But the Internet- style separation is a real layer that there is no way around

Peter Norvig explains a very interesting example about how a communication error caused a NASA project to fail. If 1 unattended thing can cause a NASA project to fail, imagine what it can do for a simple startup.

(Peter Norvig: ) ‘Oh, I guess Lockheed-Martin must have solved this problem’ and Lockheed says ‘Oh, JPL’s not asking anymore – they must not be concerned’

Finally I think one of the most motivating, most simple and cool things I have ever analised is Simon Peyton Jones take on how to get into research. I think it applies for open source code, programming, web development, game development and any kind of cool activity:

(Simon Peyton Jones: ) ‘Just start something, no matter how humble’… Once you start the mill turning then computer science is very fractal – almost everything turns out to be interesting, because the subject grows ahead of you. It is not like a fixed thing.

Books (or stuff) I will consider reading after this one(because they where recommended or mentioned and I found them interesting):

• MJD’s Higher-Order Perl
• Design Patterns
• Elements of Style
• Hackers Delight
• “Hamming’s advice to young researchers”
• Purely Funcional Data Structures
• Compiling with Continuations
• Discipline of Programming
• Sally Goldman’s new book about practical take on algorithms
• Peter Norvig’s Sudoku
• Peter Deutsch PDP-I List listing

Recommend: If you love programming you must read this book.