What do you think?
Rate this book
Coders at Work: Reflections on the Craft of Programming
Peter Seibel interviews 16 of the most interesting computer programmers alive today in Coders at Work, offering a brand-new companion volume to Apress’s highly acclaimed best-seller Founders at Work by Jessica Livingston. As the words "at work" suggest, Peter Seibel focuses on how his interviewees tackle the day–to–day work of programming, while revealing much more, like how they became great programmers, how they recognize programming talent in others, and what kinds of problems they find most interesting.
Hundreds of people have suggested names of programmers to interview on the Coders at Work web site: http://www.codersatwork.com. The complete list was 284 names. Having digested everyone’s feedback, we selected 16 folks who’ve been kind enough to agree to be interviewed:
- Frances Allen: Pioneer in optimizing compilers, first woman to win the Turing Award (2006) and first female IBM fellow
- Joe Armstrong: Inventor of Erlang
- Joshua Bloch: Author of the Java collections framework, now at Google
- Bernie Cosell: One of the main software guys behind the original ARPANET IMPs and a master debugger
- Douglas Crockford: JSON founder, JavaScript architect at Yahoo!
- L. Peter Deutsch: Author of Ghostscript, implementer of Smalltalk-80 at Xerox PARC and Lisp 1.5 on PDP-1
- Brendan Eich: Inventor of JavaScript, CTO of the Mozilla Corporation
- Brad Fitzpatrick: Writer of LiveJournal, OpenID, memcached, and Perlbal
- Dan Ingalls: Smalltalk implementor and designer
- Simon Peyton Jones: Coinventor of Haskell and lead designer of Glasgow Haskell Compiler
- Donald Knuth: Author of The Art of Computer Programming and creator of TeX
- Peter Norvig: Director of Research at Google and author of the standard text on AI
- Guy Steele: Coinventor of Scheme and part of the Common Lisp Gang of Five, currently working on Fortress
- Ken Thompson: Inventor of UNIX
- Jamie Zawinski: Author of XEmacs and early Netscape/Mozilla hacker
What you’ll learn:
How the best programmers in the world do their job
Who is this book for?
Programmers interested in the point of view of leaders in the field. Programmers looking for approaches that work for some of these outstanding programmers.
Hundreds of people have suggested names of programmers to interview on the Coders at Work web site: http://www.codersatwork.com. The complete list was 284 names. Having digested everyone’s feedback, we selected 16 folks who’ve been kind enough to agree to be interviewed:
- Frances Allen: Pioneer in optimizing compilers, first woman to win the Turing Award (2006) and first female IBM fellow
- Joe Armstrong: Inventor of Erlang
- Joshua Bloch: Author of the Java collections framework, now at Google
- Bernie Cosell: One of the main software guys behind the original ARPANET IMPs and a master debugger
- Douglas Crockford: JSON founder, JavaScript architect at Yahoo!
- L. Peter Deutsch: Author of Ghostscript, implementer of Smalltalk-80 at Xerox PARC and Lisp 1.5 on PDP-1
- Brendan Eich: Inventor of JavaScript, CTO of the Mozilla Corporation
- Brad Fitzpatrick: Writer of LiveJournal, OpenID, memcached, and Perlbal
- Dan Ingalls: Smalltalk implementor and designer
- Simon Peyton Jones: Coinventor of Haskell and lead designer of Glasgow Haskell Compiler
- Donald Knuth: Author of The Art of Computer Programming and creator of TeX
- Peter Norvig: Director of Research at Google and author of the standard text on AI
- Guy Steele: Coinventor of Scheme and part of the Common Lisp Gang of Five, currently working on Fortress
- Ken Thompson: Inventor of UNIX
- Jamie Zawinski: Author of XEmacs and early Netscape/Mozilla hacker
What you’ll learn:
How the best programmers in the world do their job
Who is this book for?
Programmers interested in the point of view of leaders in the field. Programmers looking for approaches that work for some of these outstanding programmers.
632 pages, Paperback
First published September 1, 2009
574 people are currently reading
8651 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 283 reviews
December 1, 2009
One of my many, many areas of deep intellectual insecurity is computer programming.
As a kid I remember writing BASIC programs on paper in the backseat of the car during family trips to Florida. I also remember spending hours on my Vic 20 as a kid and even crashing it a few times trying to execute 6502 assembly with POKE and JMP. I whizzed through FORTRAN and Pascal my freshman year at Purdue.
Then tragedy struck the next year as I got my first B in college from a microprocessor class based on the Motorola 6809. Later I had to drop a class in C because I could not get my head around pointers. After that I embraced the beautiful equations of Maxwell and Laplace and disdained the impure applied science of computers.
A few years later I was in Silicon Valley begging for a job working with computers after seeing the bleak career of an RF engineer as a coop student. It was a smart move, but even after working in high tech for 20 years I still feel sometimes like I'm on the outside looking in.
So I was eager to read these interviews with 15 luminaries in computer science and maybe get the answers to questions I was always too embarrassed to ask. It felt very satisfying to read, and I was not disappointed at all. Some of the interviews were dry and scholarly, but most were very interesting and thoughtful. I eventually had to put post-it notes on the inside cover to write down all the names and concepts that I need to follow up on now that I'm done with this book.
It's a shame that none of the coders is as famous as the founders interviewed in the very similar book Founders At Work. Ken Thompson and Peter Norvig were the only two I had heard of before reading this book. Some of these interviews, notably with Brad Fitzpatrick and Ken Thompson, made me want to put the book down and do a Wayne's World-esque "I'm not worthy!" genuflection.
The biggest surprise in this book is that almost everyone mentioned using print statements as their main method of debugging programs. I always felt like I was cheating when I did this. But hey if it's good enough for them...
Other surprises: A lot of these people work for Google and are surprisingly open about the processes used there. Norvig's comments on the hiring process got some news coverage when the book came out. I guess the Google PR people don't harass the big shots as much as the rest of their people.
Another surprise was hearing some of these people complaining about C and C++. I dutifully plowed my way through K&R (and may do so again), but I never thought to voice my complaints out loud. Fran Allen in particular has harsh things to say about C. ("We have seriously regressed, since C developed. C has destroyed our ability to advance the start of the art...")
Someone else (forget who) said that he never wanted a degree in CS because it was like getting a degree in Microsoft. Equating computer science with trade school was my snobby rationalization for not pursuing computer science, but most of the people interviewed described what they did as a craft. I think that is more accurate.
Highly recommended. Now I want to find a copy of Programmers at Work, released more than 20 years before this book, interviewing people like Bill Gates and John Warnock. I wonder what the people in Coders At Work will be doing in 20 years.
As a kid I remember writing BASIC programs on paper in the backseat of the car during family trips to Florida. I also remember spending hours on my Vic 20 as a kid and even crashing it a few times trying to execute 6502 assembly with POKE and JMP. I whizzed through FORTRAN and Pascal my freshman year at Purdue.
Then tragedy struck the next year as I got my first B in college from a microprocessor class based on the Motorola 6809. Later I had to drop a class in C because I could not get my head around pointers. After that I embraced the beautiful equations of Maxwell and Laplace and disdained the impure applied science of computers.
A few years later I was in Silicon Valley begging for a job working with computers after seeing the bleak career of an RF engineer as a coop student. It was a smart move, but even after working in high tech for 20 years I still feel sometimes like I'm on the outside looking in.
So I was eager to read these interviews with 15 luminaries in computer science and maybe get the answers to questions I was always too embarrassed to ask. It felt very satisfying to read, and I was not disappointed at all. Some of the interviews were dry and scholarly, but most were very interesting and thoughtful. I eventually had to put post-it notes on the inside cover to write down all the names and concepts that I need to follow up on now that I'm done with this book.
It's a shame that none of the coders is as famous as the founders interviewed in the very similar book Founders At Work. Ken Thompson and Peter Norvig were the only two I had heard of before reading this book. Some of these interviews, notably with Brad Fitzpatrick and Ken Thompson, made me want to put the book down and do a Wayne's World-esque "I'm not worthy!" genuflection.
The biggest surprise in this book is that almost everyone mentioned using print statements as their main method of debugging programs. I always felt like I was cheating when I did this. But hey if it's good enough for them...
Other surprises: A lot of these people work for Google and are surprisingly open about the processes used there. Norvig's comments on the hiring process got some news coverage when the book came out. I guess the Google PR people don't harass the big shots as much as the rest of their people.
Another surprise was hearing some of these people complaining about C and C++. I dutifully plowed my way through K&R (and may do so again), but I never thought to voice my complaints out loud. Fran Allen in particular has harsh things to say about C. ("We have seriously regressed, since C developed. C has destroyed our ability to advance the start of the art...")
Someone else (forget who) said that he never wanted a degree in CS because it was like getting a degree in Microsoft. Equating computer science with trade school was my snobby rationalization for not pursuing computer science, but most of the people interviewed described what they did as a craft. I think that is more accurate.
Highly recommended. Now I want to find a copy of Programmers at Work, released more than 20 years before this book, interviewing people like Bill Gates and John Warnock. I wonder what the people in Coders At Work will be doing in 20 years.
November 3, 2011
Coders at Work is one long read into the lives of several fantastic computer scientists, the software-writing variety. Peter Seibel interviews sixteen "programmers", among them Joe Armstrong (Erlang), Brad Fitzpatrick (OpenID, memcached), Simon Peyton Jones (Haskell), THE Donald Knuth, Peter Norvig (AI), and Ken Thompson (UNIX). A few of the missing topics: high-performance computing, social networking, peer-to-peer file-sharing, more Internet.
Each interview goes over a number of standard questions, ranging from biographical to technical to philosophical: How did you learn to program? What is the role of documentation? What is the role of testing? What is the worst bug you have faced in your career? What is the best way to debug? What is the role of computer science courses, in particular assembly, in your career? What is the role of math in your career? How big were the teams in which you worked? What is your best achievement? Is your work science, engineering, or art? How does your schedule affect your family and social life? Seibel also tailors questions for each interviewee, knowing well their biography and confronting them about milestones, contacting former professors and current friends, creating ties between different interviewees, etc.
The book is very long, but this is because each interview tries to capture not only the answers, but also the essence of the interlocutor. We get to appreciate the kindness and open spirit of Simon Peyton Jones, the non-nonsense attitude of Donald Knuth, the die-hard approach of Joe Armstrong, etc. I found this immensely appealing and well-worth the wordiness.
A few of the lessons:
- Most interviewees have started programming early, and among their early programs were games;
- Most interviewees had a middle-class to rich family and did not have to struggle much in life;
- There is no programming language that can do all, but C++ is widely regarded as an abomination;
- Modern programming languages include C (performance), Python (prototyping), Erlang (distributed, fault-tolerant);
- Assembly is regarded as either still important and relevant as part of computer science curriculum, or completely outdated--in the latter case, it still teaches you how to think about low-level problems;
- Math is not seen as important as a whole, but computer scientists should learn parts depending on their branch of work (cryptography, graphics, etc. do require math);
- The most difficult to debug programs are related to concurrency, parallelism, multi-users;
- The most successful pieces of software are written alone or in small teams; once the team enlarges past, say, ten people, the ability to deliver becomes rare;
- Working in this field does not necessarily lead to long hours, but it drains physically and psychically, and affects negatively family and social life;
- Often, the best achievement is just shipping.
All in all, an amazing book about computer scientists, and an absolute must read for anyone with aspirations for this industry.
Each interview goes over a number of standard questions, ranging from biographical to technical to philosophical: How did you learn to program? What is the role of documentation? What is the role of testing? What is the worst bug you have faced in your career? What is the best way to debug? What is the role of computer science courses, in particular assembly, in your career? What is the role of math in your career? How big were the teams in which you worked? What is your best achievement? Is your work science, engineering, or art? How does your schedule affect your family and social life? Seibel also tailors questions for each interviewee, knowing well their biography and confronting them about milestones, contacting former professors and current friends, creating ties between different interviewees, etc.
The book is very long, but this is because each interview tries to capture not only the answers, but also the essence of the interlocutor. We get to appreciate the kindness and open spirit of Simon Peyton Jones, the non-nonsense attitude of Donald Knuth, the die-hard approach of Joe Armstrong, etc. I found this immensely appealing and well-worth the wordiness.
A few of the lessons:
- Most interviewees have started programming early, and among their early programs were games;
- Most interviewees had a middle-class to rich family and did not have to struggle much in life;
- There is no programming language that can do all, but C++ is widely regarded as an abomination;
- Modern programming languages include C (performance), Python (prototyping), Erlang (distributed, fault-tolerant);
- Assembly is regarded as either still important and relevant as part of computer science curriculum, or completely outdated--in the latter case, it still teaches you how to think about low-level problems;
- Math is not seen as important as a whole, but computer scientists should learn parts depending on their branch of work (cryptography, graphics, etc. do require math);
- The most difficult to debug programs are related to concurrency, parallelism, multi-users;
- The most successful pieces of software are written alone or in small teams; once the team enlarges past, say, ten people, the ability to deliver becomes rare;
- Working in this field does not necessarily lead to long hours, but it drains physically and psychically, and affects negatively family and social life;
- Often, the best achievement is just shipping.
All in all, an amazing book about computer scientists, and an absolute must read for anyone with aspirations for this industry.
November 12, 2009
What felt missing to me, and why this is only 4 stars, was any attempt to pull the interviews together and synthesize something from them.
Instead, we get a book where, for example, N-1 coders are asked if they read Knuth right through, or use it for reference, or have not read it; and this is followed by Knuth basically demolishing the foundations of any conclusions you might be able to make from their answers, with a offhand comment that "I sometimes wonder if I can read them."
Anyway, this book was a much happier book for me than Beautiful Code. The interview style does mean that you feel you get to know most of the participants, and there is plenty of humbling and inspirational stuff, lots of interesting history, as well as lots of places where these big names show they're only human too -- for example, coder after coder fesses up to using print statements for debugging.
Seibel got access to a great set of people, gave some quite good interviews where he managed some impressive followup questions on a wide and historically deep set of topics, and somehow got it to all hold together. Well done.
Instead, we get a book where, for example, N-1 coders are asked if they read Knuth right through, or use it for reference, or have not read it; and this is followed by Knuth basically demolishing the foundations of any conclusions you might be able to make from their answers, with a offhand comment that "I sometimes wonder if I can read them."
Anyway, this book was a much happier book for me than Beautiful Code. The interview style does mean that you feel you get to know most of the participants, and there is plenty of humbling and inspirational stuff, lots of interesting history, as well as lots of places where these big names show they're only human too -- for example, coder after coder fesses up to using print statements for debugging.
Seibel got access to a great set of people, gave some quite good interviews where he managed some impressive followup questions on a wide and historically deep set of topics, and somehow got it to all hold together. Well done.
December 27, 2009
The book was requested by my 20-year old son, who is a computer science major studying programming language, for his birthday. I browsed through it, found it interesting and ended up reading the whole thing. This book satisfied the geek in me. It was self-validating for me to read about others who are passionate about software development - its not something you read about often. Quite a few of the people interviewed were actually quite a bit older than me - so it was interesting to read about the evolution of the craft that I've seen come and go. It would have been interesting to include more (and younger) females in the book - only one was interviewed.
October 12, 2009
Four start with a big asterisk.
Overall, this is a fascinating book that any programmer will enjoy. Seibel does a nice job asking questions that are particular to each person, but also trying to get a variety of opinions on the same questions that face all programmers. (E.g., how do you debug? how do you read new code? how do you identify good programmers?)
The problem with the book is the interview with Fran Allen. If you look up "women" in the index, you'll find about a dozen pages, all of them in Allen's interview. If gender equality is an important issue in computer science, Seibel should've treated it as such and asked more than just the one woman about it. If not, why is he wasting space on it? As it is, Seibel treats gender equality as an issue for women in engineering to solve, which is the worst possible attitude to have.
Overall, this is a fascinating book that any programmer will enjoy. Seibel does a nice job asking questions that are particular to each person, but also trying to get a variety of opinions on the same questions that face all programmers. (E.g., how do you debug? how do you read new code? how do you identify good programmers?)
The problem with the book is the interview with Fran Allen. If you look up "women" in the index, you'll find about a dozen pages, all of them in Allen's interview. If gender equality is an important issue in computer science, Seibel should've treated it as such and asked more than just the one woman about it. If not, why is he wasting space on it? As it is, Seibel treats gender equality as an issue for women in engineering to solve, which is the worst possible attitude to have.
March 26, 2012
Not quite what I expected. I was hoping for more information and less blathering--"I worked here, then here, and then I went back to that one place because they offered more vacation time. Then I quit again because I didn't like it anymore. Then I had a kid. Then I stopped programming."
I understand the desire to explore the interviewee's personal backgrounds, but isn't this book supposed to be about the practice of programming? I can't say I learned much from this book, and since the vast majority of the important stuff has been discussed at length elsewhere, I suggest reading something else, unless you're really interested in these programmers' curriculum vitae.
I understand the desire to explore the interviewee's personal backgrounds, but isn't this book supposed to be about the practice of programming? I can't say I learned much from this book, and since the vast majority of the important stuff has been discussed at length elsewhere, I suggest reading something else, unless you're really interested in these programmers' curriculum vitae.
October 13, 2021
I enjoyed this, but it's something you're only going to care about if you're a programmer by trade.
The book is a collect of interviews w/ a lot of programming luminaries, ranging from jwz to ken thompson (unix pioneer) to the person who wrote livejournal to the person who wrote the first "internet-message-processor" (IMP)-- essentially the world's first internet router.
a lot of the older folks recount starting off on punch card machines or time share PDPs.... it's interesting to get their thoughts on how things have changed. the interviewer asks similar questions to all of them but the questions are pretty good. mostly it confirms what i've always believed, which is that software developers are more like carpenters than engineers or scientists.
is programming a young person's game?
is provability a worthwhile pursuit?
does anybody not debug by inserting a ton of print statements?
yes, kinda and no
The book is a collect of interviews w/ a lot of programming luminaries, ranging from jwz to ken thompson (unix pioneer) to the person who wrote livejournal to the person who wrote the first "internet-message-processor" (IMP)-- essentially the world's first internet router.
a lot of the older folks recount starting off on punch card machines or time share PDPs.... it's interesting to get their thoughts on how things have changed. the interviewer asks similar questions to all of them but the questions are pretty good. mostly it confirms what i've always believed, which is that software developers are more like carpenters than engineers or scientists.
is programming a young person's game?
is provability a worthwhile pursuit?
does anybody not debug by inserting a ton of print statements?
yes, kinda and no
December 31, 2009
The best book that I read all year was also the best book I read all year.
-m
-m
March 19, 2019
Terrific account of programming adventures and convictions by some of the disciplines stars. My favorite chapters were on Jamie Zawinsky; Netscape, Brad Fitzpatrick; author of Memcached and now working on Go at Google, Douglas Crockford, Joe Armstrong, Simon Peyton Jones, and Peter Norvig. I found most of the other chapters fairly weak, hence the 3-star rating, despite the interviews with the ones named easily being 4-5 stars.
It's interesting how a few of them have somewhat quit the disciplines and now live far away from computers. I can see the appeal in that, but, I can't really see myself doing it long-term, which many of them have done. The amount of commonalities in what they've each discovered is great. They alll describe it in slightly different ways, however: solving the problem at the right level of abstraction, not using every feature under the sun, defining data structures before anything else, and encouraging that atmosphere where people have enough slack in their workday to experiment—but also enough direction to be successful and not screw around all day.
A phrase that Simon Peyton Jones used a lot I haven't been able to stop thinking about is: "[..] your code should obviously have no bugs rather than having no obvious bugs." I like that a lot. I can really appreciate that from all the code that's come back to bite me where I've said "this is solved now!", where, really, it's band-aid onto a ship rather than taking the ship back to the shipyard.
It's interesting how a few of them have somewhat quit the disciplines and now live far away from computers. I can see the appeal in that, but, I can't really see myself doing it long-term, which many of them have done. The amount of commonalities in what they've each discovered is great. They alll describe it in slightly different ways, however: solving the problem at the right level of abstraction, not using every feature under the sun, defining data structures before anything else, and encouraging that atmosphere where people have enough slack in their workday to experiment—but also enough direction to be successful and not screw around all day.
A phrase that Simon Peyton Jones used a lot I haven't been able to stop thinking about is: "[..] your code should obviously have no bugs rather than having no obvious bugs." I like that a lot. I can really appreciate that from all the code that's come back to bite me where I've said "this is solved now!", where, really, it's band-aid onto a ship rather than taking the ship back to the shipyard.
Read
November 8, 2018تاب «Coders at Work » نوشته پیتر سیبل در سال 2009 به چاپ رسیده و با وجودی که مدّت زیادی از انتشار آن نمیگذرد مورد استقبال زیادی از سوی طراحان نرمافزار و برنامهنویسان قرار گرفته است. پیتر سیبل، که نام کتابش را از کتابهای معروف و پیشین «Writers at Work » و «Founders at Work » اقتباس کرده، در این کتاب به مصاحبه با پانزده تن از برجستهترین و سرشناسترین برنامهنویسان و دانشمندان رایانه، با پیش زمینه تحصیلی و علاقهمندیهای متفاوت در این حوزه، پرداخته و خواننده را با ایدههای آنها درباره زندگی و برنامهنویسی آشنا ساخته است.
اغلب برنامهنویسان به تنهایی و یا در گروههای کوچک به فعالیت میپردازند و جالبترین بخش فعالیتی که انجام میدهند در مغز آنها اتفاق میافتد که به دور از چشم دیگران است. تنها پنجرهای که به کار برنامهنویسان وجود دارد، رفتار برنامههایی است که توسط آنها نوشته شده و بر روی رایانهها اجرا میشود. بنابراین، اغلب برنامهنویسان تنها خودشان، و احتمالاً چند همکار معدودشان، میدانند که چگونه برنامه نویسی میکنند و چگونه این کار را فرا گرفتهاند. پیتر سیبل به دلیل آن که خود با حرفه برنامهنویسی آشنایی کامل دارد، سعی نموده است تا با طرح پرسشهای جالب و تخصصی، این گوشههای پنهان را برای خواننده آشکار سازد. »
در این کتاب با 15 برنامه نویس خبره و دانشمندِ علوم کامپیوتر از قبیل Joshua Bloch، Peter Norvig، Donald Knuth، Ken Thomson، و Jamie Zawinski مصاحبه شده است. نویسنده ی این کتاب، Peter Seibel، این مصاحبه ها را انجام داده است تا با استفاده از این رویکرد، نکاتی در مورد پروژه های معروفی که توسط این افراد در حال اجرا می باشند، و نیز داستان های الهام بخشی که پشت این پروژه ها وجود دارند، را ارائه دهد. این نویسنده همچنین، نگاهی داشته است به عواملی که موجب معروف شدن این افراد شده اند، و طرز تفکر و اندیشه ی آنها را نیز واکاوی نموده است.
توصیه میکنم که این کتاب را مطالعه کنید. از آن جا که مطالب کتاب بر اساس گفتوگوهای خودمانی نویسنده با بزرگان برنامهنویسی انجام شده است، نکاتی را از آن خواهید آموخت که در هیچ کتاب و مرجعی پیدا نخواهید کرد.
November 2, 2015
I never read books on programming, or coding, or whatever. Maybe that's a personal flaw. It's been my job for my entire adult life, and a little bit before that. But I grabbed this book after seeing an image of the cover, and I ended up devouring it.
The book is a set of interviews with some of the supermen of programming. Sometimes very, very technical. Sometimes funny. Sometimes I felt like an idiot (these people are incredibly, incredibly good) but it also reminded me of the reasons I got into programming in the first place, as a kid, and later on, and it's good to know a lot of the modern developments in the industry that I hate, a lot of these old guys do too.
Don't go looking for this to be a practical how-to. I wouldn't suggest it to anyone who hasn't been programming for years already, but I did recommend it immediately to a couple of old friends. It's such a breath of fresh air compared to an endless parade of frameworks and Ruby and Patterns and whatever other vomit-inducing bullshit is the latest development fad. These guys were there, doing the heavy lifting, when computers filled entire rooms, all the way through to now where a sizeable chunk of the interviewees work at Google. It broadens your perspective, not only to see where we started, but some really interesting ways forward.
And yeah, some of these guys are legitimate fossils. Diff? Source control? Subroutines? It's still worth it.
The book is a set of interviews with some of the supermen of programming. Sometimes very, very technical. Sometimes funny. Sometimes I felt like an idiot (these people are incredibly, incredibly good) but it also reminded me of the reasons I got into programming in the first place, as a kid, and later on, and it's good to know a lot of the modern developments in the industry that I hate, a lot of these old guys do too.
Don't go looking for this to be a practical how-to. I wouldn't suggest it to anyone who hasn't been programming for years already, but I did recommend it immediately to a couple of old friends. It's such a breath of fresh air compared to an endless parade of frameworks and Ruby and Patterns and whatever other vomit-inducing bullshit is the latest development fad. These guys were there, doing the heavy lifting, when computers filled entire rooms, all the way through to now where a sizeable chunk of the interviewees work at Google. It broadens your perspective, not only to see where we started, but some really interesting ways forward.
And yeah, some of these guys are legitimate fossils. Diff? Source control? Subroutines? It's still worth it.
March 2, 2017
این کتاب مجموعه مصاحبه با ۱۵ نفر از توسعهدهندگان نامدار و باتجربه در حوزههای مختلف ساخت نرمافزار است. در هر مصاحبه افراد از نحوه نگاهشان به برنامهسازی و چگونگی برخورد با مسائل مختلف حوزه مهندسی نرمافزار صحبت میکنند. همچنین قسمت خوبی از مصاحبه ها مربوط به گذشته و زندگینامه این افراد از زبان خودشان است که آگاهی از آنها باعث افزایش تجربیات خواننده و درک بهتر مفاهیم و روند توسعه رشتهی برنامهسازی کامپیوتر میشود.
بسیاری از مسائلی که خودم به شکل روزمره با آنها دست و پنجه نرم میکنم در این کتاب و از زبان خبرگان این رشته بررسی شده است. بسیار کتاب آموزندهای برای من بود. خوانندنش را به افراد فعال در حوزه برنامهنویسی و مهندسی نرمافزار اکیدا توصیه میکنم.
با تشکر از آقای ابراهیم نقیب زاده مشایخ و انجمن انفورماتیک ایران که کتب با ارزشی را در این حوزه ترجمه کرده و میکنند.
بسیاری از مسائلی که خودم به شکل روزمره با آنها دست و پنجه نرم میکنم در این کتاب و از زبان خبرگان این رشته بررسی شده است. بسیار کتاب آموزندهای برای من بود. خوانندنش را به افراد فعال در حوزه برنامهنویسی و مهندسی نرمافزار اکیدا توصیه میکنم.
با تشکر از آقای ابراهیم نقیب زاده مشایخ و انجمن انفورماتیک ایران که کتب با ارزشی را در این حوزه ترجمه کرده و میکنند.
October 23, 2014
A fun read to hear the stories of famous programmers and to understand how they think about their specialties. It's inspiring to see that almost all of them come across as normal, humble people that are started like everyone else. Unfortunately, not all the interview questions brought out interesting responses: the questions that focused on the programmer's expertise and history were great; the canned/rigid questions like "how do you read code" or "do high level degrees matter" were less great, often resulting in "it depends" or vague answers.
Some fun quotes from the book:
Zawinski: Your competitor’s six-month 1.0 has crap code and they’re going to have to rewrite it in two years but, guess what: they can rewrite it because you don’t have a job anymore.
Zawinski: I find that getting something on the screen as soon as possible really helps focus the problem for me. It helps me decide what to work on next.
Fitzpatrick: In practice, nothing works. There are all these beautiful abstractions that are backed by shit. The implementation of libraries that look like they could be beautiful are shit.
Seibel: any piece of code contains bits of embedded knowledge—little bits of cruft that are hard-won functionality that you don’t think of when you say, “Oh, we can just rewrite this.”
Crockford: I haven’t figured out a sufficiently useful way of testing units of JavaScript yet.
Eich: While producing a lot of code is still important, what has interested me—and this is something that we talked about at Netscape when we talked about their track for principal engineer—is somebody who isn’t management but still has enough leadership or influence to cause other programmers to write code like they would write without them having to do it, because you don’t have enough hours in the day or fingers.
Bloch: when you choose a language, you’re choosing more than a set of technical trade-offs—you’re choosing a community. It’s like choosing a bar. Yes, you want to go to a bar that serves good drinks, but that’s not the most important thing. It’s who hangs out there and what they talk about. And that’s the way you choose computer languages. Over time the community builds up around the language—not only the people, but the software artifacts: tools, libraries, and so forth. That’s one of the reasons that sometimes languages that are, on paper, better than other languages don’t win—because they just haven’t built the right communities around themselves.
Bloch: Many customers won’t tell you a problem; they’ll tell you a solution.
Bloch: But the fundamental rule is, write the code that uses the API before you write the code that implements it.
Bloch: 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.
Armstrong: To me programming isn’t about typing code into a machine. Programming is about understanding.
Armstrong: the central core of functional programming is the idea of nonmutable state—that x isn’t the name of a location in memory; it’s a value.
Armstrong: Then there’s—I don’t know if I read it somewhere or if I invented it myself—Joe’s Law of Debugging, which is that all errors will be plus/minus three statements of the place you last changed the program.
Armstrong: The code shows me what it does. It doesn’t show me what it’s supposed to do. I think the code is the answer to a problem. If you don’t have the spec or you don’t have any documentation, you have to guess what the problem is from the answer. You might guess wrong. I want to be told what the problem is.
Armstrong: You were asking earlier what should one do to become a better programmer? Spend 20 percent of your time learning stuff—because it’s compounded.
Armstrong: I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions — all the data comes in its input arguments and everything goes out and leave no state behind — it’s incredibly reusable.
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.
Jones: when the limestone of imperative programming is worn away, the granite of functional programming will be observed.
Jones: One thing that is hard, even for professional software engineers and developers, is to viscerally grok the size of the artifacts on which we work. You’re looking at the Empire State Building through a 1-foot-square porthole, so it’s difficult to have a real feel for how gigantic the structure you’re looking at is. And how it’s interconnected.
Deutsch: Language systems stand on a tripod. There’s the language, there’s the libraries, and there are the tools. And how successful a language is depends on a complex interaction between those three things.
Allen: Part of it is that there’s the potential for new ideas every day. One sees something, and says, “Oh, that’s new.” The whole field 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.
Isaac Asimov made a statement about the future of computers—I don’t know whether it’s right or not—that what they’ll do is make every one of us much more creative. Computing would launch the age of creativity.
Knuth: I think that’s a fundamental error made by scientists in every field. They don’t realize that 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. That all goes into the brain and gets shoved down to the point where the older people forget that they needed it.
Knuth: I try to give the key ideas and I try to simplify them the best I can, but then what happens is every five pages of my book is somebody’s career.
Knuth: The first rule of writing is to understand your audience—the better you know your reader the better you can write, of course. The second rule, for technical writing, is say everything twice in complementary ways so that the person who’s reading it has a chance to put the ideas into his or her brain in ways that reinforce each other.
Knuth: Pretty much a constant in my experience, over a long period of years, is that every time I’m exposed to 100 people from some population or other, except majors in computer science, 2 of them are programmers in the sense that they really resonate with the machine.
Some fun quotes from the book:
Zawinski: Your competitor’s six-month 1.0 has crap code and they’re going to have to rewrite it in two years but, guess what: they can rewrite it because you don’t have a job anymore.
Zawinski: I find that getting something on the screen as soon as possible really helps focus the problem for me. It helps me decide what to work on next.
Fitzpatrick: In practice, nothing works. There are all these beautiful abstractions that are backed by shit. The implementation of libraries that look like they could be beautiful are shit.
Seibel: any piece of code contains bits of embedded knowledge—little bits of cruft that are hard-won functionality that you don’t think of when you say, “Oh, we can just rewrite this.”
Crockford: I haven’t figured out a sufficiently useful way of testing units of JavaScript yet.
Eich: While producing a lot of code is still important, what has interested me—and this is something that we talked about at Netscape when we talked about their track for principal engineer—is somebody who isn’t management but still has enough leadership or influence to cause other programmers to write code like they would write without them having to do it, because you don’t have enough hours in the day or fingers.
Bloch: when you choose a language, you’re choosing more than a set of technical trade-offs—you’re choosing a community. It’s like choosing a bar. Yes, you want to go to a bar that serves good drinks, but that’s not the most important thing. It’s who hangs out there and what they talk about. And that’s the way you choose computer languages. Over time the community builds up around the language—not only the people, but the software artifacts: tools, libraries, and so forth. That’s one of the reasons that sometimes languages that are, on paper, better than other languages don’t win—because they just haven’t built the right communities around themselves.
Bloch: Many customers won’t tell you a problem; they’ll tell you a solution.
Bloch: But the fundamental rule is, write the code that uses the API before you write the code that implements it.
Bloch: 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.
Armstrong: To me programming isn’t about typing code into a machine. Programming is about understanding.
Armstrong: the central core of functional programming is the idea of nonmutable state—that x isn’t the name of a location in memory; it’s a value.
Armstrong: Then there’s—I don’t know if I read it somewhere or if I invented it myself—Joe’s Law of Debugging, which is that all errors will be plus/minus three statements of the place you last changed the program.
Armstrong: The code shows me what it does. It doesn’t show me what it’s supposed to do. I think the code is the answer to a problem. If you don’t have the spec or you don’t have any documentation, you have to guess what the problem is from the answer. You might guess wrong. I want to be told what the problem is.
Armstrong: You were asking earlier what should one do to become a better programmer? Spend 20 percent of your time learning stuff—because it’s compounded.
Armstrong: I think the lack of reusability comes in object-oriented languages, not functional languages. Because the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle. If you have referentially transparent code, if you have pure functions — all the data comes in its input arguments and everything goes out and leave no state behind — it’s incredibly reusable.
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.
Jones: when the limestone of imperative programming is worn away, the granite of functional programming will be observed.
Jones: One thing that is hard, even for professional software engineers and developers, is to viscerally grok the size of the artifacts on which we work. You’re looking at the Empire State Building through a 1-foot-square porthole, so it’s difficult to have a real feel for how gigantic the structure you’re looking at is. And how it’s interconnected.
Deutsch: Language systems stand on a tripod. There’s the language, there’s the libraries, and there are the tools. And how successful a language is depends on a complex interaction between those three things.
Allen: Part of it is that there’s the potential for new ideas every day. One sees something, and says, “Oh, that’s new.” The whole field 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.
Isaac Asimov made a statement about the future of computers—I don’t know whether it’s right or not—that what they’ll do is make every one of us much more creative. Computing would launch the age of creativity.
Knuth: I think that’s a fundamental error made by scientists in every field. They don’t realize that 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. That all goes into the brain and gets shoved down to the point where the older people forget that they needed it.
Knuth: I try to give the key ideas and I try to simplify them the best I can, but then what happens is every five pages of my book is somebody’s career.
Knuth: The first rule of writing is to understand your audience—the better you know your reader the better you can write, of course. The second rule, for technical writing, is say everything twice in complementary ways so that the person who’s reading it has a chance to put the ideas into his or her brain in ways that reinforce each other.
Knuth: Pretty much a constant in my experience, over a long period of years, is that every time I’m exposed to 100 people from some population or other, except majors in computer science, 2 of them are programmers in the sense that they really resonate with the machine.
August 5, 2024
It’s a really interesting read that I’ve been going through over the years. For the most part, I forgot I was reading the book, only getting back to it in 2020. 😅
Peter Seibel does a great job of interviewing figures that have interesting things to say. I was lured into the book by Brad Fitzpatrick, Peter Norvig, and Donald Knuth’s chapters. I really enjoyed Jamie Zawinski’s. Here’s also one of the quotes that I still remember to this date, giving me focus on what to learn and improve. It’s Zawinski’s:
“Seibel: Do you find that programming and writing are similar intellectual exercises?
Zawinski: In some ways, yeah. Programming is obviously much more rigid. But as far as the
overall ability to express a thought, they’re very similar. Not rambling, having an idea in your
head of what you’re trying to say, and then being concise about it. I think that kind of thinking
is the overlap between programming and writing prose.”
In my opinion, writing prose is the cornerstone of writing. If you can write prose, at least in a way you can understand yourself, you'll be able to capture your day-to-day life and think in new ways. :))
Peter Seibel does a great job of interviewing figures that have interesting things to say. I was lured into the book by Brad Fitzpatrick, Peter Norvig, and Donald Knuth’s chapters. I really enjoyed Jamie Zawinski’s. Here’s also one of the quotes that I still remember to this date, giving me focus on what to learn and improve. It’s Zawinski’s:
“Seibel: Do you find that programming and writing are similar intellectual exercises?
Zawinski: In some ways, yeah. Programming is obviously much more rigid. But as far as the
overall ability to express a thought, they’re very similar. Not rambling, having an idea in your
head of what you’re trying to say, and then being concise about it. I think that kind of thinking
is the overlap between programming and writing prose.”
In my opinion, writing prose is the cornerstone of writing. If you can write prose, at least in a way you can understand yourself, you'll be able to capture your day-to-day life and think in new ways. :))
September 28, 2022
almost everybody emphasized the importance of writing readable code
Seibel: How did you learn to program?
Zawinski: eighth grade, I think. We had some TRS-80s and we got to goof around with BASIC a little bit.
Zawinski: I read a lot of science fiction. I thought AI was really neat
Zawinski: We were so focused on deadline it was like religion. We were shipping a finished product in six months or we were going to die trying.
Seibel: How did you come up with that deadline?
Zawinski: Well, we looked around at the rest of the world and decided, if we’re not done in six months, someone’s going to beat us to it so we’re going to be done in six months.
the way we divided up labor
we’d look at the list of features and I’d go, “Uhhh, maybe I’ll work on that,” and he’d go, “OK, I’ll work on that,” and then we’d go away.
Check-ins would happen and then we’d come back and he’d say, “Alright, I’m done with that, what are you doing?” “Uh, I’m working on this.” “OK, well, I’ll start on that then.”
I know I could do this by clicking on 30,000 web pages and doing it by hand, but why don’t I write this script—little timesaver things. I know to people who aren’t programmers, that seems like a black art.
I find that getting something on the screen as soon as possible really helps focus the problem for me.
instead of just displaying a tree structure, now maybe I should be emitting HTML or something along those lines. Or parsing the headers in a more detailed way.
Seibel: I’ve noticed that one thing that separates good programmers from bad programmers is that good programmers are more facile at jumping between layers of abstraction—they can keep the layers distinct while making changes and choose the right layer to make changes in.
I always find that a 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.
Zawinsky: What are the top-level entry points of this file, this module, whatever? With an object-y language, that’s done by the language for you. With C you’ve got to be a little more explicit about that.
Seibel: You put the leaves first in the file, but is that how you write? Do you build up from leaves?
Zawinski: If you don’t understand how something works, ask someone who does. Not knowing something doesn’t mean you’re dumb—it just means you don’t know it yet.
Seibel: Were you actually one of those kids who took toasters apart?
Zawinski: Yeah. I made a telephone and learned how to dial with a telegraph tapper that I made out of a tin can. Boy’s Own Science Book from the ’30s,
Zawinski: The one I always recommend is Structure and Interpretation of Computer Programs
Seibel: Is there a key skill programmers must have?
Zawinski: Well, curiosity—taking things apart. Wanting to know what’s going on under the hood.
Seibel: Have you read Knuth’s, The Art of Computer Programming?
Zawinski: “Oh, my program’s getting gigantic,” what are they going to do? Really that probably doesn’t even matter because you’ll just throw more memory at it and it’ll be fine.
Fitzpatrick: My mom says I was reading the Apple II programmers’ manual from the library at the same time as Clifford the Big Red Dog.
Fitzpatrick: Philadelphia? The cheesesteak place.
Fitzpatrick: He came in and took a piss in my hotel bathroom without even closing the door as I’m standing right there. I’m like, “Alright. You’re comfortable.” It was like we knew each other for four or five years, even though we had never met.
Once there were three of us, it was a little crowded in my house, so I was like, “Oh, OK, let’s get an office.”
my mom was fighting with me because she worked for me. I had to make rules for my mom, like, “If you call me, it has to be personal or business; whatever one you start with, that’s how you end it. You can’t switch from work to personal or personal to work.” I just started hanging up on her if she switched.
Fitzpatrick: There was a guy assigned to me at this ISP. I was having problems with my server dying all the time. I’m like, “I paid my $10.00 a month. Why isn’t it working?” So he would say, “Oh, do this.” Pretty soon I was learning Unix and learning what was actually going on.
Then I converted to FastGCI. Then I tuned Apache and turned off reverse DNS lookups. All these steps you go through. Finally, I was I/O-bound or CPU-bound. Then I got my own dedicated server.
then I put something up on the LiveJournal news page and I said, “Help. We need to buy servers.”
Then we had three web servers and one database server. At that point, I started playing with three or four HTTP load balancers—mod_backhand and mod_proxy and Squid and hated them all.
You just throw more of them and spread load.
Fitzpatrick: It’s one thing to go learn a language for fun, but until you write some big, complex system in it, you don’t really learn it.
Seibel: So what languages would you say you’ve really lived and breathed with enough to claim as your own?
Fitzpatrick: Perl. C. Back in the day, BASIC, but I’m not even sure BASIC counts. I wrote a lot of Logo too.
now at Google, in the last year, it’s a lot of C++, Python, and Java.
Seibel: From what I understand, Google has a C++-centric culture because that’s what they used originally and they’ve built a whole bunch of software infrastructure around it.
Fitzpatrick: It could be. Once, when I was 11 or 12, we were on a trip around the US and I wrote that game Mastermind on a TI-85 calculator. So I wrote the thing three times. But then it got so easy. That’s a good point—the second time around it was a lot easier.
Seibel: How low do you think programmers need to go—do programmers still need to know assembly and how chips work?
Fitzpatrick: I don’t know. I see people that are really smart—I would say they’re good programmers—but say they only know Java. The way they think about solving things is always within the space they know. They don’t think end-to-end as much. I think it’s really important to know the whole stack even if you don’t operate within the whole stack.
Someone described Google’s App Engine as this generation’s BASIC. Because this generation, everything is networked.
The fact that App Engine gives you one button, “Put this on the Web,” and you write in one language, arguably a pretty easy-to-learn one, Python, is perfect.
Fitzpatrick: Or I would make up my own terminology for it and people would think I didn’t know what I was talking about. Formal C.S. education helped me be able to talk about it.
Seibel: How do you design software?
Fitzpatrick: I start with interfaces between things. What are the common methods, or the common RPCs, or the common queries. If it’s storage, I try to think, what are the common queries? What indexes do we need? How are the data going to be laid out on disk? Then I write dummy mocks for different parts and flesh it out over time.
Seibel: Do you have any advice for self-taught programmers?
Fitzpatrick: Always try to do something a little harder, that’s outside your reach. Read code. I heard this a lot, but it didn’t really sink in until later. There were a number of years when I wrote a lot of code and never read anyone else’s.
I really enjoyed reading code, because whenever I didn’t understand some pattern, I was like, “Wait, why the fuck did they do it like this?” and I would look around more, and I’d be like, “Wow, that is a really clever way to do this. I see how that pays off.”
Fitzpatrick: Or if you really respect some programmer, go read some of their code. Maybe that’ll make you realize that they’re mortal and they’re not really someone you should be idolizing.
That’s always the best way to start a conversation. Even at Google, that’s the way I start a lot of conversations to a team I don’t know. When I fix a bug in their product the first thing I do is send them a patch in the mail and just say, “What do you guys think of this?”
Fitzpatrick: having worked at Google with really strict style guidelines in all languages. On our top six or seven languages, there’s a really strict style guide that says, “This is how we lay out our code. This is how we name variables. This is how we do spacing and indentation, and these patterns and conventions you use, and this is how you declare a static field.”
I definitely context-switch way too often and I’m spread too thin.
I had a friend, who had some iptables rule, that on connection to certain IP addresses between certain hours of the day would redirect to a “You should be working,” page. I haven’t got around to doing that, but I need to do something like it, probably.
To check in you need three conditions met: You need someone to review it and say it looks good. You need to be certified in the language—basically you’ve proven you know the style of this language—called “readability.” And then you also need the approval above from somebody in the owner’s file in that directory. So in the case that you already are an owner of that directory and you have readability in that language, you just need someone to say, “Yeah, it looks good.” And it’s a pretty good system, because there tends to be a minimum of two, up to twenty, thirty owners. Once you work on a code base for a while, someone just adds you to owners. I think it’s a great system.
Fitzpatrick: Nothing with Google is really a deadline. With Google it’s like, “What do you think about launching this? How does that feel?” It’s rare that there’s some real deadline. Most of them, we think it’d be nice to launch on this date and so everyone tries really hard. But you’re only letting down other people that want to see it launch by that day if you don’t finish something. And most of the things I work on are very “When it’s done, it’s done.”
Seibel: When you were hiring programmers at LiveJournal, did you manage them?
Fitzpatrick: Well, I kind of assumed that none of them would need managing; that they would just all be self-driven like me. That was a learning experience in HR, that some people just do what they’re told and don’t really have a passion for excellence.
Seibel: Do you have favorite interview questions?
Fitzpatrick: One of the ones I’ve given a few times because it was on my AP programming test is given two decimal numbers as a strings of arbitrary length, multiply them. There are a lot of different ways that they could do it. If they’re really good at math—like I’m not—they can find some clever ways to do it really efficiently. Worst case, they can make a class that does just addition repeatedly. I tell them from the beginning, “Don’t stress out. You don’t have to do it efficiently. Just get it done somehow.” Some people stress out and have no clue where to begin. That’s kind of a bad sign. The worst case, you just implement the algorithm you do in grade school.
Seibel: Or does that only work if you have some natural inclination that way?
Seibel: Google has a bit of a reputation, as Microsoft also does, of interviewers using puzzle questions.
Fitzpatrick: One question was, imagine you have a bunch of computers on a switch and they turn on the whole rack; come up with an algorithm so every machine on the rack knows the status of all the other ones about whether they’re on or off. So basically a presence thing. That was pretty much the constraint. Basically, they described Ethernet: you could send a broadcast to everyone, or you could send it to a specific MAC address. So I just kind of walked through all the different strategies to minimize bandwidth and to minimize latency discovering when something’s dead. That was a fun one.
Seibel: What are your debugging tools? Debuggers? Printlns? Something else?
Fitzpatrick: Println if I’m in an environment where I can do that. Debugger, if I’m in an environment that has good debuggers. GDB is really well maintained at Google
I might as well continue making it simpler for the next maintainer.
Fitzpatrick: MJD’s Higher-Order Perl. The book
Seibel: The Art of Computer Programming
Fitzpatrick: Having users is a key to getting contributors. More users find more bugs and find more use cases. It’s more fun to work with other people, especially on open source stuff.
When I see the number of web sites that use memcached or the load balancer or something, I’m like, “Ah, that’s cool.”
Seibel: What do you think is the most important skill for a programmer to have?
Fitzpatrick: Thinking like a scientist; changing one thing at a time.
Seibel: Is there anything that you did specifically to improve your skill as a programmer?
Fitzpatrick: Sometimes I’ll go out of my way to write something in a language that I would rather not write it in
Seibel: People have claimed that there are orders of magnitude differences in productivity between the best and worst programmers. Has that been your experience?
Fitzpatrick: Yeah
Fitzpatrick: I have this silly board game on my phone. I was kind of tired—I couldn’t work on anything serious, so I wrote a solver for that game. Tried to do some dynamic programming and did different board sizes and did a bunch of random boards and made a histogram of how many moves it takes to solve the board for different board sizes. I sent it to the author.
Douglas Crockford - He invented JSON. Published book, JavaScript: The Good Parts.
Crockford: 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. You have greater reeducation costs
JavaScript, purely by accident, has become the most popular programming language in the world
Crockford: I think that is the most useful thing that a community of programmers can do for each other—spend time on a regular basis reading each other’s code.
Crockford: At each meeting, someone’s responsible for reading their code, and they’ll walk us through everything, and the rest of us will observe. It’s a really good chance for the rest of the team to understand how their stuff is going to have to fit with that stuff.
Crockford: I think in terms of one letter. Also in JavaScript, there’s an indefensible efficiency argument that you’re actually paying for the download cost of those extra characters, and so you can make programs smaller by making your variable names smaller.
Some things, like my loop counters, will probably always be i.
I don’t use continue ever. If I see a continue in my code, then I assume I haven’t thought it through carefully.
A lot of programming is you keep stuff in your head until you can get it written down and structured properly.
Seibel: To what extent do you think having that kind of mathematical training is necessarily to be a programmer?
Crockford: If we were writing operating systems or writing runtimes, it’d be much more critical. But we’re doing form validations and UIs.
Seibel: Do you have any advice for self-taught programmers?
Crockford: Yeah, read a lot. There are good books out there. Find the good ones and read those. And if you’re doing web development, find the best sites and look at their code. Most web developers learned to do web development by doing “view source,”
I just want to know that you know how to put an algorithm together, you understand data structures, and you know how to document it.
Eich: Physics was also less satisfying to me because it has kind of stalled. There’s something not quite right when you have these big inductive theories where people are polishing corners and inventing stuff like dark energy, which is basically unfalsifiable. I was gravitating toward something that was more practical
Academia has not been helpful in leading people toward a better model. I think academia has been kind of derelict. Maybe it’s not their fault. The economics that they subsist on aren’t good.
you can learn a lot reading other people’s code. I did like Brian Kernighan’s books. And Knuth's Art of Computer Programming, Volumes 1–3
Seibel: So is that something you often do in interviews: get them to talk about their own projects?
Eich: I do.
Seibel: Is that even a good first-pass filter?
Eich: I’m skeptical. Google does that in spades, and they hire a bunch of very bright puzzle-solvers. But some of them, their street smarts are not necessarily there, and mature judgment. So I’m skeptical of it. I think we have to do it to some extent because you can end up getting someone who talks well, but actually isn’t effective at programming, and so you want to see them think on their feet, you want to see if they’ve solved a problem before. So we give them fairly practical problems. Not esoteric puzzles or math-y things, but more like programming problems.
affected by Pirsig’s Zen and the Art of Motorcycle Maintenance.
Seibel: Are there any books that every programmer should read?
Bloch: Design Patterns. Another is Elements of Style. Hacker’s Delight, by Hank Warren.
Knuth’s The Art of Computer Programming.
Frederick Brooks’s The Mythical Man Month.
The main message of the book is “adding people to a late software project makes it later,” and it’s still true.
Java Concurrency in Practice
you need to be able to name your identifiers well
There are oodles of aphorisms to this effect. My favorite is one that’s commonly misattributed to Thelonious Monk: “Simple ain’t easy.”
Seibel: As a Java guy at Google, do you think it could be used more? Leaving aside the force of history and historical choices, if somehow you could wave a magic wand and replace all of the C++ with Java, could that work?
Bloch: Up to a point.
what is C but glorified assembly language?
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.
I know other people who are stunningly good at extracting that last percentage of performance. You want to put them in a position where that’s what they’re doing. I think you’ve got to figure out what your engineers are good at and use them for that.
solving real problems for real users
you need three real uses before you put anything in. You don’t put anything in just because it’s neat.
Seibel: I was reading Java Puzzlers and Effective Java and it struck me that there are a lot of little weird corners for a language that started out so simple.
Seibel: How did you learn to program?
Zawinski: eighth grade, I think. We had some TRS-80s and we got to goof around with BASIC a little bit.
Zawinski: I read a lot of science fiction. I thought AI was really neat
Zawinski: We were so focused on deadline it was like religion. We were shipping a finished product in six months or we were going to die trying.
Seibel: How did you come up with that deadline?
Zawinski: Well, we looked around at the rest of the world and decided, if we’re not done in six months, someone’s going to beat us to it so we’re going to be done in six months.
the way we divided up labor
we’d look at the list of features and I’d go, “Uhhh, maybe I’ll work on that,” and he’d go, “OK, I’ll work on that,” and then we’d go away.
Check-ins would happen and then we’d come back and he’d say, “Alright, I’m done with that, what are you doing?” “Uh, I’m working on this.” “OK, well, I’ll start on that then.”
I know I could do this by clicking on 30,000 web pages and doing it by hand, but why don’t I write this script—little timesaver things. I know to people who aren’t programmers, that seems like a black art.
I find that getting something on the screen as soon as possible really helps focus the problem for me.
instead of just displaying a tree structure, now maybe I should be emitting HTML or something along those lines. Or parsing the headers in a more detailed way.
Seibel: I’ve noticed that one thing that separates good programmers from bad programmers is that good programmers are more facile at jumping between layers of abstraction—they can keep the layers distinct while making changes and choose the right layer to make changes in.
I always find that a 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.
Zawinsky: What are the top-level entry points of this file, this module, whatever? With an object-y language, that’s done by the language for you. With C you’ve got to be a little more explicit about that.
Seibel: You put the leaves first in the file, but is that how you write? Do you build up from leaves?
Zawinski: If you don’t understand how something works, ask someone who does. Not knowing something doesn’t mean you’re dumb—it just means you don’t know it yet.
Seibel: Were you actually one of those kids who took toasters apart?
Zawinski: Yeah. I made a telephone and learned how to dial with a telegraph tapper that I made out of a tin can. Boy’s Own Science Book from the ’30s,
Zawinski: The one I always recommend is Structure and Interpretation of Computer Programs
Seibel: Is there a key skill programmers must have?
Zawinski: Well, curiosity—taking things apart. Wanting to know what’s going on under the hood.
Seibel: Have you read Knuth’s, The Art of Computer Programming?
Zawinski: “Oh, my program’s getting gigantic,” what are they going to do? Really that probably doesn’t even matter because you’ll just throw more memory at it and it’ll be fine.
Fitzpatrick: My mom says I was reading the Apple II programmers’ manual from the library at the same time as Clifford the Big Red Dog.
Fitzpatrick: Philadelphia? The cheesesteak place.
Fitzpatrick: He came in and took a piss in my hotel bathroom without even closing the door as I’m standing right there. I’m like, “Alright. You’re comfortable.” It was like we knew each other for four or five years, even though we had never met.
Once there were three of us, it was a little crowded in my house, so I was like, “Oh, OK, let’s get an office.”
my mom was fighting with me because she worked for me. I had to make rules for my mom, like, “If you call me, it has to be personal or business; whatever one you start with, that’s how you end it. You can’t switch from work to personal or personal to work.” I just started hanging up on her if she switched.
Fitzpatrick: There was a guy assigned to me at this ISP. I was having problems with my server dying all the time. I’m like, “I paid my $10.00 a month. Why isn’t it working?” So he would say, “Oh, do this.” Pretty soon I was learning Unix and learning what was actually going on.
Then I converted to FastGCI. Then I tuned Apache and turned off reverse DNS lookups. All these steps you go through. Finally, I was I/O-bound or CPU-bound. Then I got my own dedicated server.
then I put something up on the LiveJournal news page and I said, “Help. We need to buy servers.”
Then we had three web servers and one database server. At that point, I started playing with three or four HTTP load balancers—mod_backhand and mod_proxy and Squid and hated them all.
You just throw more of them and spread load.
Fitzpatrick: It’s one thing to go learn a language for fun, but until you write some big, complex system in it, you don’t really learn it.
Seibel: So what languages would you say you’ve really lived and breathed with enough to claim as your own?
Fitzpatrick: Perl. C. Back in the day, BASIC, but I’m not even sure BASIC counts. I wrote a lot of Logo too.
now at Google, in the last year, it’s a lot of C++, Python, and Java.
Seibel: From what I understand, Google has a C++-centric culture because that’s what they used originally and they’ve built a whole bunch of software infrastructure around it.
Fitzpatrick: It could be. Once, when I was 11 or 12, we were on a trip around the US and I wrote that game Mastermind on a TI-85 calculator. So I wrote the thing three times. But then it got so easy. That’s a good point—the second time around it was a lot easier.
Seibel: How low do you think programmers need to go—do programmers still need to know assembly and how chips work?
Fitzpatrick: I don’t know. I see people that are really smart—I would say they’re good programmers—but say they only know Java. The way they think about solving things is always within the space they know. They don’t think end-to-end as much. I think it’s really important to know the whole stack even if you don’t operate within the whole stack.
Someone described Google’s App Engine as this generation’s BASIC. Because this generation, everything is networked.
The fact that App Engine gives you one button, “Put this on the Web,” and you write in one language, arguably a pretty easy-to-learn one, Python, is perfect.
Fitzpatrick: Or I would make up my own terminology for it and people would think I didn’t know what I was talking about. Formal C.S. education helped me be able to talk about it.
Seibel: How do you design software?
Fitzpatrick: I start with interfaces between things. What are the common methods, or the common RPCs, or the common queries. If it’s storage, I try to think, what are the common queries? What indexes do we need? How are the data going to be laid out on disk? Then I write dummy mocks for different parts and flesh it out over time.
Seibel: Do you have any advice for self-taught programmers?
Fitzpatrick: Always try to do something a little harder, that’s outside your reach. Read code. I heard this a lot, but it didn’t really sink in until later. There were a number of years when I wrote a lot of code and never read anyone else’s.
I really enjoyed reading code, because whenever I didn’t understand some pattern, I was like, “Wait, why the fuck did they do it like this?” and I would look around more, and I’d be like, “Wow, that is a really clever way to do this. I see how that pays off.”
Fitzpatrick: Or if you really respect some programmer, go read some of their code. Maybe that’ll make you realize that they’re mortal and they’re not really someone you should be idolizing.
That’s always the best way to start a conversation. Even at Google, that’s the way I start a lot of conversations to a team I don’t know. When I fix a bug in their product the first thing I do is send them a patch in the mail and just say, “What do you guys think of this?”
Fitzpatrick: having worked at Google with really strict style guidelines in all languages. On our top six or seven languages, there’s a really strict style guide that says, “This is how we lay out our code. This is how we name variables. This is how we do spacing and indentation, and these patterns and conventions you use, and this is how you declare a static field.”
I definitely context-switch way too often and I’m spread too thin.
I had a friend, who had some iptables rule, that on connection to certain IP addresses between certain hours of the day would redirect to a “You should be working,” page. I haven’t got around to doing that, but I need to do something like it, probably.
To check in you need three conditions met: You need someone to review it and say it looks good. You need to be certified in the language—basically you’ve proven you know the style of this language—called “readability.” And then you also need the approval above from somebody in the owner’s file in that directory. So in the case that you already are an owner of that directory and you have readability in that language, you just need someone to say, “Yeah, it looks good.” And it’s a pretty good system, because there tends to be a minimum of two, up to twenty, thirty owners. Once you work on a code base for a while, someone just adds you to owners. I think it’s a great system.
Fitzpatrick: Nothing with Google is really a deadline. With Google it’s like, “What do you think about launching this? How does that feel?” It’s rare that there’s some real deadline. Most of them, we think it’d be nice to launch on this date and so everyone tries really hard. But you’re only letting down other people that want to see it launch by that day if you don’t finish something. And most of the things I work on are very “When it’s done, it’s done.”
Seibel: When you were hiring programmers at LiveJournal, did you manage them?
Fitzpatrick: Well, I kind of assumed that none of them would need managing; that they would just all be self-driven like me. That was a learning experience in HR, that some people just do what they’re told and don’t really have a passion for excellence.
Seibel: Do you have favorite interview questions?
Fitzpatrick: One of the ones I’ve given a few times because it was on my AP programming test is given two decimal numbers as a strings of arbitrary length, multiply them. There are a lot of different ways that they could do it. If they’re really good at math—like I’m not—they can find some clever ways to do it really efficiently. Worst case, they can make a class that does just addition repeatedly. I tell them from the beginning, “Don’t stress out. You don’t have to do it efficiently. Just get it done somehow.” Some people stress out and have no clue where to begin. That’s kind of a bad sign. The worst case, you just implement the algorithm you do in grade school.
Seibel: Or does that only work if you have some natural inclination that way?
Seibel: Google has a bit of a reputation, as Microsoft also does, of interviewers using puzzle questions.
Fitzpatrick: One question was, imagine you have a bunch of computers on a switch and they turn on the whole rack; come up with an algorithm so every machine on the rack knows the status of all the other ones about whether they’re on or off. So basically a presence thing. That was pretty much the constraint. Basically, they described Ethernet: you could send a broadcast to everyone, or you could send it to a specific MAC address. So I just kind of walked through all the different strategies to minimize bandwidth and to minimize latency discovering when something’s dead. That was a fun one.
Seibel: What are your debugging tools? Debuggers? Printlns? Something else?
Fitzpatrick: Println if I’m in an environment where I can do that. Debugger, if I’m in an environment that has good debuggers. GDB is really well maintained at Google
I might as well continue making it simpler for the next maintainer.
Fitzpatrick: MJD’s Higher-Order Perl. The book
Seibel: The Art of Computer Programming
Fitzpatrick: Having users is a key to getting contributors. More users find more bugs and find more use cases. It’s more fun to work with other people, especially on open source stuff.
When I see the number of web sites that use memcached or the load balancer or something, I’m like, “Ah, that’s cool.”
Seibel: What do you think is the most important skill for a programmer to have?
Fitzpatrick: Thinking like a scientist; changing one thing at a time.
Seibel: Is there anything that you did specifically to improve your skill as a programmer?
Fitzpatrick: Sometimes I’ll go out of my way to write something in a language that I would rather not write it in
Seibel: People have claimed that there are orders of magnitude differences in productivity between the best and worst programmers. Has that been your experience?
Fitzpatrick: Yeah
Fitzpatrick: I have this silly board game on my phone. I was kind of tired—I couldn’t work on anything serious, so I wrote a solver for that game. Tried to do some dynamic programming and did different board sizes and did a bunch of random boards and made a histogram of how many moves it takes to solve the board for different board sizes. I sent it to the author.
Douglas Crockford - He invented JSON. Published book, JavaScript: The Good Parts.
Crockford: 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. You have greater reeducation costs
JavaScript, purely by accident, has become the most popular programming language in the world
Crockford: I think that is the most useful thing that a community of programmers can do for each other—spend time on a regular basis reading each other’s code.
Crockford: At each meeting, someone’s responsible for reading their code, and they’ll walk us through everything, and the rest of us will observe. It’s a really good chance for the rest of the team to understand how their stuff is going to have to fit with that stuff.
Crockford: I think in terms of one letter. Also in JavaScript, there’s an indefensible efficiency argument that you’re actually paying for the download cost of those extra characters, and so you can make programs smaller by making your variable names smaller.
Some things, like my loop counters, will probably always be i.
I don’t use continue ever. If I see a continue in my code, then I assume I haven’t thought it through carefully.
A lot of programming is you keep stuff in your head until you can get it written down and structured properly.
Seibel: To what extent do you think having that kind of mathematical training is necessarily to be a programmer?
Crockford: If we were writing operating systems or writing runtimes, it’d be much more critical. But we’re doing form validations and UIs.
Seibel: Do you have any advice for self-taught programmers?
Crockford: Yeah, read a lot. There are good books out there. Find the good ones and read those. And if you’re doing web development, find the best sites and look at their code. Most web developers learned to do web development by doing “view source,”
I just want to know that you know how to put an algorithm together, you understand data structures, and you know how to document it.
Eich: Physics was also less satisfying to me because it has kind of stalled. There’s something not quite right when you have these big inductive theories where people are polishing corners and inventing stuff like dark energy, which is basically unfalsifiable. I was gravitating toward something that was more practical
Academia has not been helpful in leading people toward a better model. I think academia has been kind of derelict. Maybe it’s not their fault. The economics that they subsist on aren’t good.
you can learn a lot reading other people’s code. I did like Brian Kernighan’s books. And Knuth's Art of Computer Programming, Volumes 1–3
Seibel: So is that something you often do in interviews: get them to talk about their own projects?
Eich: I do.
Seibel: Is that even a good first-pass filter?
Eich: I’m skeptical. Google does that in spades, and they hire a bunch of very bright puzzle-solvers. But some of them, their street smarts are not necessarily there, and mature judgment. So I’m skeptical of it. I think we have to do it to some extent because you can end up getting someone who talks well, but actually isn’t effective at programming, and so you want to see them think on their feet, you want to see if they’ve solved a problem before. So we give them fairly practical problems. Not esoteric puzzles or math-y things, but more like programming problems.
affected by Pirsig’s Zen and the Art of Motorcycle Maintenance.
Seibel: Are there any books that every programmer should read?
Bloch: Design Patterns. Another is Elements of Style. Hacker’s Delight, by Hank Warren.
Knuth’s The Art of Computer Programming.
Frederick Brooks’s The Mythical Man Month.
The main message of the book is “adding people to a late software project makes it later,” and it’s still true.
Java Concurrency in Practice
you need to be able to name your identifiers well
There are oodles of aphorisms to this effect. My favorite is one that’s commonly misattributed to Thelonious Monk: “Simple ain’t easy.”
Seibel: As a Java guy at Google, do you think it could be used more? Leaving aside the force of history and historical choices, if somehow you could wave a magic wand and replace all of the C++ with Java, could that work?
Bloch: Up to a point.
what is C but glorified assembly language?
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.
I know other people who are stunningly good at extracting that last percentage of performance. You want to put them in a position where that’s what they’re doing. I think you’ve got to figure out what your engineers are good at and use them for that.
solving real problems for real users
you need three real uses before you put anything in. You don’t put anything in just because it’s neat.
Seibel: I was reading Java Puzzlers and Effective Java and it struck me that there are a lot of little weird corners for a language that started out so simple.
on-hold
May 18, 2012Favorite quotes:
Zawinski: "It's great to rewrite your code and make it cleaner and by the third time it'll actually be pretty. But that's not the point--you're not here to write code; you're here to ship products."
Zawinski: "If you don't understand how something works, ask someone who does. A lot of people are skittish about that. And that doesn't help anybody. Not knowing something doesn't mean you're dumb--it just means you don't know it yet."
Crockford: "Readability of code is now my first priority. It's more important than being fast, almost as important as being correct, but I think being readable is actually the most likely way of making it correct."
Crockford: "Part of what makes programming difficult is most of the time we're doing stuff we've never done before. If it was stuff that had been done before we'd be reusing something else. For most of what we do, we're doing something that we haven't done before. And doing things that you haven't done before is hard. It's a lot of fun, but it's difficult."
Crockford: "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."
Eich: "It's going to take several tries to know what the hell you're doing. And then when you have a design moer firm you'll stick with it and you'll start patching it more, and you'll get to this mature state where we creak with patches. It's kind of an evolutionary dead-end for code."
Eich: "You don't want to write too many words, prose or code. In some ways the code should speak for itself at the small level. It's at the bigger level, the big monster function or the module boundary, that you need docs."
Bloch: "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 interchangeable, 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."
Bloch: "There's this problem, which is, programming is so much of an intellectual meritocracy and often these people are the smartest people in the organization; therefore they figure they should be allowed to make all the decisions. But merely the fact that they're the smartest people in the organization doesn't mean they should be making all the decisions, because intelligence is not a scalar quantity; it's a vector quantity. And if you lack empathy or emotional intelligence, then you shouldn't be designing APIs or GUIs or languages."
Armstrong: "Most of software development goes on in your head anyway."
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....I can't say beginner programmers should open up all these abstractions. But what I am saying is you should certainly consider the possibility of opening them. Not completely reject the idea. It's worthwhile seeing if the direct route is quicker than the packaged route."
Armstrong: "And what I've learned is, programming when you're tired, you write crap and you throw it all away the next day."
Armstrong: "The really good programmers spend a lot of time programming."
Peyton Jones: "I think my default is not to write something very general to begin with. So I try to make my programs as beautiful as I can but not necessarily as general as I can. There's a difference. I try to write code that will do the task at hand in a way that's as clear and perspicuous as I can make it."
Peyton Jones: "Programming is such fun. Why would you ever want not to do it?"
Peyton Jones: "That's the worst thing about long-lived programs...that they gradually become ugly."
Zawinski: "It's great to rewrite your code and make it cleaner and by the third time it'll actually be pretty. But that's not the point--you're not here to write code; you're here to ship products."
Zawinski: "If you don't understand how something works, ask someone who does. A lot of people are skittish about that. And that doesn't help anybody. Not knowing something doesn't mean you're dumb--it just means you don't know it yet."
Crockford: "Readability of code is now my first priority. It's more important than being fast, almost as important as being correct, but I think being readable is actually the most likely way of making it correct."
Crockford: "Part of what makes programming difficult is most of the time we're doing stuff we've never done before. If it was stuff that had been done before we'd be reusing something else. For most of what we do, we're doing something that we haven't done before. And doing things that you haven't done before is hard. It's a lot of fun, but it's difficult."
Crockford: "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."
Eich: "It's going to take several tries to know what the hell you're doing. And then when you have a design moer firm you'll stick with it and you'll start patching it more, and you'll get to this mature state where we creak with patches. It's kind of an evolutionary dead-end for code."
Eich: "You don't want to write too many words, prose or code. In some ways the code should speak for itself at the small level. It's at the bigger level, the big monster function or the module boundary, that you need docs."
Bloch: "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 interchangeable, 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."
Bloch: "There's this problem, which is, programming is so much of an intellectual meritocracy and often these people are the smartest people in the organization; therefore they figure they should be allowed to make all the decisions. But merely the fact that they're the smartest people in the organization doesn't mean they should be making all the decisions, because intelligence is not a scalar quantity; it's a vector quantity. And if you lack empathy or emotional intelligence, then you shouldn't be designing APIs or GUIs or languages."
Armstrong: "Most of software development goes on in your head anyway."
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....I can't say beginner programmers should open up all these abstractions. But what I am saying is you should certainly consider the possibility of opening them. Not completely reject the idea. It's worthwhile seeing if the direct route is quicker than the packaged route."
Armstrong: "And what I've learned is, programming when you're tired, you write crap and you throw it all away the next day."
Armstrong: "The really good programmers spend a lot of time programming."
Peyton Jones: "I think my default is not to write something very general to begin with. So I try to make my programs as beautiful as I can but not necessarily as general as I can. There's a difference. I try to write code that will do the task at hand in a way that's as clear and perspicuous as I can make it."
Peyton Jones: "Programming is such fun. Why would you ever want not to do it?"
Peyton Jones: "That's the worst thing about long-lived programs...that they gradually become ugly."
July 14, 2018
I am pretty glad I ended up reading this book.
This book is structured as a set of interviews of veteran software developers; some well known: like Don Knuth, Brendan Eich, Ken Thompson and Peter Norvig, while others I had never heard of. The interview asked a similar set of questions to all the people covered in the book, that covered topics such as: their workflow, their thought process while planning system design, philosophical takes on problem solving, and programming as a profession over the years, and some free-form meandering.
The breadth of folks covered was pretty valuable. Almost each of the interviewees had something unique to offer in terms of sharing their experience or offering up an insight about their work that they had learned over multiple decades in the profession.
This book is structured as a set of interviews of veteran software developers; some well known: like Don Knuth, Brendan Eich, Ken Thompson and Peter Norvig, while others I had never heard of. The interview asked a similar set of questions to all the people covered in the book, that covered topics such as: their workflow, their thought process while planning system design, philosophical takes on problem solving, and programming as a profession over the years, and some free-form meandering.
The breadth of folks covered was pretty valuable. Almost each of the interviewees had something unique to offer in terms of sharing their experience or offering up an insight about their work that they had learned over multiple decades in the profession.
October 17, 2009
Coders at work transcribes 16 some odd interviews of both new and old school programming giants culminating with Donald Knuth. For me it was the right book at the right time. After a year of studying algorithms, languages, and hardware, it was good to hear the voices of experience detailing the struggles of their day-to-days. In some cases their lessons reassured me that I hadn't missed some magic programming spells, in others I felt grossly outmatched by their experience and casual referencing of computers, languages, and tools that were totally unknown to me. Besides the well-appreciated name drops, the central message of this book was really quite simple: To be a good programmer, program and if you come across a good program read its code. Makes sense in retrospect.
September 15, 2016
Coders at Work is not a technical book: any computing aficionado with curiosity towards computing history will enjoy it and programmers can learn a lot from the first hand experiences of computing legends.
This is the second time I have read it from cover to cover but I also pick on some interviews from time to time. The fact that Seibel is a class 1 programmer himself makes the interviews quite enjoyable.
This is the second time I have read it from cover to cover but I also pick on some interviews from time to time. The fact that Seibel is a class 1 programmer himself makes the interviews quite enjoyable.
August 16, 2015
I loved it. It's light to read, it contains interviews with some of the best programmers/computer scientists/hackers, giving their opinion on many cool topics, usually differing between themselves. It also presents with a good overview of the history of CS.
January 20, 2021
I loved it!
September 13, 2023
Probably the definitive work of contemporary oral history in computer science. Seibel is a computer scientist himself, and is familiar with his interviewees work. As a result, he asks good, incisive questions. Better yet, he remembers the answers previous interviewees gave, and brings them up when interviewing the next CS luminary. So, while the book is inherently episodic, a sequence of interviews with different participants, there are strong threads running throughout it.
Perhaps the strongest of these threads is Donald Knuth. He is everpresent in the book, mentioned in each interview, usually praised and sometimes criticized (literate programming gets mixed reviews). So when the last interview rolls around, and it's with Knuth himself, it's a dramatic climax.
Anyone interested in academic computer science, software engineering practice at large corporations and startups, or anything in between, will find wisdom in this book. I can't recommend it too highly.
Perhaps the strongest of these threads is Donald Knuth. He is everpresent in the book, mentioned in each interview, usually praised and sometimes criticized (literate programming gets mixed reviews). So when the last interview rolls around, and it's with Knuth himself, it's a dramatic climax.
Anyone interested in academic computer science, software engineering practice at large corporations and startups, or anything in between, will find wisdom in this book. I can't recommend it too highly.
February 11, 2023
An interesting look at how many high-profile programmers and computer scientists learned, honed, and practiced their craft. This can sometimes drag a bit, particularly since some of the subjects are talking about workflows and tools very far removed from most modern programmers. That said, Peter Siebel is a very skilled interviewer, and there's a much more intimate look at how people think and work than is available in many coding books.
August 23, 2020
Great motivation and inspiration.
Interesting to learn from the great. This is a great book to pick up and read in short bursts. The book is packed with wisdom.
Interesting to learn from the great. This is a great book to pick up and read in short bursts. The book is packed with wisdom.
Read
April 17, 2024this needs sooo much editing omg. typos on every page
April 14, 2022
I really enjoyed this. It was just the right time for me, as I've just starting a computer science degree. I found learning the devs lives revealing and the ability to hear from the masters of the field, some of whom are now passed away, was great!
However, this is very technical and not really a book for people without experience in computer science. Much of what was covered, I didn't understand at first. Then, later, when covering it in a computer science lesson, it sunk in!
Typical of interview books, there are some repetitive questions, some of which are not particularly interesting. For example, whether they see themselves as "engineers, computer scientists..." who cares, really? I mean... But, luckily, there weren't many useless repetitive questions and Siebel did an excellent job adapting to the interviewer and with his extensive range of knowledge, had no problem keeping up with anything these master threw at him.
This is a book I'll likely re-read later on, when I have more knowledge, and will learn more for doing so.
Key Points
However, this is very technical and not really a book for people without experience in computer science. Much of what was covered, I didn't understand at first. Then, later, when covering it in a computer science lesson, it sunk in!
Typical of interview books, there are some repetitive questions, some of which are not particularly interesting. For example, whether they see themselves as "engineers, computer scientists..." who cares, really? I mean... But, luckily, there weren't many useless repetitive questions and Siebel did an excellent job adapting to the interviewer and with his extensive range of knowledge, had no problem keeping up with anything these master threw at him.
This is a book I'll likely re-read later on, when I have more knowledge, and will learn more for doing so.
Key Points
August 28, 2014
This was an awesome read. It contains 15 interviews with programmers of well-known skill, giving their opinion on history, current state and future, sharing their valuable and now unobtainable experience programming with wires, switches and punch cards, and explaining what programming means to them personally. There is a lot of diversity here, spanning the whole theoretical/practical spectrum and including some who left the field for other work (running a bar, composing music).
The historical views offered are quite valuable. Many of the speakers have strong negative opinions about technologies that are quite standard now: C/C++, object oriented programming, even API's; this was a valuable exercise in re-examining the basics. The speakers show that sometimes technology has regressed, and they wish they could have back some of the methods used in the 60's and 70's.
It's funny to see that if Perl is mentioned, they either hate it or love it. Java gets mostly negative comments, though a number of the authors work in it regularly. Python is mostly positive, I think. The one that stands out is Haskell, which, of those who mention it, mostly adore it (one speaker is cautious, saying that it is not a cure-all, though still an improvement).
They share war stories about tracing down bugs; what they think makes a great programmer and how they interview; how they work and how they dive into a new code base; what they think of Knuth, his books, and literate programming; how they started programming and what original sources or texts they recommend to budding programmers; artist, scientist, craftsman or writer; and plenty more.
The bibliography is nice, but I can't help but think that many sources are mentioned by the speakers but not provided there. Also, the text does not contain references to the bibliography, which makes it harder to use. Actually, what I really want is an index. Hundreds of topics must be covered, and the speakers kind of blur together in my mind. Without an index, there's no way for me to really go back and review specific points. I just have to read it again (though that might not be
so bad).
All of the chapters are good, but my favorites are Guy Steele and Bernie Cosell. Guy Steele sort of mesmerizes with his imagination of what might be possible in a programming language. Bernie Cosell is extremely pragmatic about code maintenance, and is known for being a master debugger. However, he believes that this reputation is slightly misplaced:
"I had two convictions, which actually served me well: that
programs ought to make sense and there are very, very few inherently hard problems. Anything that looks really hard or tricky is probably more the product of the programmer not fully understanding what they needed to do and pounding it with a hammer ’til they got code that looked like it did the right thing."
So when there is a bug to be found, he looks at it, finds it too convoluted to understand, and just rewrites it simply the way he understands that it should be done. Then the bug is gone, and he is hailed as the bug squasher.
He also explains how when he worked for the government and could never get budget approvals for updating designs, he would just update the software design as part of a bug fix, moving the design closer to what was needed. Siebel asks: "have you heard of refactoring?" "No, what is that?" "What you just described." These old-timers really know what they're talking about, even if they haven't kept up with all of the "recent" terminology!
The Knuth chapter also contains the best explanation and motivation of literate programming I've ever read; it really made it click, being at the end of a book containing differing opinions and opines of software writing practices. Knuth also explains that TeX is only Turing-complete because the users required it and he had to force in the additional features "kicking and screaming." He seems generally annoyed that so many things end up being Turing complete.
The historical views offered are quite valuable. Many of the speakers have strong negative opinions about technologies that are quite standard now: C/C++, object oriented programming, even API's; this was a valuable exercise in re-examining the basics. The speakers show that sometimes technology has regressed, and they wish they could have back some of the methods used in the 60's and 70's.
It's funny to see that if Perl is mentioned, they either hate it or love it. Java gets mostly negative comments, though a number of the authors work in it regularly. Python is mostly positive, I think. The one that stands out is Haskell, which, of those who mention it, mostly adore it (one speaker is cautious, saying that it is not a cure-all, though still an improvement).
They share war stories about tracing down bugs; what they think makes a great programmer and how they interview; how they work and how they dive into a new code base; what they think of Knuth, his books, and literate programming; how they started programming and what original sources or texts they recommend to budding programmers; artist, scientist, craftsman or writer; and plenty more.
The bibliography is nice, but I can't help but think that many sources are mentioned by the speakers but not provided there. Also, the text does not contain references to the bibliography, which makes it harder to use. Actually, what I really want is an index. Hundreds of topics must be covered, and the speakers kind of blur together in my mind. Without an index, there's no way for me to really go back and review specific points. I just have to read it again (though that might not be
so bad).
All of the chapters are good, but my favorites are Guy Steele and Bernie Cosell. Guy Steele sort of mesmerizes with his imagination of what might be possible in a programming language. Bernie Cosell is extremely pragmatic about code maintenance, and is known for being a master debugger. However, he believes that this reputation is slightly misplaced:
"I had two convictions, which actually served me well: that
programs ought to make sense and there are very, very few inherently hard problems. Anything that looks really hard or tricky is probably more the product of the programmer not fully understanding what they needed to do and pounding it with a hammer ’til they got code that looked like it did the right thing."
So when there is a bug to be found, he looks at it, finds it too convoluted to understand, and just rewrites it simply the way he understands that it should be done. Then the bug is gone, and he is hailed as the bug squasher.
He also explains how when he worked for the government and could never get budget approvals for updating designs, he would just update the software design as part of a bug fix, moving the design closer to what was needed. Siebel asks: "have you heard of refactoring?" "No, what is that?" "What you just described." These old-timers really know what they're talking about, even if they haven't kept up with all of the "recent" terminology!
The Knuth chapter also contains the best explanation and motivation of literate programming I've ever read; it really made it click, being at the end of a book containing differing opinions and opines of software writing practices. Knuth also explains that TeX is only Turing-complete because the users required it and he had to force in the additional features "kicking and screaming." He seems generally annoyed that so many things end up being Turing complete.
March 10, 2017
This is probably the best non-technical book on software I have every read, the interviews are amazing - mostly because the people interviewed are total rockstars. The book provides a great indirect overview of industry as a whole. For me personally, working mostly on the web it's too easy to lose sight of the big picture, how huge the world of software really is, how different the challenges are, and how prominent and brilliant are the industry leaders. Highly recommend this one.
November 12, 2009
If you are thinking about being a programmer, pick any interview from this book and read it. If, after reading it, you aren't excited about programming, then just stop. This is the best book I've ever read that gets inside the mind of a great programmer. True greats, the pioneers of computer science and industry achievement.
I learned things about programming, such as the usefulness of monads and closures, that had been previously under appreciated. I found the interviewees to be extremely candid, with profound answers to such questions as "do you think programming is a young person's game" (with a variety of answers) and "do you think of yourself as a craftsman, engineer, scientist or artist?"
A few attitudes shared by most if not all interviewed:
-C++ is not a good choice of language
-There is no silver bullet for debugging or reading code written by others
-Using puzzles in technical interviews is not the best way to determine who to hire
-Don Knuth's "The Art of Computer Science" is tough to get through (even for Don himself!)
-Get something easy working first before you optimize it
I really enjoyed reading Doug Crockford (of Atari, Lucasfilm, Yahoo and JSON fame) talk about JavaScript. I enjoyed hearing Dan Ingalls (implementer of several versions of Smalltalk) talk about teaching a new programmer by tapping into their inner passions, vs. teaching programming for its own sake. I particularly enjoyed reading the Guy Steele interview. Guy, co-creator of Common Lisp and Scheme, talks about magic and programming (pp360-361):
"I think it's not an accident that we often use the imagery of magic to describe programming. We speak of computing wizards and we think of things happening by magic or automagically. And I think that's because being able to get a machine to do what you want is the closest thing we've got in technology to adolescent wish-fulfillment."
Reading this book helped to recreate the magic of programming for me. I would recommend it to any programmer, old or new. You don't have to read it all straight through either... feel free to pick and choose, without fear of losing context.
I learned things about programming, such as the usefulness of monads and closures, that had been previously under appreciated. I found the interviewees to be extremely candid, with profound answers to such questions as "do you think programming is a young person's game" (with a variety of answers) and "do you think of yourself as a craftsman, engineer, scientist or artist?"
A few attitudes shared by most if not all interviewed:
-C++ is not a good choice of language
-There is no silver bullet for debugging or reading code written by others
-Using puzzles in technical interviews is not the best way to determine who to hire
-Don Knuth's "The Art of Computer Science" is tough to get through (even for Don himself!)
-Get something easy working first before you optimize it
I really enjoyed reading Doug Crockford (of Atari, Lucasfilm, Yahoo and JSON fame) talk about JavaScript. I enjoyed hearing Dan Ingalls (implementer of several versions of Smalltalk) talk about teaching a new programmer by tapping into their inner passions, vs. teaching programming for its own sake. I particularly enjoyed reading the Guy Steele interview. Guy, co-creator of Common Lisp and Scheme, talks about magic and programming (pp360-361):
"I think it's not an accident that we often use the imagery of magic to describe programming. We speak of computing wizards and we think of things happening by magic or automagically. And I think that's because being able to get a machine to do what you want is the closest thing we've got in technology to adolescent wish-fulfillment."
Reading this book helped to recreate the magic of programming for me. I would recommend it to any programmer, old or new. You don't have to read it all straight through either... feel free to pick and choose, without fear of losing context.
April 19, 2011
A great collection of interviews with fifteen different programmers, conducted by a programmer.
It's been a long time since I've read a technical book that really resonated with me, but this is one of them. I picked up this book on the recommendation of a programmer who included it in a small collection of great books about programming that included 'The C Programming Language' and 'Programming Pearls' -- two of my favorites. I wasn't disappointed.
The collection of programmers here includes a number of grand masters, including Donald Knuth, Ken Thompson, Jamie Zawinski, Peter Norvig, Guy Steele and Douglas Crockford. While there is a vast array of opinions here, a few common themes emerge:
1) All of them have something to hate about every programming language commonly in use. Some of them have particular favorites, but everyone hates C++ (as opposed to C).
2) Most of these folks will debug using print statements, rather than source level debuggers. Increasingly so as web applications make debugging more complicated.
3) Not a lot of love for integrated programming environments (such as Eclipse or Visual Studio)
4) Many of the older programmers express alarm at the increasing reliance on libraries or packages ("black boxes"), understanding the need for them, but disliking the increasing knowledge gap that has resulted.
The programmer I felt the most affinity for was Ken Thompson, who has long been a hero of mine. I found his willingness to rewrite (an abhorrence for some programmers, who wish to create eternal art) refreshing.
I loved Zawinski's paean to the lowly screensaver.
It's been a long time since I've read a technical book that really resonated with me, but this is one of them. I picked up this book on the recommendation of a programmer who included it in a small collection of great books about programming that included 'The C Programming Language' and 'Programming Pearls' -- two of my favorites. I wasn't disappointed.
The collection of programmers here includes a number of grand masters, including Donald Knuth, Ken Thompson, Jamie Zawinski, Peter Norvig, Guy Steele and Douglas Crockford. While there is a vast array of opinions here, a few common themes emerge:
1) All of them have something to hate about every programming language commonly in use. Some of them have particular favorites, but everyone hates C++ (as opposed to C).
2) Most of these folks will debug using print statements, rather than source level debuggers. Increasingly so as web applications make debugging more complicated.
3) Not a lot of love for integrated programming environments (such as Eclipse or Visual Studio)
4) Many of the older programmers express alarm at the increasing reliance on libraries or packages ("black boxes"), understanding the need for them, but disliking the increasing knowledge gap that has resulted.
The programmer I felt the most affinity for was Ken Thompson, who has long been a hero of mine. I found his willingness to rewrite (an abhorrence for some programmers, who wish to create eternal art) refreshing.
I loved Zawinski's paean to the lowly screensaver.
Displaying 1 - 30 of 283 reviews