Rate this book

Coders At Work: Reflections On The Craft Of Programming (2009)

by Peter Seibel(Favorite Author)

3.95 of 5 Votes: 3

ISBN

1430219483 (ISBN13: 9781430219484)

languge

English

genre

History & Biography

publisher

Apress

review 1: A fun read to hear the stories of famous programmers and to understand how they think about their specialties. It's inspiring to see that almost all of them come across as normal, humble people that are started like everyone else. Unfortunately, not all the interview questions brought out interesting responses: the questions that focused on the programmer's expertise and history were great; the canned/rigid questions like "how do you read code" or "do high level degrees matter" were less great, often resulting in "it depends" or vague answers. Some fun quotes from the book:Zawinski: Your competitor’s six-month 1.0 has crap code and they’re going to have to rewrite it in two years but, guess what: they can rewrite it because you don’t have a job anymore.Zawinski: I fi... morend that getting something on the screen as soon as possible really helps focus the problem for me. It helps me decide what to work on next. Fitzpatrick: In practice, nothing works. There are all these beautiful abstractions that are backed by shit. The implementation of libraries that look like they could be beautiful are shit.Seibel: any piece of code contains bits of embedded knowledge—little bits of cruft that are hard-won functionality that you don’t think of when you say, “Oh, we can just rewrite this.”Crockford: I haven’t figured out a sufficiently useful way of testing units of JavaScript yet.Eich: While producing a lot of code is still important, what has interested me—and this is something that we talked about at Netscape when we talked about their track for principal engineer—is somebody who isn’t management but still has enough leadership or influence to cause other programmers to write code like they would write without them having to do it, because you don’t have enough hours in the day or fingers.Bloch: when you choose a language, you’re choosing more than a set of technical trade-offs—you’re choosing a community. It’s like choosing a bar. Yes, you want to go to a bar that serves good drinks, but that’s not the most important thing. It’s who hangs out there and what they talk about. And that’s the way you choose computer languages. Over time the community builds up around the language—not only the people, but the software artifacts: tools, libraries, and so forth. That’s one of the reasons that sometimes languages that are, on paper, better than other languages don’t win—because they just haven’t built the right communities around themselves.Bloch: Many customers won’t tell you a problem; they’ll tell you a solution.Bloch: But the fundamental rule is, write the code that uses the API before you write the code that implements it.Bloch: there are some people who, in Kevin Bourrillion’s words, “lack the empathy gene.” You aren’t going to be a good API designer or language designer if you can’t put yourself in the shoes of an ordinary programmer trying to use your API or language to get something done.Armstrong: To me programming isn’t about typing code into a machine. Programming is about understanding.Armstrong: the central core of functional programming is the idea of nonmutable state—that x isn’t the name of a location in memory; it’s a value.Armstrong: Then there’s—I don’t know if I read it somewhere or if I invented it myself—Joe’s Law of Debugging, which is that all errors will be plus/minus three statements of the place you last changed the program.Armstrong: The code shows me what it does. It doesn’t show me what it’s supposed to do. I think the code is the answer to a problem. If you don’t have the spec or you don’t have any documentation, you have to guess what the problem is from the answer. You might guess wrong. I want to be told what the problem is.Armstrong: You were asking earlier what should one do to become a better programmer? Spend 20 percent of your time learning stuff—because it’s compounded.Armstrong: I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions — all the data comes in its input arguments and everything goes out and leave no state behind — it’s incredibly reusable.Jones: This was my main insight about small companies: to be an entrepreneur you need to get energy from stressful situations involving money, whereas my energy is sapped by stressful situations involving money.Jones: when the limestone of imperative programming is worn away, the granite of functional programming will be observed.Jones: One thing that is hard, even for professional software engineers and developers, is to viscerally grok the size of the artifacts on which we work. You’re looking at the Empire State Building through a 1-foot-square porthole, so it’s difficult to have a real feel for how gigantic the structure you’re looking at is. And how it’s interconnected.Deutsch: Language systems stand on a tripod. There’s the language, there’s the libraries, and there are the tools. And how successful a language is depends on a complex interaction between those three things.Allen: Part of it is that there’s the potential for new ideas every day. One sees something, and says, “Oh, that’s new.” The whole field gets refreshed very frequently. It’s very exciting to think about what the potential for all of this is and the impacts it can have.Isaac Asimov made a statement about the future of computers—I don’t know whether it’s right or not—that what they’ll do is make every one of us much more creative. Computing would launch the age of creativity.Knuth: I think that’s a fundamental error made by scientists in every field. They don’t realize that when you’re learning something you’ve got to see something at all levels. You’ve got to see the floor before you build the ceiling. That all goes into the brain and gets shoved down to the point where the older people forget that they needed it.Knuth: I try to give the key ideas and I try to simplify them the best I can, but then what happens is every five pages of my book is somebody’s career.Knuth: The first rule of writing is to understand your audience—the better you know your reader the better you can write, of course. The second rule, for technical writing, is say everything twice in complementary ways so that the person who’s reading it has a chance to put the ideas into his or her brain in ways that reinforce each other.Knuth: Pretty much a constant in my experience, over a long period of years, is that every time I’m exposed to 100 people from some population or other, except majors in computer science, 2 of them are programmers in the sense that they really resonate with the machine.
review 2: One of my all-time favorites. Peter Seibel really assembled THE most interesting people for his interview - and interesting mixture between old and young (Brad Fitzpatrick), and even the first woman in CS - Fran Allen. I was delighted to see that my top 3 CS idols (Donald Knuth, Brendan Eich, and Ken Thompson) were part of his vaudeville.Seibel really kept the flow interesting and found the right tone the most out of his interviewees and almost had the perfect timing to switch between topics. It was an interesting read where I learned much about the backgrounds of those accomplished people, gained insights of how they think and work, and to some extend found useful information here that can help me throughout my own career. less

Download links for: Coders at Work: Reflections on the Craft of Programming

Advertising