I used to post an annual list of top 10 fave reads of the year. Nowadays, I post a "book report" for every book I read. It takes less time than writing up the top 10. It took too long to pick the top 10. But if I was still doing that, Coders at Work would have been an easy pick. It's a book of interviews with famous computer programmers. It was terribly inspiring. These folks are still in the game, still getting stuff done. Well, some of them are. Some of them are now musicians, goat farmers... But most of them are still changing the world.
If you read this blog a lot, you might be surprised that I'd find a book of interviews with programmers "inspiring". Didn't I just read another such book and find it "saddening"? Yeah, but those were people who worked on programming languages, always at the center of a storm of controversy. The people in Coders at Work didn't all work on programming languages. They seem less bitter. (Or maybe they are bitter and I just don't notice it. Maybe I'm quicker to spot flame-war scar tissue from programming language arguments. The bitterness award in this book, as near as I could tell, went to Fran Allen, a Fortran guru who's sorry that programmers used C&nsp;for so many years instead of highly-optimized high-level programming languaes, like, say, Fortran. (At the same time, it's interesting to hear from someone rail against something that I take for granted as part of the environment such as C.))
Famous names, titans of the industry science art field, but there's no blustering thunder in their talk. They sound like the geeks you've known. They don't have the perfect answer to everything, but they're driven to find out. There is a terrible realization that comes over you when you read interviews like this. These people have done great things, but they don't sound that special. They sound like me and the people around me. If they could change the world, so could I. Thus the terrible realization: You can't blame your lack of accomplishment on lack of talen. You'd better get up off of your ass and do something.
A conversation about code maintenance with Doug Crockford. He's talking about how much effort to put into "cleaning up" code. Lately at work, I've been talking about this with folks, so I'm interested in what Crockford has to say:
Siebel: [interviewer] In one of your talks you quoted Exodus 23:10 and 11: "And six years thou shalt sow thy land, and shalt gather in the fruits thereof. But the seventh year thou shalt let it rest and lie still" and suggested that every seventh sprint should be spent cleaning up code. What is the right time frame for that?
Crockford: Six cycles—whatever the cycle is between when you ship something. If you're on a monthly delivery cycle then I think every half year you should skip a cycle and just spend time cleaning the code up.
Siebel: So if you don't clean up every seventh cycle you may be faced with the choice of whether or not to do a big rewrite. How do you know when, if ever, it's time for a big rewrite?
Crockford: Generally the team knows when it's time. Management finds out a lot later. The team is getting beat up pretty regularly, making too many bugs; the code's too big, it's too slow; we're falling behind. They know why. It's not because they became stupider or lazier. It's because the code base is no longer serving the purpose that it needs to.
Josh Bloch on different personality types amongst programmers, leading to different specializations:
...I'm not proud of this [lack of IDE jockey skills]. Engineers have things that they're good at and things they're not so good at. There are people who would like to pretend that this isn't so, that engineers are interchangeale, and that everyone can and should be a total generalist. But this ignores the fact that there are people who are stunningly good at certain things and not necessarily so good at other things. If you force them all to do everything, you'll probably make mediocre products.
In particular there are some people who, in Kevin Bourrillion's words, "lack the empathy gene." You aren't going to be a good API designer or language designer if you can't put yourself in the shoes of an ordinary programmer trying to use your API or language to get something done. Some people are good API and language designers, though. Then there are people who are stunningly good at the technical aspects of language design where they can say, "Oh this will make the ting not LALR(1) and you need to tweak it in just such a way." That's an incredibly useful skill. But it's no substitute for having the empathy gene and knowing that you have this awful language that's unusable.
As a professional technical writer, I hope that nobody listens to Josh and Kevin on that "empathy" thing. I earn my keep writing documentation for APIs which aaaaalmost make sense but not quite. If folks start designing APIs that make sense to other folks, then I may have to learn a new profession.
More from Josh Bloch:
Siebel: Was there real user pressure for generics [in Java]? Were people complaining that the lack of generics was stopping them from writing software?
Bloch: Were real engineers bitching about the lack of generics [in Java]? I think the unfortunate answer to that question is no, they weren't. I think I was guilty of putting in something because it was neat. And because it felt like the right thing to do.
Heck, I like the idea of generics, too. Why didn't real engineers bitch about the boilerplate code? Maybe because they'd been driven away from Java by that boilerplate? Oh, wait, this isn't an inspiring conversation, this is a conversation of regret. And what a coincidence, we're talking about programming languages. Let's move on...
Really interesting to me as someone who wants to discourage makes-sense APIs for programmers and who's interested when someone gets all like Jane Goodall amongst the programmers is Simon Peyton-Jones talking about some research going on at Microsoft:
Siebel: For you, what about the relation between research and actually programming?
Peyton-Jones: Oh, they interact a lot. My area of study is programming languages. What are programming languages for in the end? They're to make it easier to program. ... One thing we're not good about is this: the proof of the pudding is in the eating, so you should watch programmers eating. That is, you should do proper, formalized studies of programmers programming and see what they do. And that's jolly expensive. And it's also more "squishy." It's harder to come up with unequivocal results.
So the culture of the programming-language community is much more, "prove that your type system is sound and complete," kind of stuff. We dodge, probably, the more important but much harder to answer questions about whether, in practice, they make people more productive. ...
...New versions of Visual Studio [Microsoft's IDE] are extensively usability tested.
Siebel: Presumably that's more for the total user interaction, rather than for programming language issues.
Peyton-Jones: Well, they also do some interesting work on testing APIs. Steven Clarke and his colleagues at Redmond have made systematic attempts to watch programmers, given a new API, talk through what they're trying to do. And they get the people who designed the API to sit behind a glass screen and watch them.
And the guys sitting there behind the glass screen say, "No, no, don't do that! That's not the right way!" But it's soundproof. That turns out often to be very instructive. They go and change their API. To be honest, programming language research is weak on that score. But it is partly because these are difficult questions to answer. And culturally we're not well adapted to do it. I regard it as a weakness. But not one that I personally feel terribly well equipped to address.
Peter Norvig points out that programmers have been trying to design too much up front for a long time
I also remember finding my father's back issues of Scientific American in the attic and going through them. These was this article by Christopher Strachey on software engineering... I read [the article] again recently and the first thing I noticed was that there's a bug in it. ... But in the [article] prose it says there's a functionmake-movewhich takes a board position and returns a move and then you look in the code and there'smake-moveand it takes a board position and an extra parameter. Apparently they wrote the prose first and then they wrote the implementation. And they found out you can't search infinitely deep so they added an extra parameter which was depth of search and you recurse down to a certain level and then you stop. They had added that in afterwards and hadn't gone back and fixed the documentation.
Bernie Cossell writes about design review meetings at BBN. He wrote a lot, and I'm not going to type the whole thing in. You can hunt it down yourself. But I typed in this part:
That takes enough confidence in your skill as an engineer to say, "Well, that's wonderful. Here's my problem. I couldn't figure out how to do this and I was hoping you guys wouldn't notice so you'd give me an OK on the design review." The implicit answer was, "Of course youre goint to get an OK on the design review because it looks OK. Let's fix that problem while we've got all the good guys here so you don't flounder with it for another week or two."
Other people talk about design reviews. Some mention the importance of separating design review from approval. Maybe the review-ee shouldn't be so worried about getting the "OK" on their project. Maybe they should be concentrating on getting advice in the areas where it will do the most good.
And there's an interview with Don Knuth, the algorithms/data structures guy. And that section was darned interesting. Not because I learned about some amazing O(n) sorting technique. No, this was something else.
When you're working on a big coding project with a lot of other people, you find yourself favoring simple designs. Like, you might say "Sure, a reverse-bifuracted Spundler-model trie built atop a 2:3 balanced splay tree would be more efficient. But if you use a hash table here, it wouldn't be that much slower. And a lot of people understand hash tables pretty well." And there are sound engineering principles for taking the simpler approach. Even if the original genius who suggested the fancy whatzit could implement it without bugs, thee's still the problem that everyone who adds a feature in that area needs to learn about the fancy whatzit.
But... these reasons feel like lame excuses. You don't feel proud presenting these reasons. They feel like we've given up. "Programmers are too stupid to learn all these complex things. So let's just give up and only use simple things." In the back of your mind you wonder... How does Knuth choose a data structure? You expect his answer to be "We tried writing the structure-choosing decision process down as a flow chart but stopped when the paper had filled three rooms. It is possible to choose the perfect data structure for any kind of data. I know how. But I gave up on trying to teach other people after my past attempts killed three grad students."
But that's not what he said. He said...
Knuth ...[When writing books] I try to explore the territory in a way that is most relevant to a practical programmer rather than the most academic cachet for getting something published that's theoretically interesting but wouldn't really be used in a real program.
The things that I leave out are where somebody has a data structure that saves a factor of log log n only when n gets bigger than two to the million. And there are lots and lots of papers that are doing that. They're playing games where in principle, if computers were godlike, then we could have algorithms that are faster. But even an algorithm like a balanced tree or AVL tree, I don't use in my own programs unless I know it's going to be a really big tree.
Siebel: What do you use?
Knuth: I use an ordinary binary search tree with a little trick for randomizing it that I just put in.
Knuth also mentions that he noticed when Josh Bloch warned the world that many many of the world's quicksort implementations, all copied and pasted from one source, had the same bug. I use that story, too, in training classes about documentaton. Not many class attendees heard that most of the world's quicksorts were broken, though it was widely announced, and quicksort is pretty important. And thus they learned an important lesson about the limited power of documentation.
I use binary search tree, just like Knuth. I use the same anecdote as Knuth. The excuses fall away. We should all accomplish as these titans have done.
