Coders at Work is a Great Book
I'm now about 3/4 of the way through Coders at Work, which is a series of interviews with software lumninaries (a good range, like Douglas Crockford, Donald Knuth, Brad Fitzpatrick, etc.). I've been truly enjoying this book, one of the better computer/software/geek books I've read in a while. There have been various points of debate further covered by Lambda and so on; big ones tend to be C++ hate and testing. I've liked reading a lot of the different points of view on what one needs to know to be a great programmer, as well as debugging techniques (a lot more print statement use than I expected!).
Since I just finished the chapter with Dan Ingalls, a couple points that caught my attention:
He's never used C or C++. For someone with his experience, it caught me by surprise. My biased view of things is that C is that "everyone" has done C. I realize these days that's very much not true, in that you have plenty of folks who've only used PHP for example. But, if you've got say 10+ years of experience, it's amazing if you've avoided C (or C++). I suspect it will still be some time before I've written more LOC in a language other than C/C++ (for me, more C++ than pure C).
And, this question and answer, to quote directly from the book, I loved. Not because it means we keep programming to us programmers, but because he nails the fact that people want to focus on what interests them, and collaborating so that you leverage your expertise and don't waste your time on something that someone else can do more efficiently and/or effectively, is great. Oh, and I love the last sentence in his answer, awesome:
Seibel: Related to that, as more and more fields rely on computing in more and more ad hoc ways, there are folks who want to find a way for "nonprogrammers" to program. Do you think that'll happen, or will domain experts, say biologists, always have to team up with programmers to build custom software to solve their problems?
Ingalls: I think there will be that kind of collaboration because the biologist isn't interested in programming it. He's interested in finding out this or that. Then there's somebody who understands how this stuff is being wored on on the computers who can help him do that. I think the thing that lets a nonprogrammer program is an application.
Get the book, it's good stuff. A few notes about me, in relation to common themes:
- I like testing, and believe in automated test suites, etc. I like TDD, BDD, and TFD, etc., but I'm not insanely strict about it either.
- I've done a ton of C++ (e.g. Photoshop and other desktop apps), and at this point, especially after things like templates and so on, find it repulsive.
- I don't believe you have to know the hardware or assembly language to be a great coder - unless what you're coding is particularly impacted by that. Ingalls talks about this a bit too.
Oh, one last thing the book has inspired, or really, has further motivated me on, is to [re]learn some other, what I'd consider non-mainstream languages (depends on your POV). In particular Lisp, or in my case, I'm poking around with Clojure (I did scheme stuff in school, and loved it, but it's been a long time since I've done any lisp or scheme code, nor have I written a significant app/program with it) and Simon Peyton Jones' interview inspired me to look at Haskell. I've been quite interested in functional programming in general lately. I've spent some time with an Erlang book, but honestly the syntax just repulsed me and thus I'd rather look at something else (Armstrong's interview was also interesting, not that any of them weren't). I'm after the functional stuff more for the principles they pursue, and don't really expect to use them specifically, so I'd rather spend time with one where the syntax is more appealing. Fun.
