Coders at Work

View on Goodreads

As coders, we spend a lot of time staying on top of the latest trends. We don’t often reflect on the fundamentals of the craft or consider the wisdom experienced practitioners have to offer. This book does just that, interviewing fifteen of the greatest programmers and computer scientists. Below are my highlights from the book.

Preface

There were, however, some common themes: almost everybody emphasized the importance of writing readable code; most of my subjects have found that the hardest bugs to track down are in concurrent code; and 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. And almost everyone seemed to think that ubiquitous multi-core CPUs are going to force some serious changes in the way software is written. Peter Seibel, p. xiii

Jamie Zawinski

C++ is just an abomination. Everything is wrong with it in every way. Jamie Zawinski, p. 10

And it was just nice to be in that kind of environment where when someone says, “That’s nonsense,” or “We should do it this way,” you can just take their word for it, believe that they know what they were talking about. That was really nice. Jamie Zawinski, p. 13

There’s never a time to start over and rewrite it. And it’s never a good idea to start over and rewrite it. Jamie Zawinski, p. 17

They were being extremely academic about their project. They were trying to approach it from the DOM/DTD side of things. “Oh, well, what we need to do is add another abstraction layer here and have a delegate for this delegate for this delegate. And eventually a character will show up on the screen.” Jamie Zawinski, p. 22

At the end of the day, ship the fucking thing! […] you’re not here to write code; you’re here to ship products. Jamie Zawinski, p. 22

Also, once you start writing code, you’re gonna realize, “No, that was a dumb idea. Why did I think that this module was going to be really easy when actually it’s way more complicated than I thought?” Which is something you’re not going to clue into until you actually start writing code and feel it getting away from you. Jamie Zawinski, p. 29

I always find that at good way to sort of immerse yourself in a piece of code is pick a task you want to accomplish and then try and do it. Jamie Zawinski, p. 35

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. Jamie Zawinski, p. 40

It’s weird that people often confuse those two pursuits. People who are into very theoretical computer science are thought of in the same way as people who are shipping desktop applications. And they don’t really have a lot to do with each other. Jamie Zawinski, p. 42

But I’ve always seen much more in common with writing prose than math. It feels like you’re writing a story and you’re trying to express a concept to a very dumb person – the computer – who has a limited vocabulary. Jamie Zawinski, p. 45

Brad Fitzpatrick

I think it’s really important to know the whole stack even if you don’t operate within the whole stack. Brad Fitzpatrick, p. 65

Always try to do something a little harder, that’s outside your reach. Read code. Brad Fitzpatrick, p. 69

Some are purists. They would just do abstraction on abstraction on abstractions. They would go really slowly and are very religious about their style. They’re like, “I’m an artisan programmer.” And I was like, “Your code doesn’t run. It’s not efficient and it doesn’t look like any of the other code that you’re interacting with.” Brad Fitzpatrick, p. 76

But the thing I find is by writing a program to cheat, you learn because you have to learn it really in depth to write that program. Brad Fitzpatrick, p. 77

Once you get to a lot of machines, all of a sudden the programmers’ time is worth less than the number of machines that this will be deployed against, so now write it in C and profile the hell out of it, and fix the compiler, and pay people to work on GCC to make this compile faster. Brad Fitzpatrick, p. 80

Thinking like a scientist; changing one thing at a time. Patience and trying to understand the root cause of things. Brad Fitzpatrick, p. 86

Douglas Crockford

Well, ultimately the significance of the changes you can make to a language is related to the success of the language. The more successful the language is, the greater the cost of changing it. Douglas Crockford, p. 96

JavaScript, purely by accident, has become the most popular programming language in the world. […] The problem with the language is that it was rushed to the market way too fast and standardized way too fast. So most of its defects are not in the current implementations – they are in the specification. The standard says do this incorrectly. Which is appalling. But that’s the state of it. Douglas Crockford, pp. 96–97

The worst feature of JavaScript, without question, is its dependence on a global object. It doesn’t have linkers, it doesn’t have any kind of information hiding between compilation units. It all gets dumped together into a common global object. Douglas Crockford, p. 98

The whole web is built on one mistake after another. We have this big pile of accidents. Douglas Crockford, p. 99

