Slashdot Mirror
Coders At Work
Vladimir Sedach writes "Aside from authoring narrowly focused technical books, teaching
university courses, or mentoring others in the workplace, programmers
don't often get a chance to pass on the knowledge of the practise of
programming as a profession. Peter
Seibel's Coders at Work takes fifteen world-class
programmers and distills their wisdom into a book of interviews with
each of them." Keep reading for Vladimir's review.
Coders at Work
author
Peter Seibel
pages
632
publisher
Apress
rating
8
reviewer
Vladimir Sedach
ISBN
978-1430219484
summary
How the best programmers in the world do their job
The list of coders interviewed includes some geek household names
like Donald Knuth and jwz, but also some not so well-known ones such
as Bernie Cosell (one of the programmers behind the ARPANET IMP, the
first Internet router) and Fran Allen (compiler pioneer). The full
list of people interviewed is available on the book's website. The eras
embodied by the interviewees range from the very beginnings of
software as we know it today, to the heyday of the Internet boom, when
people like Brad Fitzpatrick made their mark.
Seibel himself is a coder and author (having the well-received Practical Common Lisp under his belt). It is then no surprise that the interviews are packed with technical details, which (with one exception, explained below) restricts the intended audience of the book to those already familiar with programming.
Coders at Work manages to communicate the wisdom of programmers of bygone eras, while simultaneously being heavily colored by very contemporary issues. JavaScript, its consequences and its discontents, is a topic recurring throughout the book. More than just a recounting of history, Coders at Work should inspire readers to learn about the wider context of their craft and stop the reinvention of the proverbial wheel decried by several of the interviewees in its pages.
Given the related subject matter, the people interviewed in Coders at Work who played a role in creating major programming languages (Armstrong, Eich, and Steele), and close publication dates of the two books, inevitable comparisons will be drawn between Coders at Work and Federico Biancuzzi and Shane Warden's Masterminds of Programming (I previously reviewed Masterminds of Programming on my blog). There is a lot of common ground between the two books in terms of technical areas covered, but Coders at Work clearly comes out on top.
Part of the reason has to do with the fact that Seibel's choice of interviewees is stellar. Masterminds of Programming's niche focus on programming language designers meant that its authors had a tougher job than Seibel, but details like the omission of Alan Kay (creator of Smalltalk and one of the most influential programming language designers in the field's history) from Masterminds are nothing short of dumbfounding.
Just as important to making Coders at Work a good book is the fact that Seibel is a great interviewer. Seibel's questions felt more open-ended than those in Masterminds, and the resulting interviews have a flow and narrative that makes them engrossing to read and gives the programmers interviewed a chance to explore details in-depth.
A refreshing aspect of Coders at Work are the interviewees who don't shy away from strong opinions or humor, as shown in this remark by Peter Deutsch, "I think Larry Wall has a lot of nerve talking about language design--Perl is an abomination as a language." One aspect where Coders unintentionally shines is as a guide to finding and hiring programming talent. Even non-technical managers will benefit greatly by reading those excerpts of the interviews concerned with hiring programmers.
Another unexpected aspect of the book is the breadth of topics discussed — everything from debugging machine code to women's issues in computing workplace and education.
One area where Coders could stand improvement is in its length. Not all of the coders interviewed possessed the gift of brevity, and many interview answers could have been edited to reduce their length without affecting the message.
In her interview, Fran Allen makes an interesting assertion — programming and computer science need to become more socially relevant. Other scientific and engineering fields are filled with well-known personalities, described in prominent interviews, biographies, and major Hollywood films. The only "software people" to appear in the public spotlight are the CEOs of major software firms. Ultimately, its role in helping programming assert its status as a socially relevant profession may be the most important contribution of Coders at Work.
You can purchase Coders at Work from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Seibel himself is a coder and author (having the well-received Practical Common Lisp under his belt). It is then no surprise that the interviews are packed with technical details, which (with one exception, explained below) restricts the intended audience of the book to those already familiar with programming.
Coders at Work manages to communicate the wisdom of programmers of bygone eras, while simultaneously being heavily colored by very contemporary issues. JavaScript, its consequences and its discontents, is a topic recurring throughout the book. More than just a recounting of history, Coders at Work should inspire readers to learn about the wider context of their craft and stop the reinvention of the proverbial wheel decried by several of the interviewees in its pages.
Given the related subject matter, the people interviewed in Coders at Work who played a role in creating major programming languages (Armstrong, Eich, and Steele), and close publication dates of the two books, inevitable comparisons will be drawn between Coders at Work and Federico Biancuzzi and Shane Warden's Masterminds of Programming (I previously reviewed Masterminds of Programming on my blog). There is a lot of common ground between the two books in terms of technical areas covered, but Coders at Work clearly comes out on top.
Part of the reason has to do with the fact that Seibel's choice of interviewees is stellar. Masterminds of Programming's niche focus on programming language designers meant that its authors had a tougher job than Seibel, but details like the omission of Alan Kay (creator of Smalltalk and one of the most influential programming language designers in the field's history) from Masterminds are nothing short of dumbfounding.
Just as important to making Coders at Work a good book is the fact that Seibel is a great interviewer. Seibel's questions felt more open-ended than those in Masterminds, and the resulting interviews have a flow and narrative that makes them engrossing to read and gives the programmers interviewed a chance to explore details in-depth.
A refreshing aspect of Coders at Work are the interviewees who don't shy away from strong opinions or humor, as shown in this remark by Peter Deutsch, "I think Larry Wall has a lot of nerve talking about language design--Perl is an abomination as a language." One aspect where Coders unintentionally shines is as a guide to finding and hiring programming talent. Even non-technical managers will benefit greatly by reading those excerpts of the interviews concerned with hiring programmers.
Another unexpected aspect of the book is the breadth of topics discussed — everything from debugging machine code to women's issues in computing workplace and education.
One area where Coders could stand improvement is in its length. Not all of the coders interviewed possessed the gift of brevity, and many interview answers could have been edited to reduce their length without affecting the message.
In her interview, Fran Allen makes an interesting assertion — programming and computer science need to become more socially relevant. Other scientific and engineering fields are filled with well-known personalities, described in prominent interviews, biographies, and major Hollywood films. The only "software people" to appear in the public spotlight are the CEOs of major software firms. Ultimately, its role in helping programming assert its status as a socially relevant profession may be the most important contribution of Coders at Work.
You can purchase Coders at Work from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I still think "Microserfs" is the best book about coders, ever. I worked as a programmer in Seattle for a year back in the late 90's and it was pretty much dead on.
Floating in the black seas of infinity without a paddle.
I know I am not alone in deploring the puerile comments and immature attitudes of male programmers.
In every computing workplace where I have worked, men have behaved like sex-crazed animals and women have *never* felt comfortable working topless.
Rich And Stupid is not so bad as Working For Rich And Stupid.
by "work" they must mean reading slashdot all day.
I found Writing Solid Code (Maguire, 1993) worth the read. Sure, some of what's in there is dated but many of the concepts are timeless and part of today's conventional wisdom.
Things like coding for security, coding for readability/maintenance, etc. etc.
Granted, those concepts weren't new in 1993 either, but many in the generation of programmers that cut their teeth on Turbo Pascal and 8-bit-machine BASIC never learned the lessons from 1960s mainframe code jockeys.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Yes, it must be refreshing all right, listening to aging Computer "Scientists" reciting crap that's been stale for years. It certainly is courageous for an ACM member to continue the smear campaign against perl. His friends in the gentleman's club will be shocked at his outspokeness.
You might think that the obvious utility of perl, the fact that perl and perl derived languages remain tremendously popular with people writing actual code, might blunt the man's opinion that it's an "abomination". Is it at all possible that Larry Wall got a few things right, and that the CS field's decades-long obsession with elegance and reductionism was somewhat misplaced?
(And if you want to take the line that the CS attitude is correct, how would you prove that it's correct? Writing working code is evidently not relevant. And if you can't prove it, then what does the "S" stand for in "CS"?)
FTFS: "In her interview, Fran Allen makes an interesting assertion â" programming and computer science need to become more socially relevant."
How do you recognize the extroverted programmer? He's the one staring at *your* shoes.
Same goes for engineers. Name a well-known (outside of engineering) engineer. I'll wait ...
Since programming involves long hours alone staring at a computer screen, it's no surprise it tends to attract people who don't mind or even enjoy being alone, and for whom self-promotion is fairly low on the to-do list.
I am officially gone from
I'm disguted, repeatedly, at what passes for applications these days. Back when I started we wrote tight, purposeful code and optimised for speed or size. But now I'm constantly encountering untested code, applications which have the most bombastic interfaces, layouts which seem more ad hoc than well planned and a dozen other gripes.
Can't be all the coders faults. Whatever happened to Q/A? Whatever happened to analysts who have a clue? I keep seeing people who have no background in IT making decisions and overruling experince wiht seat of the pants decisions. Even to the point of corrupting data and having no fall-back plan.
I feel I need to retire, but I'm many, many years from that.
I'd like a book which discusses the EPIC FAIL of present day standards and practices of software development.
A feeling of having made the same mistake before: Deja Foobar
Judging from the construction of his statement*, not Steven Colbert. That narrows it down a bit.
*My evidence? The use of the "or" conjunction, which in English is semantically equivalent to a logical XOR.
Welcome to the Panopticon. Used to be a prison, now it's your home.
I'm disguted, repeatedly. . .
Sounds painful. Hope you get over it soon.
What?
Another similar book that is no longer in print is the semi-classic, Programmers at Work subtitled Interviews With 19 Programmers Who Shaped the Computer Industry, (1986 /1989) by Susan Lammers which includes interviews with well-known or pioneer programmers such as Charles Simonyi (Microsoft), Bill Gates, Gary Kildall (Intergalactic Digital Research), Andy Hertzfield (Macintosh Operating System), John Warnock (Postscript) and C. Wayne Ratcliff (dBASE).
Ah yes, "They Don't Make Them Like They Used To."
Bugs have been around forever. Q/A has been troublesome since the beginning - heck, many of the problems outlined in the Unix Hater's Handbook were the direct result of poor Q/A throughout the... erm... Unixverse. Bloated code? That's been around as long as there's been code - heck, INTERCAL was explicitly designed to produce it! People with no background in IT making decisions and overruling experience? That's also been happening for ages.
That said, I'll give you credit on one thing - yeah, your code was tight, purposeful and optimized for speed or size, at least as far as the machine was concerned. You didn't have a choice. Instead of focusing on maintainability or ease of understanding, programmers had to bend to the machine's thinking instead of the other way around since there just wasn't enough machine to tolerate human weakness. Eventually, though, computers became powerful enough where programming could stop focusing on getting every last clock cycle's worth by any means necessary and more on solving programming problems quickly and easily. Put another way, the programmer's time finally became more valuable than the machine's time. Once that happened, the rules changed - something which those some of those people with "no background in IT" figured out years ago (I hear it's because they had a background in some dark discipline called "accounting") and which a lot of IT people still can't wrap their minds around.
So, instead of writing a narrowly focused technical book, they wrote a narrowly focused technical book?
If working down on the corporate cube farm has shown me anything - it's that non-technical managers produce atrocious applications. Unbelievably expensive. Too slow to be used in spite of the cost. Rejected by users, because they are seldom part of the development team.
I can predict, fairly accurately, the outcome of a corporate development effort from the answer to these questions:
Is the business sponsor and the user team deeply involved in an Agile/Iterative way throughout the development effort?
Is the actual technical side of the development led by a technical manager with real authority?
Does he or she have their choice of tools and technology without interference from above or corporate IT's "Best Practices"?
Are requirements managed flexibly, with early deliverables of basic functionality followed up be newly discovered needs?
The biggest breakthrough in coding, reflected in the biographies of the coder interviewed, is a return to smaller teams, guided by involved end users. In other words, rediscovering earlier practices and respect for the lessons of the Mythical Man Month.
"Knowing everything doesn't help..."
That guy is a relic of another age, and certainly not a coder; he's purely an academic in theoretical computer science.
He's good at making algorithms, but certainly not at coding.
You're ignorant. Have you ever used TeX or METAFONT? Knuth wrote them. The CWEB compiler? Knuth again. How about the MMIX simulator and assembler for MMIX architecture that Knuth designed to go along with TAOCP? Yep, Knuth. Want some more? See:
http://www-cs-staff.stanford.edu/~uno/programs.html
Whatever happened to Q/A? Whatever happened to analysts who have a clue?
"Agile programming" happened. No need to figure out the requirements up front, they're going to change anyway. No need to architect the system, we'll just use a "framework" and add features.
This works OK for web sites in PHP, but don't try to do hard real time or database internals or secure software that way. Agile programming will give you a set of loosely coupled features, but for many user-facing applications, that's good enough.
Interestingly, I do wonder how Knuth would be rated in these days of massive (have you seen Java recently?) APIs, agile, test-driven development ? One thing that seems in common with all these guys is that they have written code which is of the old-school low-level infrastructural variety. His algorithm code is awesome, but a little spartan on the variable naming conventions. This is coming from someone who has an autographed set of TaoCP (and attended his occasional rare seminars).
Does the book actually have interviews with the front-liner programmers who have to deal with product management and managers in their day to day development work on web apps?
Winton
You'll find him in "Programmers At Work" by Susan Lammers. That book was published by Microsoft Press back in 1986.
LOL. From my perspective, all computer programming languages are abominations. They are ancient primitive relics of what I call the Babbage and Lovelace era. They should all be placed in the Smithsonian right next to the buggy whip and the slide rule. I live for the day when a constitutional amendment is passed to ban them all. :-D
So your solution is a concurrent language using diagrams in place of syntax?
I'm not about to tell you the COSA approach is a bad idea, and I'd hate to discourage someone who's obviously got a lot of interest in making a system that really is better... But I have my doubts about visual programming languages in general. Mainly because it bypasses the established mechanisms humans have developed for conveying complex ideas (i.e. writing) in favor of visual diagrams - you lose the capability to convey a large volume of information effectively in a reasonably small space - or at least it seems you would. At any rate I can't figure out how those node graphs work...
And your statements about reliability? In what sense can a logic circuit be "guaranteed" free of defects? Did Intel know about this method of quality assurance back when they were designing the Pentium? It seems to me that simple logic circuits can be guaranteed free of defects because the human mind can readily model the whole system and intuitively decide it is correct. When the system is complex, that is no longer true.
I donâ(TM)t want to know about how to implement loops, tree structures, search algorithms and all that other jazz. If I want my program to save an audio recording to a file, I donâ(TM)t want to learn about frequency ranges, formats, fidelity, file library interface, audio library interface and so forth. This stuff really gets in the way.
It seems as though you've just said you want someone else to solve your problems for you.
To a certain extent this is quite reasonable. If you want to save an audio recording, it's reasonable to expect someone else to have come up with a program that will make it easy for you. This is why we have "sound recorder" applications and the like.
But what if you're the first person to write such a program? Or what if, for whatever reason (i.e. licensing issues, etc.) you can't use the work that's already been done? Then it seems to me that there's no way around it: you simply must understand about audio formats and deal with them on their own terms.
Likewise, suppose you want a program that can calculate a route to drive from Baltimore to Chicago. Of course it's been done: you can go ask Google for the route... But what if you want your own program that does this? Like if you wanted to compete with Google and get in the computer-map business? Then you'd need one of those pesky algorithms to turn that big pile of data into a usable route. The problem's not practically solvable unless you approach it with the right kind of strategy, that's exactly what an algorithm is. It's not practical to expect that all the problems in the world have already been solved by whoever created your language toolkit - if it were, then I'd be out of a job.
Bow-ties are cool.
I hear you. I remember when, back on my Apple II+, I could write new music on my sequencer (with fully sampled orchestral sounds - no external hardware needed), download new mp3s from Amazon.com, and chat in real-time with some friends, all at the same time. I remember how easy it was to stream real-time video wirelessly to my TV. Programming interfaces was a snap as well, with fully-featured APIs available for several different flavors of operating systems.
I remember how just about any information you could want was available on the Internet with just a click of a mouse. I especially loved how I could order just about anything online - no more hectic holiday shopping for me! Also, remember how awesome the videogames used to look and play? Why, those first-person shooters practically looked photo-realistic. It was amazing how well they ran on such old hardware.
Integrating new hardware and devices was far easier as well. We could just pick up a new gizmo and plug it to the Apple II's USB port, and damned if the computer didn't just instantly recognize it and load up some drivers. Best of all, you could pick up a new, reasonably powerful computer for about $1000 or so.
Man, those were the days... Oh, wait. I'm thinking of *today's computers*.
Irony: Agile development has too much intertia to be abandoned now.
How would you handle loops or complicated algorithms with many conditional paths in such a language? Languages are designed to solve practical problems, not to just to look pretty.
Real software developers code. Sure, they do other important work as well, but code is the work product. Every single person I've ever worked with who denied this was a crap coder who could write a clear design doc (but great at PowerPoint, or Project, or other busywork).
Socialism: a lie told by totalitarians and believed by fools.
This is one of those funny things about software. Software is so valuable, people are willing to use it even when it's buggy. No one wants to go back to the manual way once they are shown the automated way. It is often less work to workaround the defects than to go back to no software.
Combine that value proposition with the fact that software demand way outstrips supply, and you get a lot of marginal software.
Cars were like this once before too. MG owners know what I am talking about. Cars used to be far less reliable than buggy software from a major vendor. No one remembers anymore, cause the Japanese cleaned their clocks, and they are all gone now. (Miata anyone?)
Next time you see an MG, ask the driver how many parts cars he has in his garage to keep that one running. My uncle used to have 2 parts cars for every running MG.
But if I said that 2/3 of your software would basically not run, and you'd have to harvest DLL's from 2 of them to keep the third one running, you'd go nuts. But that's how cars were for a long long time. Just like software is now. /shrug. Move along, nothing to see!
I have mixed feelings towards the people cited as "all-time great programmers and computer scientists", at least the ones I know anything about.
Ken Thompson. The one, absolute no-brainer for inclusion, because he's the most influential programmer ever, without exception. His minimalistic approach to OS design and API specification has had a profound effect on how people think software platforms. I started to study programming before Unix became widely used, and the sheer baroqueness of pre-Unix OS's is far beyond what younger programmers can imagine. Even if you've never read anything this guy has written, you've been influenced by his ideas. We all owe him big time.
Donald Knuth. His contributions are pretty major. But the paradigms he uses to talk about programming are thoroughly obsolete. And I do not understand his obsession with finishing an unfinishable book.
Josh Bloch. I've had the pleasure of actually working with him. Brilliant dude, and certainly someone all programmers should listen to. (And he doesn't get enough credit for his contributions to the design of Java.) But calling him a programmer is a bit like calling Frank Lloyd Wright a "builder".
Jamie Zawinski. I don't know that much about the guy, but what I do know makes me unwilling to accept his opinion on anything. I'm informed mainly by the config files for early versions of Netscape Navigator. JWZ's comments in these files were the only documentation I could find for making the browser work with PC keyboards under Linux. These were short of useful information and long on rants about the supposed shortcomings of various hardware vendors. These would have been stupid and unprofessional, even if they hadn't been arrogant and poorly informed. (No Jamie, Alt and Meta are not the same thing.) And isn't his main claim to fame his contribution to the Netscape code base? Most of which was simply abandoned as unmaintainable when NS's projects got taken over by Mozilla and Sun.