all2one awakening

He said, "Just start something, no matter how humble." ... It turned out to be a very significant piece of advice. p. 249

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. p. 266

STM is not going to save the world on its own. Concurrency, and parallel programming generally, is many-faceted beast and I don't think it will be slain by a single bullet. I'm a diversifist when it comes to concurrency. p. 271

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. p. 275

As soon as you can do it, you stretch to the point where you can't do it anymore. I suppose I don't really see it as, is it this or is it that? There will always be a strong crafty element. I think, just because we'll stretch our ambition. In the case of engineering structures, there are physical limits on how far you can stretch. Nobody's going to build a bridge that traverses the Atlantic any time soon. And that really might fall down if you build it. But that's not the reason people won't build it - it's just because it'd be too expensive. Whereas nowadays, with software, once you can build bridges over the Channel pretty quickly and cheaply, well then, that becomes a done deal and we now think that's pretty cheap so we'll now try the Atlantic. And now it falls apart again. p. 280-281

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. p. 286

There's some saying in German about the perfect being the enemy of the good; I forget exactly where it comes from - every practical engineer has to learn that lesson. p. 306

Seibel: You told me once that when Guido van Rossum came here he had to get checked out on Python and Ken Thompson had to get checked out on C, to make sure they could meet very explicit coding standards. p. 309

Sometimes I feel guilty about that. Is that a failure on my part? I didn't understand what the bug was. I didn't find the bug. I just dropped a bomb on the house and blew up all the bugs and built a new house. In some sense, the bug eluded me. But if it becomes the right solution, maybe it's OK. You've done it faster than you would have by finding it. p. 315

If you found that the programmers in the big corner offices were more productive, is that because you reward the good programmers with the offices, or is it because the offices makes them better? You can't really come to a conclusion. p. 316

One of the interesting things we found, when trying to predict how well somebody we've hired is going to perform when we evaluate them a year or two later, is one of the best indicators of success within the company was getting the worst possible score on one of your interviews. We rank people from one to four, and if you got a one on one of interviews, that was a really good indicator of success. p. 322