Another example is the “continue” statement. I have never seen piece of code that I could not improve by taking the “continue” out. Douglas Crockford, p. 106

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.” Douglas Crockford, p. 110

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 hard. Douglas Crockford, p. 113

In most of the classical languages, the language is the thing imposing the discipline. In JavaScript you have to bring your own discipline. Douglas Crockford, p. 118

I think threads are an atrocious programming model. They’re an occasional [necessary] evil, but they’re not necessary for most of the things we use threads for. Douglas Crockford, p. 121

I think we’re tragically unaware of our history, and I’m often really disappointed to see that people who are now practicing this craft having no intellectual curiosity about where this stuff came from and just assume that some committee got it right and presented them with a set of tools or languages, and all they have to do is use it properly. Douglas Crockford, pp. 127–128

Brendan Eich

When you writing Haskell programs you’re forced to decide your proof system in advance of knowing what it is you’re doing. Dynamic languages became popular because people can actually rapidly prototype and keep this latent type system in their head. Then maybe later on, if they have a language that can support it, or if they’re recoding in a static language, they can write down the types. Brendan Eich, p. 139

But there’s something that still bothers me if over time we lose the ability to write to the metal. Somebody’s doing it; the compiler is generating the code. The compiler writers have to be doing a better job over time. Brendan Eich, p. 141

So a blue-collar language like Java shouldn’t have a crazy generic system because blue-collar people can’t figure out what the hell the syntax means with covariant, contravariant type constraints. Certainly I’ve experienced some toe loss due to C and C++’s foot guns. Brendan Eich, p. 147

There’s sort of a programming ziggurat – the Right Stuff, you know. People are climbing towards the top, even though some of the tops sometimes fall off or lose a toe. Brendan Eich, p. 148

We need to have the programming discipline not be just this sort of blue-collar thing that’s cut off from the people in the ivory towers. Brendan Eich, p. 151

You end up doing very basic stuff, though. It’s like a lot of other bugs. You end up bisecting – you know “wolf fence.” You try to figure out by monitoring execution and the state of memory and try to bound the extent of the bug and control flow and data that can be addressed. Brendan Eich, p. 152

But if you really are trying to move a needle and you don’t know exactly what you’re doing, rewrite. It’s going to take several tries to know what the hell you’re doing. Brendan Eich, pp. 154–155

You spend all this time writing documents and then you go to write the code and often you realize that it’s really stupid and you totally change the code and put the documents down the memory hole. Brendan Eich, p. 158

[…] finding the right idea that has the New Jersey philosophy of a 90/10 trade-off – a sweet, sound theoretical core that isn’t going to solve all your problems but when you fall on the 10 percent that loses, you don’t go to hell. You can actually win this way and the code stays small enough and simple enough and there’s some dance between theory and implementation. Brendan Eich, p. 164

Joshua Bloch

Basically I’ve become harder on myself over the years – that’s what it takes to write good programs. You really can’t accept bad habits from yourself. Joshua Bloch, p. 170

The importance of requirements analysis can’t be overstated. There are people who think, “Oh, yeah, requirements analysis; you go to your customer, you say, ‘What do you need?’ He tells you, and you’re done.” Nothing could be further from the truth. Not only is it a negotiation but it’s a process of understanding. Many customers won’t tell you a problem; they’ll tell you a solution. Joshua Bloch, p. 178

The fundamental theorem of API design is, when in doubt, leave it out. […] “Simple ain’t easy.” Joshua Bloch, p. 181

But I think a big sin in our area, in engineering, is doing stuff just because it’s neat, because it’s good engineering, whatever. If you’re not solving real problems for real users – in this case, Java programmers – then you shouldn’t add the feature. Joshua Bloch, p. 195

We weren’t really thinking that the most important thing we could do was solve real problems for real customers. The moment you lose sight of that and who your customers are, you’re dead meat. Joshua Bloch, p. 202

Joe Armstrong

Over the years I’ve kind of made a generic mistake and the generic mistake is to not open the black box. To mentally think, this black box is so impenetrable and so difficult that I won’t open it. Joe Armstrong, p. 211

Programers have been conned into using all these different programming languages and they’ve been conned into not using easy ways to connect programs together. Joe Armstrong, p. 213

And what I don’t see in system architectures is this clear distinction between the gluing things together and the complexity of the things inside the boxes. Joe Armstrong, pp. 214–215

I just know from experience, stop – don’t write code. Stop with the problem. Do something else. Joe Armstrong, p. 216

What we learned later was, it wasn’t all that easy to discover new stuff. And it’s incredibly difficult to get people to use new and better stuff. Joe Armstrong, p. 220

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. Joe Armstrong, p. 223

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. Joe Armstrong, p. 223

[…] Joe’s Law is Debugging, which is that all errors will be plus/minus three statements of the place you last changed the program. Joe Armstrong, p. 227

I’ve always taken the view of system design, you solve the hard problems first. Identify the hard problems and then solve them. And the easy problems, you know they’ll just come out in the wash. Joe Armstrong, p. 231

Prolog is so different to all the other programming languages. It’s just this amazing way of thinking. Joe Armstrong, p. 233

Simon Peyton 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. Simon Peyton Jones, p. 248

He said, “Just start something, no matter how humble.” […] It turned out to be a very significant piece of advice. Simon Peyton Jones, p. 249

You’re five times as productive if you’re working on something that makes you enthusiastic. So if you find yourself thinking, “I just love this and is just like to have some time to dig into it some more,” a PhD is a fantastic opportunity […]. Simon Peyton Jones, p. 250

“What’s the equivalent of UML diagrams for a functional language?” […] it’s the type system. […] It’s almost an architectural description of part of what your program does. Simon Peyton Jones, p. 263

I’ll start writing type signatures into a file right away. Actually I’ll probably start writing some code that manipulates values of those types. Then I’ll go back and change the data types. It’s not a two-stage process where we say, “Now I’ve done the types, I can write the code.” Simon Peyton Jones, p. 265

Nevertheless, I think to try to specify all that a program should do, you get specifications that are themselves so complicated that you’re no longer confident that they say what you intended. Simon Peyton Jones, p. 269

Concurrency, and parallel programming generally, is a 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. Simon Peyton Jones, p. 271

Finer-grained locking is tricky to get right. I think this is one of the huge wins of STM, is it gives you the fine granularity of very fine-grained locking along with very simple reasoning principles. Simon Peyton Jones, p. 273

Bits are often beautiful or at least acceptably non-ugly when they’re first built. In the face of protracted life – maintenance – it’s quite difficult to maintain that. That’s the worst thing about long-lived programs … that they gradually become ugly. Simon Peyton Jones, p. 285

Peter Norvig

You’ve got to be able to make progress and then improve on it. That’s all you need to be able to do in life. You’ve got to have some idea and say, “Here’s the direction to go,” and then be able to say, “Now I’ve got to refine it.” […] “Where was I going? How did I get there? Is there a better way to get there?” Peter Norvig, p. 299

[…] the perfect being the enemy of the good […] every practical engineer has to learn that lesson. Peter Norvig, p. 306

I think he [Donald Knuth, literate programming] was solving a problem that doesn’t exist anymore to a large degree. Peter Norvig, p. 318

Guy Steele

Then I became involved at MIT in the spring of 1969 in the High School Studies Program. This was great – go on Saturday mornings and have college students teach you all this cool stuff. I took courses in group theory and computer programming and I forget what all else. Guy Steele, p. 327

I set out to be a pure math major and arranged my courses appropriately and then discovered I had no intuition whatsoever for infinite dimensional Banach spaces. That’s what did me in. Fortunately, just out of interest, I had taken enough computer courses on the side that I was well-positioned to make the switch in major. Guy Steele, p. 331

The point is to present ideas in an order such that they tell a story rather than just being a pile of code thrown together. Guy Steele, p. 336

Knuth carefully laid out TeX: The Program so you could almost read it as a novel or something. You could read it in a linear pass. […] Of course, it was an enormous amount of work on his part, which is why very few programs have been done that way. Guy Steele, p. 337

[…] you want to design the specification of what’s in the middle in such a way that it naturally is also correct on the boundaries, rather than treating boundaries as special cases. Guy Steele, p. 344

I worked seriously on the implementation of Emacs probably for only about four or six weeks. […] Stallman did the other 99.9999 percent of the work. Guy Steele, p. 347

But there is this demand for adding to the language […] for a really successful programming language, you need to design and plan for the social process as much and you design the technical features of the language and think about how those two things are going to interact. Guy Steele, p. 350

The one thing I am reasonably convinced of is that it’s a mistake to think that one language solves all problems better than any other language, or even equally well. I really think there are application areas for which particular languages are better suited. Guy Steele, p. 352

[…] it’s really hard to make a language that’s great at everything, in part because there are only so many concise notations to go around. There’s this Huffman encoding problem. If you make something concise, something is going to have to be more verbose as a consequence. Guy Steele, p. 352

[…] it’s not possible to understand everything that’s going on anymore. Or even to think you can. So I think the programmers of today are up against a more difficult environment – still exercising the same amounts of ingenuity but in an environment that’s harder to understand. So we try to make more elaborate languages to help them deal with the uncertainty of those environments. Guy Steele, p. 355

Programming is a highly unnatural activity, I’m convinced, and it must be carefully learned. People are used to their listeners filling in the gaps. Guy Steele, p. 360

[…] if a bug is thought to be rare, then looking at rarely executed paths may be fruitful. Guy Steele, p. 364

It’s easy to become too fixated on optimizing something just because you can, even though it’s not what you need to work on. Guy Steele, p. 370

Dan Ingalls

I may be the only person who’s ever written a hash table in COBOL. Dan Ingalls, p. 376

In a much bigger sense I hate to see computer-science departments that feel their role is to prepare people to work in an industry and the industry is going that way and therefore we have to teach our students that way. It’s exactly the wrong thing to do. What you should be doing with your students is teaching them to think generally – think outside the box and plot the other courses we should be pursuing. Dan Ingalls, p. 379

I thinks it’s better to have the underlying systems be as dynamic as possible. The you can put on syntax or type restrictions, or this, that, and the other that make it into a fixed thing. Dan Ingalls, p. 381

When Smalltalk-80 got out in the world there were Smalltalk companies; objects were a big thing; Bytes did its issue all about Smalltalk. The promise was that objects were going to be these reusable components and that programmers would just go down to Ye Olde Object Shoppe and buy some objects and plug them into their program. Peter Seibel, p. 389

So why is message passing such a good thing? That’s the reason: it separates the inside from the outside, 100 percent. Dan Ingalls, p. 389

To me, the really exciting thing about computers is that they allowed mathematics to become a synthetic, not just an analytic art. What I have so much fun doing day to day is a mathematical kind of thing, but it’s creative, generative, synthetic. Dan Ingalls, p. 401

And I kind of feel like the better a language is, the less you need comments. You use reasonable variable names. That’s why I liked the keyword parameters in Smalltalk. It made things pretty readable. Dan Ingalls, p. 408

L Peter Deutsch

My belief is still, if you get the data structures and their invariants right, most of the code will just kind of write itself. L Peter Deutsch, p. 420

[…] the principles for dealing with algorithmic problems are based a lot more directly on 5,000 or 10,000 years’ worth of history in mathematics. How we go about programming now, we don’t had anything like that foundation to build on. Which is one of the reasons why so much software is crap: we don’t really know what we’re doing yet. L Peter Deutsch, p. 421

[…] the world of basically all programming languages that we have is so different in such deep ways from the physical world that our senses and our brains and our society have coevolved to deal with, that it is loony to expect people to do well with it. There has to be something a little wrong with you for you to be a really good programmer. L Peter Deutsch, p. 423

The physical properties of matter are such that 99.9 percent of the time you can understand it in aggregate. […] To a great extent, that is not true in the world of software. L Peter Deutsch, p. 424

[…] how important it is to measure things; that there’ll be times – maybe more times than you think – when your beliefs or intuitions just wont be right, so measure things. Even sometimes measure things you don’t think you need to measure. L Peter Deutsch, p. 430

[…] requirements always change, they always are going to at least attempt to change in directions you didn’t think of. L Peter Deutsch, pp. 433–434

