Coders at Work Quotes

“The most depressing thing about life as a programmer, I think, is if you're faced with a chunk of code that either someone else wrote or, worse still, you wrote yourself but you no longer dare to modify. That's depressing.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I sometimes feel a bit afraid about the commercial world with, on the one hand, the imperatives of getting it done because the customer needs it next week and, on the other hand, the sheer breadth rather than depth of the systems that we build.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Peyton Jones: For me, part of what makes programming fun is trying to write programs that have an intellectual integrity to them. You can go on slapping mud on the side of a program and it just kind of makes it work for a long time but it's not very satisfying. So I think a good attribute of a good programmer, is they try to find a beautiful solution. Not everybody has the luxury of being able to not get the job done today because they can't think of a beautiful way to do it.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I think the primary limitation on software is not the speed of computers but our ability to get our heads around what it's supposed to do.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Seibel: What's your desert-island list of books for programmers? Peyton Jones: Well, you should definitely read Jon Bentley's Programming Pearls. Speaking of pearls, Brian Hayes has a lovely chapter in this book Beautiful Code entitled, “Writing Programs for ‘The Book’” where I think by “The Book” he means a program that will have eternal beauty. You've got two points and a third point and you have to find which side of the line between the two points this third point is on. And several solutions don't work very well. But then there's a very simple solution that just does it right. Of course, Don Knuth's series, The Art of Computer Programming. I don't think it was ever anything I read straight through; it's not that kind of book. I certainly referred to it a lot at one stage. Chris Okasaki's book Purely Functional Data Structures. Fantastic. It's like Arthur Norman's course only spread out to a whole book. It's about how you can do queues and lookup tables and heaps without any side effects but with good complexity bounds. Really, really nice book. Everyone should read this. It's also quite short and accessible as well. Structure and Interpretation of Computer Programs. Abelson and Sussman. I loved that. And Compiling with Continuations, Andrew Appel's book about how to compile a functional program using continuation passing style. Also wonderful. Books that were important to me but I haven't read for a long time: A Discipline of Programming by Dijkstra. Dijkstra is very careful about writing beautiful programs. These ones are completely imperative but they have the “Hoare property” of rather than having no obvious bugs they obviously have no bugs. And it gives very nice, elegant reasoning to reason about it. That's a book that introduced me for the first time to reasoning about programs in a pretty watertight way. Another book that at the time made a huge impression on me was Per Brinch Hansen's book about writing concurrent operating systems. I read it lots of times.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“A sequential implementation of a double-ended queue is a first-year undergraduate programming problem. For a concurrent implementation with a lock per node, it's a research paper problem. That is too big a step. It's absurd for something to be so hard. With transactional memory it's an undergraduate problem again.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“But if you ask me, is STM better than locks and condition variables? Now you're comparing like with like. Yes. I think it completely dominates locks and condition variables. So just forget locks and condition variables. For multiple program counters, multiple threads, diddling on shared memory on a shared-memory multicore: STM. But is that the only way to write concurrent programs? Absolutely not.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Peyton Jones: I think my default is not to write something very general to begin with. So I try to make my programs as beautiful as I can but not necessarily as general as I can. There's a difference. I try to write code that will do the task at hand in a way that's as clear and perspicuous as I can make it. Only when I've found myself writing essentially the same code more than once, then I'll think, “Oh, let's just do it once, passing some extra arguments to parameterize it over the bits that are different between the two.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Peyton Jones: I think probably the big changes in how I think about programming have been to do with monads and type systems. Compared to the early 80s, thinking about purely functional programming with relatively simple type systems, now I think about a mixture of purely functional, imperative, and concurrent programming mediated by monads.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“The code shows me what it does. It doesn't show me what it's supposed to do.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Seibel: What are the techniques that you use there? Print statements? Armstrong: Print statements. The great gods of programming said, “Thou shalt put printf statements in your program at the point where you think it's gone wrong, recompile, and run it.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“It's a motivating force to implement something; I really recommend it. If you want to understand C, write a C compiler. If you want to understand Lisp, write a Lisp compiler or a Lisp interpreter. I've had people say, “Oh, wow, it's really difficult writing a compiler.” It's not. It's quite easy. There are a lot of little things you have to learn about, none of which is difficult. You have to know about data structures. You need to know about hash tables, you need to know about parsing. You need to know about code generation. You need to know about interpretation techniques. Each one of these is not particularly difficult. I think if you're a beginner you think it's big and complicated so you don't do it. Things you don't do are difficult and things you've done are easy. So you don't even try. And I think that's a mistake.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Armstrong: I'd write them in C or assembler or something. Or I might actually write them in a dialect of Erlang and then cross-compile the Erlang to C. Make a dialect—this kind of domain-specific language kind of idea. Or I might write Erlang programs which generate C programs rather than writing the C programs by hand. But the target language would be C or assembler or something. Whether I wrote them by hand or generated them would be the interesting question. I'm tending toward automatically generating C rather than writing it by hand because it's just easier.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“One that's tricky is slight spelling errors in variable names. So I choose variable names that are very dissimilar, deliberately, so that error won't occur. If you've got a long variable like personName and you've got personNames with an “s” on the end, that's a list of person names, that will be something that my eye will tend to read what I thought it should have been. And so I'd have personName and then listOfPeople. And I do that deliberately because I know that my eye will see what I thought I'd written.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Armstrong: Yeah, then all the bits fit together. But maybe I can't explain it to anybody. I just get a very strong feeling that if I start writing the program now it'll work. I don't really know what the solution is. It's like an egg. The chicken's ready to lay the egg. Now I'm ready to lay the egg.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“And another thing, very important for problem solving, is asking my colleagues, “How would you solve this?” It happens so many times that you go to them and you say, “I've been wondering about whether I should do it this way or that way. I've got to choose between A and B,” and you describe A and B to them and then halfway through that you go, “Yeah, B. Thank you, thank you very much.” You need this intelligent white board—if you just did it yourself on a white board there's no feedback. But a human being, you're explaining to them on the white board the alternative solutions and they join in the conversation and suggest the odd thing. And then suddenly you see the answer. To me that doesn't extend to writing code. But the dialog with your colleagues who are in the same problem space is very valuable.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I can't say beginner programmers should open up all these abstractions. But what I am saying is you should certainly consider the possibility of opening them. Not completely reject the idea. It's worthwhile seeing if the direct route is quicker than the packaged route.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“The funny thing is, thinking back, I don't think all these modern gizmos actually make you any more productive. Hierarchical file systems—how do they make you more productive? Most of software development goes on in your head anyway. I think having worked with that simpler system imposes a kind of disciplined way of thinking. If you haven't got a directory system and you have to put all the files in one directory, you have to be fairly disciplined. If you haven't got a revision control system, you have to be fairly disciplined. Given that you apply that discipline to what you're doing it doesn't seem to me to be any better to have hierarchical file systems and revision control. They don't solve the fundamental problem of solving your problem. They probably make it easier for groups of people to work together. For individuals I don't see any difference.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“What we're doing is an aesthetic pursuit. It involves craftsmanship as well as mathematics and it involves people skills and prose skills—all of these things that we don't necessarily think of as engineering but without which I don't think you'll ever be a really good engineer.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“As your confidence in the API increases, then you flesh it out. But the fundamental rule is, write the code that uses the API before you write the code that implements it.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I have this big allergy to ivory-tower design and design patterns. Peter Norvig, when he was at Harlequin, he did this paper about how design patterns are really just flaws in your programming language. Get a better programming language. He's absolutely right. Worshipping patterns and thinking about, “Oh, I'll use the X pattern.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Seibel: When you're hiring programmers, how do you recognize the good ones? Crockford: The approach I've taken now is to do a code reading. I invite the candidate to bring in a piece of code he's really proud of and walk us through it.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Because we were so smart and we had so much experience. We had it wired. Couldn't miss. Programmers are optimistic. And we have to be because if we weren't optimists we couldn't do this work. Which is why we fall prey to things like second systems, why we can't schedule our projects, why this stuff is so hard.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“You've got the second-system problem where people who've had some success are given a blank slate and allowed to do whatever they want. Generally, they will fail because they'll be too ambitious, they won't understand the limits. And you get nothing out of that. You have to have extreme discipline to say, “It's not a blank slate; it's reimplementing what we had here; it's doing what we knew.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“The really good programmers spend a lot of time programming. I haven’t seen very good programmers who don’t spend a lot of time programming. If I don’t program for two or three days, I need to do it. And you get better at it—you get quicker at it. The side effect of writing all this other stuff is that when you get to doing ordinary problems, you can do them very quickly. - Joe Armstrong”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I think one thing that’s really important is to not be afraid of your ignorance. If you don’t understand how something works, ask someone who does. A lot of people are skittish about that. And that doesn’t help anybody. Not knowing something doesn’t mean you’re dumb – it just means you don’t know it yet.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“[Assembly level programming] kind of still separates the chest hair—gender-independent—programmers from those who don't quite have it. — Brendan Eich”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Seibel: I was looking at one of your papers from the 70s about your Fortran profiler. In the preamble you were very enthusiastic about how that tool changed your programming from figuring out what you were going to write, writing it, and debugging it, to figuring out what you were going to write, writing a really simple version, profiling it, then optimizing it.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“the advantage of some ignorance; it leaves some room for creativity. But sometimes it feels like ignorance is endemic in this industry-that people are unaware of things and wheels are constantly being reinvented with pointy corners.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Steele: Yeah. And not knowing the future. If I could change one thing-this is going to sound stupid-but if I could go back in time and change one thing, I might try to interest some early preliterate people in not using their thumbs when they count. It could have been the standard, and it would have made a whole lot of things easier in the modern era. On the other hand, we have learned a lot from the struggle with the incompatibility of base-ten with powers of two.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming