Coders At Work 207
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.
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.
| 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 |
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.
Socially relevent (Score:5, Insightful)
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.
Biggest Gripe about coding .. shouldn't be coders (Score:5, Insightful)
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.
Re:Microserfs (Score:5, Insightful)
Re:ah yes, anti-perl tirades are refreshing (Score:5, Insightful)
Re:ah yes, anti-perl tirades are refreshing (Score:4, Insightful)
The thing is, from an application standpoint, I wouldn't consider perl a programming language. To me, it's an advanced scripting langauge. And it does that really, really well. But as a programming language, it isn't exactly the best.
Re:Biggest Gripe about coding .. shouldn't be code (Score:5, Insightful)
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.
Re:Microserfs (Score:5, Insightful)
The look of disappointment on the faces of the major news anchors was priceless and underscored their severe lack of understanding of technology.
It was if someone had said that a bridge needs repairs (the experts can see the rot), the billions were spent fixing the bridge and when the first person crossed the bridge it did not collapse. Then they whine that there is no sensational story, that the bridge would not have fallen anyway and why was the money spent, what a waste?
I hate news people. I find them shallow, news bite hunting morons.
Re:Coders that work? (Score:4, Insightful)
So, instead of writing a narrowly focused technical book, they wrote a narrowly focused technical book?
Re:Socially relevent (Score:3, Insightful)
Same goes for engineers. Name a well-known (outside of engineering) engineer. I'll wait ...
Imhotep - Ancient Egypt.
Leonardo DaVinci - Renaissance
David Fisher - Present (Dynamic rotating tower thing).
Come on now, You can't clump Engineers into the same group as computer scientists, they've been around for ages.
The Well of Uncomfortable Truths (Score:5, Insightful)
LOL. From my perspective, all computer programming languages are abominations [blogspot.com]. 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.
Re:ah yes, anti-perl tirades are refreshing (Score:3, Insightful)
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".
Excuse me, but why can't it be both? It's nasty, but it works for a lot of things. That said, python does what perl does with easier syntax, so I'll be using that.
Re:I Hate All Programming Languages (Score:3, Insightful)
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.
Re:ah yes, anti-perl tirades are refreshing (Score:2, Insightful)
As for Perl... Whether or not people have said bad things about Perl before, whether or not people do good work in Perl, I can't find fault in anyone who feels it's still worth mentioning that Perl is a horrible jumble of a computer language.
People do lots of good work in English too, including writing computer code (all the syntax, keywords, etc. are in English), doing aviation, and many other thing. But English is a horrible jumble of a language.
Re:ah yes, anti-perl tirades are refreshing (Score:5, Insightful)
I come from a physics background and most physicists used to, and may still, program in FORTRAN, yet FORTRAN is a terrible programming language.
They use Fortran because the language is designed and optimized to be the best language at what physicists and other physical scientists most often need it do: crunch a whole lot of numbers. I wouldn't use Fortran to make a word processor or web browser, but if you need a program to spend two weeks doing a lot of math, you just can't beat it.