I think behind this perhaps is a mindset of software as expense vs. software as a capital asset. I’m very much in the software-as-capital-asset school. […] And there is no such thing as a capital asset that doesn’t require ongoing maintenance and investment. L Peter Deutsch, p. 434

A large part of the sell for objects was that well-designed objects are reusable, so the investment that you put into the design pays itself back in less effort going down the road. I still believe that, but probably not quite as strongly as I did. The things that I see getting reused these days are either very large or very small. […] very small things – individual icons, insidiously web page designs – or very big things like entire languages or large applications with extension architectures like Apache or Mozilla. L Peter Deutsch, pp. 434–435

I’ve seen software practice over a period of just about 50 years and it basically hasn’t improved tremendously in about the last 30 years. […] I would make a strong case that programming languages have not improved qualitatively in the last 40 years. L Peter Deutsch, p. 435

Every now and then I feel a temptation to design a programming language but then I just lie down until it goes away. L Peter Deutsch, p. 436

[Jim Morris says] a type checker is just a Neanderthal correctness-prover. L Peter Deutsch, p. 438

[…] theorem-proving technology basically has – in my opinion – failed as a practical technology for improving software reliability. It’s just too damn hard to formalize the properties you want to establish. L Peter Deutsch, p. 445

Ken Thompson

So I […] essentially built Unix on these very, very small PDP machines. […] I kind of expected that for what I was doing I was going to eventually get fired. I didn’t. Ken Thompson, p. 458

Modern programming scares me in many respects, where they will just build layer after layer after layer that does nothing except translate. It confuses me to read a program which you must read top-down. Ken Thompson, p. 459

And I’ve always been totally willing to hack things apart if I find a different way that fits better or a different partitioning. I’ve never been a lover of existing code. Code by itself almost rots and it’s gotta be rewritten. Even when nothing has changed, for some reason it rots. Ken Thompson, p. 460

Documenting is very, very hard; it’s time consuming. To do it right, you’ve got to do it like programming. You’ve got to deconstruct it, put it together in nice ways, rewrite it when it’s wrong. People don’t do that. Ken Thompson, p. 461

There was just no reason to ever build a Lisp machine. It was kind of stupid. Ken Thompson, p. 463

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. Ken Thompson, p. 467

To build a very complex algorithm for something that’s never run is just stupid. It’s just a waste of time. It’s a bug generator. Ken Thompson, pp. 469–470

[Seibel: And presumably part of the reason writing programs directly in assembly is less important these days is because compilers have gotten better.] No. I think it’s mostly because machines have gotten a lot better. Compilers stink. You look at the code coming out of GCC and it’s awful. It’s really not good. Ken Thompson, p. 471

Plus, garbage collection fights cache coherency massively. […] Usually they treat them as separate algorithms that have nothing to do with machines, but the cache coherency is very important for garbage-collection algorithms. Ken Thompson, p. 472

[Strousup] 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. Ken Thompson, p. 475

Fran Allen

[Seibel: What makes a program beautiful?] That it is simple straightforward solution to a problem; that has some intrinsic structure and obviousness about it that isn’t obvious from the problem itself. Fran Allen, p. 489

I think our field is best done when it works on both sides [theory and practice] on the same projects. Fran Allen, p. 496

The motivation for the design of C was three problems they couldn’t really solve in the high-level languages: One of them was interrupt handling. Another was scheduling resources, taking over the machine and scheduling a process that was in the queue. And a third one was allocating memory. And you couldn’t do that from a high-level language. So that was the excuse for C. Fran Allen, p. 502

By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed. C has destroyed our ability to advance the state of the art in automatic optimization, automatic parallelization, automatic mapping of a high-level language to the machine. This is one of the reason compilers are … basically not taught much anymore in the colleges and universities. Fran Allen, p. 502

Because languages like C totally overspecify the solution of problems. Those kinds of languages are what is destroying computer science as a study. […] But they [Java, C#, Python, Ruby] still overspecify. The core thing is that it specifies location of data. If you look at these other languages, they stayed away from specifying the location of data and how to move it, where to put it in the machine. It was ultimately about its value at any point. Fran Allen, p. 503

I think in these first 50 years – 60 years maybe […] we’ve built up not only a wonderful, amazing legacy – just astounding – but also some artifacts that we need to get rid of. It’ll take a very long time to replace these and I think it’s a little hard to predict how that will evolve. But it’ll evolve very fast if we can get some new thinking going in the right places. We know how to do computations on a lot of stuff. We don’t know how to deliver the data to the computation elements in the machine. Fran Allen, p. 504

The whole field [of computer science] 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. Fran Allen, p. 513

Bernie Cosell

[…] I got an undeserved reputation for [being] a great debugger. And that’s partly true. But there’s a fake in there. […] I would think through what it was supposed to do, throw it away, and write it again from scratch. […] And it would work. Bernie Cosell, p. 525

Mostly I viewed computer programming as a means to get neat things done and I learned how to program in order to make things happen. There were things that seemed broken to me that I could fix. Bernie Cosell, p. 529

I’m sure you’ve done design reviews where you didn’t work on some part of it real well and so you kind of slide past that part. […] He had an instinct […] of catching you when you were bluffing. […] The trouble is if you were an insecure programming you assumed that this was an attack […] The design review was to help you get your program right. […] that takes enough confidence in your skill as an engineer […]. Bernie Cosell, pp. 538–539

The first is the idea that there are very few inherently hard programs. If you’re looking at a piece of code and it looks very hard – if you can’t understand what this thing is supposed to be doing – that’s almost always an indication that it was poorly thought through. At that point you don’t roll up your sleeves and try to fix the code; you take a step back and think it through again. When you e thought it through enough, you’ll find out that it’s easy. Bernie Cosell, p. 542

The other rule is to realize that programs are meant to be read. […] computer-program source code is for people, not for computers. Bernie Cosell, p. 542

Programmers are the worst optimizers in the world. They always optimize the part of the code that’s more interesting to optimize, and almost never get the part of the code that actually needs optimization. So you get these little bits of very difficult code that have no point. Bernie Cosell, p. 556

So C sort of steamrolled the zillions of languages back then. […] I am still stunned almost every day that it borders on the impossible to write a program or any real complexity in C and not have a security problem. Bernie Cosell, p. 557

When I first messed with Java – this was when it was a little baby language, of course – I said, “Oh, this is just another one of those languages to help not-so-good programmers go down the straight and narrow by restricting what they can do.” Bernie Cosell, p. 560

Donald Knuth

[…] 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. Donald Knuth, p. 568

When I wrote TeX originally in 1977 and ‘78, of course I didn’t have literate programming but I did have structured programming. I wrote it in a big notebook in longhand, in pencil. Six months later, after I had gone through the whole project, I started typing it into the computer. Donald Knuth, p. 570

I think programming is a lot like religion; people have their beliefs. Some people like to force their beliefs on others. Others say, you know, here’s what I think; I can’t prove that this is the best thing, but it sure works for me. Donald Knuth, p. 573

The first rule of writing is to understand your audience […] The second rule, for technical writing, is say everything twice in complementary ways so the person who’s reading it has a chance to put the ideas into his or her brain in ways that reinforce each other. Donald Knuth, p. 573

But it’s a different order – it’s neither top-down nor bottom-up. It’s psychologically, “What so I find is the thing that’s going to make me most satisfied to get done next and I’m ready to do it?” Donald Knuth, p. 574

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 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 […] There’s this overemphasis on reusable software where you never get to open up the box and see what’s inside the box. Donald Knuth, p. 582

If we restrict ourselves to the things that are really easy, then that’s not satisfactory because our appetite is always to push the boundary and go until it gets to something we can barely do. […] Every three years there’ll be another buzz word as to something that’s going to solve all these problems and make it really work. […] Somebody will come up with another supposedly silver bullet and there’ll be a lot of people jumping on that bandwagon and then they’ll find, “Oh, it’s still hard.” Donald Knuth, p. 593

In a way I resent having every language be universal because they’ll be universal in a different way. It’s a little bit like Unix having 30 definitions of regular expressions under one roof […] If every tool that you have included a Turing machine inside, is this really the way to go? I was thinking of TeX as something that the more programming it had in it, the less it was doing its real mission of typesetting. Donald Knuth, p. 597

The idea that people knew a thing or two in the ’70s is strange to a lot of young programmers. Donald Knuth, p. 599