Coders at Work: Reflections on the Craft of Programming

by Peter Seibel

But that's not the point-you're not here to write code; you're here to ship products.

If you don't understand how something works, ask someone who does.

I remember thinking that was a really good book, not because I learned anything from it, but because it was the book you wish your idiot coworker had read.

remember that guy. He was awesome. He was fun, friendly, and attentive, and he really cared about his code. He was really passionate when people complained about it. I'm going to use that one because if I find any bugs, I know he'll be crazy about fixing them. As opposed to the grumpy guy who maybe writes great code, but he's grumpy and not fun to interact with if you have a question or a bug. So you pick maintainers you trust

First thing I'll do is make the punctuation conform; get the indentation right; do all that stuff. I have programs that can do that for me, but I find doing that myself is more efficient in the long run because it gets me more acquainted with the code.

skip a cycle and just spend time cleaning the code up.

there's a big gulf between industry and academia: the academics are doing proofs, sometimes by hand, more and more mechanized thanks to the POPLmark challenge and things like that. But in the real world we're all in debuggers and they're pieces of shit from the 70s like GDB.

But if you really are trying to move a needle and you don't know exactly what you're doing, rewrite.

write the code that uses the API before you write the code that implements it. Because otherwise you may be wasting your time

The fundamental theorem of API design is, when in doubt, leave it out.

There's a wonderful Knuth quote about testing, quoted by Bentley and Mcllroy in their wonderful paper called "Engineering a Sort Function," about getting yourself in the meanest and nastiest mood that you can.

"Rather than have a complete specification from the start, just get customers in the room and start brainstorming."