Coders at Work Quotes

“you only got 80 words to write your routine, and so you do tend to use things like reusing instructions as data, using a piece of data for more than one thing. If you can manage to put this little subroutine there in memory, then its address can also be used as a data constant. This is what it took-it was origami and haiku and all that as a style of programming. And I spent several years doing that.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“A good example is overflow detection on arithmetic, or providing bignums instead of just letting 32-bit integers wrap around. Now,
implementing those is more expensive but I believe that providing full-blown bignums is a little less error-prone for some kinds of programming.
A trap that I find systems programmers and designers of operating-systems algorithms constantly falling into is they say, "Well, we need to synchronize some phases here so we're going to use a take-a-number strategy. Every time we enter a new phase of the computation we'll increment some variable and that'll be the new number and then the different participants will make sure they're all working on the same phase number before a certain operation happens." And that works pretty well in practice, but if you use a 32-bit integer it doesn't take that long to count to four billion anymore. What happens if that number wraps around? Will you still be OK or not? It turns out that a lot of such algorithms in the literature have that lurking bug. What if some thread stalls for 2 to the 32nd iterations? That's highly unlikely in practice, but it's a possibility. And one should either mitigate that correctness problem or else do the calculation to show that, yeah, it's sufficiently unlikely that I don't want to worry about it. Or maybe you're willing to accept one glitch every day. But the point is you should do the analysis rather than simply ignoring the issue. And the fact that counters can wrap around is a lurking pitfall”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I think it is always going to be true that a person who manages programmers should not expect it to be predictable.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I think it's not an accident that we often use the imagery of magic to describe programming. We speak of computing wizards and we think of
things happening by magic or automagically. And I think that's because being able to get a machine to do what you want is the closest thing we've got in technology to adolescent wish-fulfillment.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Seibel: Can you say now whether you think it's a good or bad language?
Thompson: It certainly has its good points. But by and large I think it's a bad language. It does a lot of things half well and it's just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether it's personal or corporate, selects a subset and these subsets are different. So it's not a good language to transport an algorithm-to say, "I wrote it; here, take it." It's way too big, way too complex. And it's obviously built by a committee.
Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said "no" to no one. He put every feature in that language that ever existed. It wasn't cleanly designed-it was just the union of everything that came along. And I think it suffered drastically from that.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“intransigence”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“an open-plan cubicle kind of thing-working, doing something, writing some Lisp program. And he'd come shuffling in with his ceramic mug of beer, bare feet, and he'd just stand behind me. I'd say hi. And he'd grunt or say nothing. He'd just stand there watching me type. At some
point I'd do something and he'd go, "Ptthh, wrong!" and he'd walk away. So that was kind of getting thrown in the deep end. It was like the Zen approach-the master hit me with a stick, now I must meditate.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“The funny thing was that that this meant the whole company had been running without mutexes for a couple weeks, and nobody noticed.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Seibel: How do you read code you didn't write? Crockford: By cleaning it. I'll throw it in a text editor and I'll start fixing it. 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.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Moore's law doesn't apply to batteries. So how much time we're wasting in interpreting stuff really matters there. The cycles count.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“The Web is broken and we need to fix it.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Things have gotten faster but the software has gotten slower and buggier in the meantime.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I would send out some contests. “Here's some code. Here's the benchmark. Make it fast.” I sent our load balancer's header parsing. We were all writing crazy regexps that didn't backtrack and tried to capture things with the most efficient capture groups. And we were all competing, getting faster and faster and faster. Then one guy comes over the next day. He had written it all in C++ with XS, and so he was like, “I win.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“When they realize, “Oh, my program's getting gigantic,” what are they going to do? They're not going to know where to start. That's my first instinct because I'm a caveman. Really that probably doesn't even matter because you'll just throw more memory at it and it'll be fine.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“I always wish people would comment more, though the thing that makes me cringe is when the comment is the name of the function rephrased. Function's called push_stack and the comment says, “This pushes to the stack.” Thank you.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“one thing that separates good programmers from bad programmers is that good programmers are more facile at jumping between layers of abstraction—they can keep the layers distinct while making changes and choose the right layer to make changes in.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“so we'll focus on the Windows side of things and then we'll port it later.” Which is what many other failed companies have done. If you're trying to ship a cross-platform product, history really shows that's how you don't do it. If you want it to really be cross-platform, you have to do them simultaneously. The porting thing results in a crappy product on the second platform.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“And he was like, “No, no, I really think we ought to do that.” And I was like, “We don't have time!” So he wrote it that night.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“Nobody, at least on the Unix side, had any idea they wanted it yet. Everyone uses them now but we had to spend a lot of time explaining to people why this was better than vi and GCC.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“When you're debugging something and then you figure out that not only is the map wrong but the tools are broken—that's a good time.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“There was a bug in GDB!”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming

“nobody seemed to think programming is a solved problem: most are still looking for a better way to write software, whether by finding ways to automatically analyze code, coming up with better ways for programmers to work together, or finding (or designing) better programming languages.”
― Peter Seibel, Coders at Work: Reflections on the Craft of Programming