Coders At Work, written by Peter Seibel and published on September 16th 2009, is a collection of interviews with some of the most predominant programmers of this generation. The conversations are lengthy and deep in any subject, including debugging and testing, all rotating around the craft of programming. The book would make a good podcast series or audiobook, but I prefer reading.
HOW THIS BOOK HELPED US?
Coders at work increased our tech literacy. The book provides information that opens up new opportunities in our careers. Also, the book helped us become problem solvers. Coders at work provided insight that helped us understand how to address issues and use tools around us to develop supreme solutions.
THE BOOK EXPLAINED UNDER 60 SECONDS
The book comprises interviews with some highly accomplished programmers. The principal parts of these interviews include how the interviewees got into programming, their favourite programming languages and first programs, opinions on the current programming trends and their career information.
TOP THREE QUOTES
- “Readability of code is now my priority. It’s more important than being fast, almost as important as being correct. Still, being readable is the most likely way of making it correct.”
- “He came in and took a piss in my hotel bathroom without even closing the door as I was standing right there. I’m like, “Alright. You’re comfortable.” We knew each other for four or five years, even though we had never met.”
- “But I think if a program is well written, there will be something about its structure that will guide me to various parts of it in an order that will make some kind of sense.”
BOOK SUMMARIES AND NOTES
Chapter one: Jamie Zawinski
Nightclub owner, Lisp hacker and early Netscape developer Jamie Zawinski are a member of a group of hackers known by their three-letter initials as full names. In 1998, he remarkably contributed to the development of mozilla.org and XEmacs. When asked how he learnt how to program, in his own words, Zawinski replied that the first time he used a computer in coding circumstances was in the eighth grade. There was no approach for saving programs, so we’d type them in from magazines. Also, I read a lot of books, I guess, about various languages to the extent that I had no way to write programs for languages that I’d only studied. Working at Lucid, a company that implements Lisp software and creates a development environment, assisted in making Zawinski a better programmer. He argues developers to be aware of the second system syndrome. It had never been a perfect idea for him to redesign a system. Zawinski advises young programmers to start small and focus more on the process than the results. That was the same way Fitzpatrick began LiveJournal.
Favourite quote of the chapter: “Sometimes. I end up doing all the sysadmin crap, which I can’t stand-I’ve never liked it. I enjoyed working on XScreenSaver because, in some ways, screen savers-the actual display modes rather than the XScreenSaver framework-are the perfect program because they almost always start from scratch, and they do something pretty, and there’s never a version 2.0. There is very rarely a bug in a screen saver. It crashes-oh, there’s a divide-by-zero, and you fix that.”
Chapter two: Brad Fitzpatrick
Brad Fitzpatrick is the youngest among the interviewees and the only person. He can’t live without the internet or personal computers. After watching his father build an Apple II from scratch, Brad became a programmer, playing with the hardware parts and reading books. Like Zawinski, Brad also started with BASIC. He couldn’t do anything with a mouse or higher graphics modes and colours. It was until one of Brad’s family friends introduced him to C and gave him Turbo C. Brad also messed around with assembly programming on calculators such as Z80 on the IT calculator. Brad’s interest in Perl started when he engaged with CGIs and printed one or two lines to the Netscape Navigator browser. Brad did not attend any classes on programming. It was all about one or two books from the library. His college was a combination of running and LiveJournal, making school bearable.
Favourite quote of the chapter: “Back when I was doing Perl-even for people that knew Perl really well-I’d recommend MJD’s Higher-Order Per! The book is entertaining in that it starts somewhat simple, and you’re like, yeah, yeah, I know what a closure is. And then it just continues to fuck with your head. By the end of the book, you’re just blown away.”
Chapter three: Douglas Crockford
Douglas Crockford was one-time a senior javascript architect at Yahoo. Previously, he worked for Lucasfilm, Atari and Electric Communities. Crockford went to San Francisco University and attended a Fortran class in the math department, where he learnt programming. Crockford argues that with the improvements in CPU and memory or hardware in general, developers don’t care anymore about efficiency as they did in the past. According to the interviewee, part of what makes programming hard is that most of the time, programmers are doing things they were not doing before. He discusses his favourite approach to interviewing job candidates. He summons the candidate to carry a piece of code he made and walk us through it. Crockford also thinks the only way to improve Javascript would be to make it smaller if we could remove all the features that don’t value it and maintain only what matters. He says this approach can be used in HTML, HTTP and CSS. Developers should figure out what the languages do best and focus on that rather than piling in new updates. When asked for advice for an upcoming programmer, Crockford replied that they should focus more on communication. They should learn how to read and write.
Favourite quote of the chapter: “For the most part, we’ve done pretty good. I think the world is a better place, although it’s not always moving forward. Looking at international policies over the last ten years, the consolidation of big media and the corrupting of effects that have not been compensated for by the open network. That’s a big disappointment. Hundreds of thousands of people have died as a direct consequence of that.”
Chapter four: Brendan Eich
Brendan Eich, CTO of the Mozilla Corporation, a subsidiary of the Mozilla Foundation, is responsible for the continuous development of the Firefox browser and creator of Javascript, the most utilised programming language on the web. Brendan was a physics major at Santa Clara, where he learnt how to program. Brendan says he was interested in Unix and C, but they were only getting started with the old DEC iron. He had a Portable C Compiler and was beginning to create code and mess around with Unix utility porting. From Brendan’s observation, more people wrote code with more high-level abstractions than before. If you run applications spread on servers worldwide, the old approach won’t work. Brendan also discusses how he worked on Kernel and networking code at SCI. The size of the language background he used grew over time because he wrote his network management and packet-sniffing layer. In addition to reading code, Eich also reads books about programming. He says he loved Brian Kernighan’s books and considered them neat. Eich also loved Knuth’s Art of Computer Programming volumes 1- 3.
Favourite quote of the chapter: “[Assenbly level programming] kind of still separates the chest hair—gender-independent—programmers from those who don’t quite have it.”
Chapter five: Joshua Bloch
Joshua Bloch is the current Chief Java architect at Google and a former engineer at Sun Microsystems. He ushered the design and implementation of the Java Collections Framework initiated in Java 2. Joshua learnt to program, especially Fortran, from his father while studying a programming course around 1971. In 1977, Joshua wrote a version of the twenty questions games known as “Animals”. This was the first exciting program he wrote. Joshua emphasises that developers should read books often, like Design Patterns with a common vocabulary, good ideas and a mish-mash of styles and languages. Another book is Elements of Style, this is not a programming book, but you should read it for two reasons. First, it improves your prose style; secondly, all the book concepts apply to programs. Joshua argues that the necessity for math is much more considerable in a community that writes compilers, libraries and frameworks. When you write web applications on top of frameworks, you must understand visual and verbal communication. In Joshua’s opinion, smart programmers usually write the worst code. Intelligent programmers can fit the whole thing in their heads and understand it. And because they can understand, they think it’s suitable for utilisation.
Favourite quote from the chapter: “We’re all optimists in our profession, or we would be forced to shoot ourselves.”
Chapter six: Joe Armstrong
Joe is the creator of Erlang and the Open Telecom Platform, a framework for building Erlang applications. Joe was studying physics, and as an undergraduate, some courses involved creating programs, and he loved it. He got very good at debugging, and the standard pay for debugging was one beer at that moment in time. Joe usually spends a lot of time thinking before getting into coding. However, during this period, he also makes notes. According to Joe Armstrong, current widgets don’t make you more productive. Take a look at Hierarchical file systems. How do they level your productivity? They don’t because almost the entire software development happens in your head. Working with an effortless system inflicts a certain disciplined way of thinking. You’ll require discipline if you don’t have a directory system and have to put all the files in a single directory. If you can apply the same field to what you’re doing, there won’t be a need for Hierarchical file systems. Hierarchical file systems, ten to one, make it effortless for groups to work in conjunction. Armstrong thinks what makes a good programmer is their choice of problems. Are they driven by the solutions or by the answers? Also, he advises young programmers to try and learn various languages as it improves their skills, flexibility and knowledge about other languages.
Favourite quote of the chapter: “I think the lack of reusability comes in object-oriented languages, not in 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 got a gorilla holding the banana and the entire jungle.”
Chapter seven: Simon Peyton Jones
In 1987, he was one of the architects of a project that led the way to resolving the programming language Haskell. Simon Peyton is the Principal Researcher at the Microsoft Research lab in Cambridge. When asked about the correlation between programming and research, Simon replied that those aspects extensively interact. Programming languages make programming effortless. They act as the user interface of programming. Therefore, programming language research and programming are immeasurably related. Simon discussed the testing of APIs at Microsoft. They do great work on testing APIs. Given a new API, Steven Clarke and his team endeavoured to observe programmers talk about what they were attempting to do. And get people who created the API to watch from a glass screen. Peyton enjoys programming when he tries to write a program with intellectual integrity. He adds you can go on slapping mud on the side of a program, and it will work for quite some time but won’t be satisfying. Therefore, one of the good attributes of a good programmer is they should always try to generate moving solutions even when in technical situations.
Favourite quote of the chapter: “Sometimes, to say that it’s obviously right doesn’t mean that you can see that it’s right without any mental scaffolding. It may be that you need to be told an insight to figure out why it’s right.”
Chapter eight: Peter Norvig
Peter Norvig is an inclusive thinker and hacker at heart. One time he designed a program to detect a series of three searches by the same user in Google’s search logs. Peter learnt to program in high school, the school had a Ph.D.-8, and he took a class that started with BASIC programming. Peter’s first interesting code he wrote was the Game of Life. He says it was a class exercise that he quickly did. Peter worked for a software company in Cambridge. Their product was a software-design toolset and various kinds of software consulting. One of the projects at the company was to create a flowchart drawer that’d analyse your program and generate a flowchart for it. Peter emphasised developers to have other skills besides writing code. Skills such as comprehending the customers’ needs, communication, and problem-solving. According to Peter, programming has become more of a social activity than it used to be. Computers back then used to be more segregated, and it was more of batch processing, so the interface was a bit simpler. Peter Norvig does not welcome Google’s approach of asking puzzle questions in interviews. He prefers interviewees to be put in a technical situation to just chitchatting to get you a feeling that them being the right guy.
Favourite quote of the chapter: “I think one of the most important things is being able to keep everything in your head at once. You have a much better chance of success if you can do that. That makes a small program easier. For a more extensive program, you need extra tools to be able to handle that.”
Chapter nine: Guy Steele
When asked what languages Guy has used, Guy Steele, proper programming polyglot, was actually programming polyglot. He generated this list: Fortran, COBOL, IBM, PDP-10 machine language, APL, C, C++, BLISS, Haskell, FOCAL, TEGO and TeX. “Those are the main ones, I guess,” he added. Guy got into programming through a friend from school who got Guy fascinated with a few lines of the Fortran program. After studying Fortran, Guy went ahead and learnt IBM 1130 assembly language. His first exciting program would create keyword-in-context indexes. And IBM offered quick indexes for their manuals that, when given a keyboard, you’d look it up in the indexes. It was alphabetised based on the keyboard, but on both sides of the keyboard, you would see different words of the context surrounding that word. Steele dealt with various machines on campuslike the DEC PDP-10. At that time, Harvard owned a PDP-10 for graduate work. The undergraduates only used the teletype terminals for a commercial system the school leased. Steele also stated some of the essential books he read that levelled his programming skills, including Knuth and The Art of Computer Programming. Also, Guy Steele argues young programmers do not utilise their thumbs when trying to count. On the other hand, there has been substantial progress from the struggle with the incompatibility of base-ten with two powers.
Favourite quote of the chapter: “So I guess there are lessons there—the lesson I should have drawn is there may be more than one bug here, and I should have looked harder the first time. But another lesson is that if a bug is thought to be rare, then looking at rarely executed paths may be fruitful. And the third thing is, having good documentation about what the algorithm is trying to do, namely a reference back to Knuth, was just incredible.”
Chapter ten: Dan Ingalls
Dan Ingalls, one of the co-founders of Smalltalk. He began the first enactment of Smalltalk, written in BASIC. He took part in implementing seven generations of Smalltalk, from the prototype to the current open source implemental, Squeak. Dan grew up as an inventor, and he majored in physics at college. He did a programming course in Fortran at Harvard. Ingalls started a program he after did a business. Its purpose was to evaluate programs and observe their dynamic behaviour, in simple terms, profiling. There was a program that would guzzle up a Fortran program and place counters at every branch point. Dan created a better version of the program that had a timer-interrupt process so it would track how much real-time was spent on different parts of the program. Dan still enjoys programming as he used to when he was beginning. He says the last two years have been interesting since he moved from a familiar environment—Smalltalk to Squeak—where the tools were great. Dan advises junior developers to learn various languages with different strengths. He adds that it’s worth it for developers to take several different computing environments and find a problem to solve.
Favourite quote of the chapter: “Different people have different levels that they need to go to feel good about what they’re working with. So I think somebody can be entirely confident maybe using a collections library without having programmed it themselves.”
HOW THIS BOOK CAN HELP SOFTWARE DEVELOPERS
“Coders at Work” is a collection of interviews conducted by Peter Seibel with some of the most successful and experienced programmers of our time. These coders share their insights, experiences, and wisdom about software development in the book. Reading this book can help software developers better understand the industry, learn from the experiences of successful programmers, and develop their skills and perspectives. The book can inspire developers to think creatively and challenge themselves to become better coders.
