Coders at Work Quotes

“Armstrong: I think the lack of reusability comes in object-oriented languages, not in 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.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“We’re all optimists in our profession or we’d be forced to shoot ourselves. - Joshua Bloch”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Norvig: I think one of the most important things is being able to keep everything in your head at once. If you can do that you have a much better chance of being successful. That makes a small program easier. For a bigger program, you need extra tools to be able to handle that.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“[On identifying talented programmers] It’s just enthusiasm. You ask them what’s the most interesting program they worked on. And then you get them to describe it and its algorithms and what’s going on. If they can’t withstand my questioning on their program, then they’re not good. I’m asking them to describe something they’ve done that they’ve spent blood on. I’ve never met anybody who really did spend blood on something who wasn’t eager to describe what they’ve done and how they did it and why. I let them pick the subject. I don’t pick the subject, so I’m the amateur and they’re the professional in this subject. If they can’t stand an amateur asking them questions about their profession, then they don’t belong. - Ken Thompson”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Readability of code is now my first priority. It's more important than being fast, almost as important as being correct, but I think being readable is actually the most likely way of making it correct.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“And once I realized that code I write never fucking goes away and I'm going to be a maintainer for life. I get comments about blog posts that are almost 10 years old. "Hey, I found this code. I found a bug," and I'm suddenly maintaining code.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“So there's that change and then there's the change that I'm really worried about: that the way a lot of programming goes today isn't any fun because it's just plugging in magic incantations—combine somebody else's software and start it up. It doesn't have much creativity. I'm worried that it's 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. The kick now is after you've done your boring work then all of the sudden you get a great image. But the work didn't used to be boring.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Knuth: They were very weak, actually. It wasn't presented systematically and everything, but I thought they were pretty obvious. It was a different culture entirely. But the guy who said he was going to fire people, he wants programming to be something where everything is done in an inefficient way because it's supposed to fit into his idea of orderliness. He doesn't care if the program is good or not—as far as its speed and performance—he cares about that it satisfies other criteria, like any bloke can be able to maintain it. Well, people have lots of other funny ideas. People have this strange idea that we want to write our programs as worlds unto themselves so that everybody else can just set up a few parameters and our program will do it for them. So there'll be a few programmers in the world who write the libraries, and then there are people who write the user manuals for these libraries, and then there are people who apply these libraries and that's it. The problem is that coding isn't fun if all you can do is call things out of a library, if you can't write the library yourself. If the job of coding is just to be finding the right combination of parameters, that does fairly obvious things, then who'd want to go into that as a career? There's this overemphasis on reusable software where you never get to open up the box and see what's inside the box. It's nice to have these black boxes but, almost always, if you can look inside the box you can improve it and make it work better once you know what's inside the box. Instead people make these closed wrappers around everything and present the closure to the programmers of the world, and the programmers of the world aren't allowed to diddle with that. All they're able to do is assemble the parts. And so you remember that when you call this subroutine you put x0, y0, x1, y1 but when you call this subroutine it's x0, x1, y0, y1. You get that right, and that's your job.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Seibel: There's a Dijkstra quote about how you can't prove by testing that a program is bug-free, you can only prove that you failed to find any bugs with your tests. But it sort of sounds the same way with a proof-you can't prove a program is bug-free with a proof-you can only prove that, as far as you understand your own proof, it hasn't turned up any bugs.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“There's a brilliant quote by Tony Hoare in his Turing Award speech about how there are two ways to design a system: “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.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Ironically, as a result of his move to the country, Cosell- one of the fathers of the Internet-now has only dial-up access from his home.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“The experience of writing something in Java and then trying to figure out—I myself have trouble installing Java on my computer—it's horrible.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Fitzpatrick: Back when I was doing Perl-even for people that knew Perl really well-I would recommend MJD's Higher-Order Per!. The book is really fun in that it starts somewhat simple and you're like, "Yeah, yeah, I know what a closure is." And then it just continues to fuck with your head. By the end of the book, you're just blown away.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“He came in and took a piss in my hotel bathroom without even closing the door as I'm standing right there. I'm like, "Alright. You're comfortable." It was like we knew each other for four or five years, even though we had never met.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Zawinski: Sometimes. I end up doing all the sysadmin crap, which I can't stand-I've never liked it. I enjoy working on XScreenSaver because in some ways screen savers-the actual display modes rather than the XScreenSaver framework-are the perfect program because they almost always start from scratch and they do something pretty and there's never a version 2.0. There's very rarely a bug in a screen saver. It crashes-oh, there's a divide-by-zero and you fix that.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I don’t know that you’re that far out on the spectrum, at least among the people I’ve talked to for this book. Though Don Knuth did write TeX in pencil in a notebook for six months before he typed in a line of code and he said he saved time because he didn’t have to bother writing scaffolding to test all the code he was developing because he just wrote the whole thing.”
― Seibel, Coders at Work: Reflections On The Craft Of Programming

“when you're writing programs you need to be able to name your identifiers well. And your prose has to be good. I'd feel lost without a good dictionary.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Seibel: But there is a difference between a denial-of-service attack and an exploit where you get root and can then do whatever you want with the box. Thompson: But there are two ways to get root—one is to overflow a buffer and the other is to talk the program into doing something it shouldn't do. And most of them are the latter, not overflowing a buffer. You can become root without overflowing any buffers. So your argument's just not on. All you've got to do is talk su into giving you a shell—the paths are all there without any run-time errors. Seibel: OK. Leaving aside whether it results in a crash or an exploit or whatever else—there is a class of bugs that happen in C, and C++ for the same reason, that wouldn't happen in, say, Java. So for certain kinds of applications, is the advantage that you get from allowing that class of bugs really worth the pain that it causes? Thompson: I think that class is actually a minority of the problems. Certainly every time I've written one of these non-compare subroutine calls, strcpy and stuff like that, I know that I'm writing a bug. And I somehow take the economic decision of whether the bug is worth the extra arguments. Usually now I routinely write it out. But there's a semantic problem that if you truncate a string and you use the truncated string are you getting into another problem. The bug is still there—it just hasn't overflown the buffer.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Seibel: So some folks today would say, “Well, certainly assembly has all these opportunities to really corrupt memory through software bugs, but C is also more prone to that than some other languages.” You can get pointers off into la-la land and you can walk past the ends of arrays. You don't find that at all problematic? Thompson: No, you get around that with idioms in the language. Some people write fragile code and some people write very structurally sound code, and this is a condition of people. I think in almost any language you can write fragile code. My definition of fragile code is, suppose you want to add a feature—good code, there's one place where you add that feature and it fits; fragile code, you've got to touch ten places. Seibel: So when there's a security breach that turns out to be due to a buffer overflow, what do you say to the criticism that C and C++ are partly responsible—that if people would use a language that checked array bounds or had garbage collection, they'd avoid a lot of these kinds of problems? Thompson: Bugs are bugs. You write code with bugs because you do. If it's a safe language in the sense of run-time-safe, the operating system crashes instead of doing a buffer overflow in a way that's exploitable. The ping of death was the IP stack in the operating system. It seems to me that there'd be more pings of death. There wouldn't be pings of “take over the machine becoming superuser.” There'd be pings of death.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Seibel: In 1974 you said that by 1984 we would have “Utopia 84,” the sort of perfect programming language, and it would supplant COBOL and Fortran, and you said then that there were indications that such language is very slowly taking shape. It's now a couple of decades since '84 and it doesn't seem like that's happened. Knuth: No. Seibel: Was that just youthful optimism? Knuth: I was thinking about Simula and trends in object-oriented programming when I wrote that, clearly. I think what happens is that every time a new language comes out it cleans up what's understood about the old languages and then adds something new, experimental and so on, and nobody has ever come to the point where they have a new language and then they want to stop at what's understood. They're always wanting to push further. Maybe someday somebody will say, “No, I'm not going to be innovative; I'm just going to be clean and simple, and I'm going to stick to it.” Pascal was started with that philosophy but then didn't continue. Maybe we'll get to a time when somebody will say, “Let's set our sights lower and really try to make something that's going to be stable.” It might be a good idea.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“When I wrote Volume I of The Art of Computer Programming people didn't realize that they could use linked lists in their own programs, that they could use pointers for data structures.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Now, why hasn't this spread over the whole world and why isn't everybody doing it? I'm not sure who it was who hit the nail on the head—I think it was Jon Bentley. Simplified it is like this: only two percent of the world's population is born to be super programmers. And only two percent of the population is born to be super writers. And Knuth is expecting everybody to be both. I don't think we're going to increase the total number of programmers in the world to more than two percent—I mean programmers who really resonate with the machine and that's their bread and butter that they've been born to do. But now that people are blogging, I've seen a great rise in the average ability of ordinary everybody to express themselves. So the second part of that that argument isn't so strong anymore.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Seibel: Have you heard of refactoring? Cosell: No, what is that? Seibel: What you just described. I think now there's perhaps a bit more acceptance, even among the project managers of this idea.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“So when they ask, “How long is it going to take you to put this change in?” you have three answers. The first is the absolute shortest way, changing the one line of code. The second answer is how long it would be using my simple rule of rewriting the subroutine as if you were not going to make that mistake. Then the third answer is how long if you fix that bug if you were actually writing this subroutine in the better version of the program. So you make your estimate someplace between those last two and then every time you get assigned a task you have a little bit of extra time available to make the program better. I think that that makes an incredible difference. It makes for programs that evolve cleanly.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“You don't get credit because the program works. We're going to the next level. Working programs are a given,”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I've done this business long enough to understand that there are some very hard problems. But very few. It's invariably the case that when they think about it harder, it gets easier and all of a sudden it's easy to program correctly.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Cosell: I have to admit that I did both. I would make things simple in the large. But when I say that programs should be easy, it's not necessarily the case that specific pieces of the functionality of the program have to be easy. I could write some very complicated code to do the right thing, right there, code that people would cringe at and not be willing to touch. But it was always in an encapsulated place. Most of the bad programs I ran into, the ones where I threw things out and recoded them, there wasn't a little island of complexity you could try to understand and fix, but the complexity had oozed through the program.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I really believed that computers were deterministic, that you could understand what they were supposed to do, and that there was no excuse for computers not working, for things not functioning properly. In retrospect, I was surprisingly good at keeping the system running, putting in new code and having it not break the system. That was the first instance of something I got an undeserved reputation for. I know that my boss, and probably some other of my colleagues, have said I was a great debugger. And that's partly true. But there's a fake in there. Really what I was was a very careful programmer with the arrogance to believe that very few computer programs are inherently difficult. I would take some piece of code that didn't look like it was working and I would try to read it. And if I could understand, then I could usually see what was wrong or poke around with it and fix it. But sometimes I would get a piece of code—often one that other people couldn't make work—and I would say, “This is way too complicated.” So I would think through what it was supposed to do, throw it away, and write it again from scratch. Some of the folks I worked with—like Will Crowther—who are terrific programmers, couldn't tolerate that. They would believe that by doing that, I would probably have fixed the 2 bugs that were there and introduced 27 new bugs. But the fact is, I was good at that. So I would rewrite stuff completely and it would be organized differently than the original programmer had organized it because I had thought about the problem differently. Typically, it was simpler than it used to be, or at least simpler to my eyes. And it would work. So I got this reputation—I fixed these mysterious bugs that nobody else could fix. Fortunately, they never asked me what the bug was. Because the truth of the matter is if they'd have asked, “How did you fix the bug?” my answer would have been, “I couldn't understand the code well enough to figure out what it was doing, so I rewrote it.” I did that a lot on the PDP-1 time-sharing system. There were chunks of the code that I would read and would say, “This doesn't do what I think this part of the program is supposed to be doing,” or “It's weird.” So I'd rewrite it. The only thing that kept me working there, with that attitude, was that I had a good track record. That's one of the things, that if you're not good at it, you make chaos. But if you are good at it, the world thinks that you can do things that you can't, really.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I really believed that computers were deterministic, that you could understand what they were supposed to do, and that there was no excuse for computers not working, for things not functioning properly. In retrospect, I was surprisingly good at keeping the system running, putting in new code and having it not break the system. That was the first instance of something I got an undeserved reputation for. I know that my boss, and probably some other of my colleagues, have said I was a great debugger. And that's partly true. But there's a fake in there. Really what I was was a very careful programmer with the arrogance to believe that very few computer programs are inherently difficult. I would take some piece of code that didn't look like it was working and I would try to read it. And if I could understand, then I could usually see what was wrong or poke around with it and fix it. But sometimes I would get a piece of code—often one that other people couldn't make work—and I would say, “This is way too complicated.” So I would think through what it was supposed to do, throw it away, and write it again from scratch. Some of the folks I worked with—like Will Crowther—who are terrific programmers, couldn't tolerate that. They would believe that by doing that, I would probably have fixed the 2 bugs that were there and introduced 27 new bugs. But the fact is, I was good at that. So I would rewrite stuff completely and it would be organized differently than the original programmer had organized it because I had thought about the problem differently. Typically, it was simpler than it used to be, or at least simpler to my eyes. And it would work. So I got this reputation—I fixed these mysterious bugs that nobody else could fix. Fortunately, they never asked me what the bug was. Because the truth of the matter is if they'd have asked, “How did you fix the bug?” my answer would have been, “I couldn't understand the code well enough to figure out what it was doing, so I rewrote it.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“But there was no real-time debugging. When the system crashed, basically the run light went out and that was it. You had control-panel switches where you could read and write memory. The only way to debug the system was to say, “What was the system doing when it crashed?” You don't get to run a program; you get to look at the table that kept track of what it was doing. So I got to look at memory, keeping track on pieces of graph paper what it was doing. And I got better at that. In retrospect, I got scarily better at that. So they had me have a pager. This was back in the era when pagers were sort of cool and only doctors had them. It was a big, clunky thing and all it would do is beep. No two-way. No messages. And it only worked in the Boston area, because its transmitter was on top of the Prudential Center. But if I was within 50 miles of Boston, it worked. And basically, I was a trained little robot: when my pager went beep, beep, beep, I called in to find out what the problem was. What was bizarre was that with no paper, in a parking lot, on a pay phone I could have them examining octal locations, changing octal locations and then I would say, “OK, put this address in and hit run,” and the system would come back up. I don't know how the hell I managed to do that. But I could do those kinds of things. I took care of the time-sharing system for probably a good two or three years.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming