Steve Yegge
Steve Yegge is a programmer and blogger who is known for writing about programming languages, productivity and software culture
16 recommendations

Recommendations by Steve Yegge

The C Programming Language
book
by Brian W. Kernighan, Dennis M. Ritchie

Steve Yegge's Review:

This is an odd little book. It's frequently mistaken for an introductory programming book, which inevitably leads to frustration. It's not a good way to learn how to program; it expects that you're already familiar with machine architecture, assembly language, compilers, and at least one other high-level language.

It's not even a very good way to learn C. The idioms and best-practices for C programming have evolved substantially, even since the second edition was published, and some of the code samples look a bit dated.

However, with all that said, it's still an amazing little book. The C language is a remarkably elegant balancing act between efficiency and expressiveness. By today's standards, perhaps, it doesn't seem very feature-rich, and many people feel that programming in C can be tedious. Perhaps so. It depends, I think, on the size of the system you're trying to build, and on your overall familiarity with the language and tools.

C isn't really suitable for building huge systems, but it was never intended to be. C was created for making Unix, and Unix isn't a large system; it's a large collection of small systems that work together cleanly and effectively (for the most part).

C is an elegant language, and is in my opinion quite a breath of fresh air if you've been working in C++ for very long. People who try use C++ to build giant, hairy systems often wind up being giant, hairy programmers as a result. If you're trying to build a large system in C, you'll inevitably wind up making a choice between two alternatives:

 

  1. Use the AlternateHardAndSoftLayers design pattern, in which you write most of your code in a high-level language, and the performance-critical parts in optimized C.

  2. Try to make C a high-level language itself, which either leads to the madness of choosing C++, or the madness of implementing your own high-level language in C, without any actual syntactic support.

 

Most companies choose the second option, usually because they haven't learned the hard way that 90% of your code never needs to be optimized, and doing so won't produce any human-observable difference in runtime performance.

Java is essentially a pre-packaged, turnkey solution for option #1; hence it has all the pros and cons of a turnkey solution. It's easier -- you only have to learn one language, and you can avoid most of the low-level programming and porting issues. The downside is that you're not using a true high-level language, and it's not as easy to optimize the performance-critical parts. But on the whole, it's better than trying option #2.

When it comes right down to it, though, C is a beautiful little language. Many (most?) computer games these days use the AlternateHardAndSoftLayers pattern; the game engine is written in C, and the games themselves are written in higher-level languages. And the game industry is one of the most obsessively performance-focused software industries out there, so that's pretty strong evidence in favor of that pattern.

I guess what I'm trying to say is that writing in C is a pleasure, as long as you don't try anything too ambitious by yourself. And the K&R book may just be the best way to see this. It's certainly a great way to come back to the language after you've been a way for a while.

Summary: after a long hard day of C++ programming, it's nice to revisit something simple and elegant.

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Compilers: Principles, Techniques, and Tools (2nd Edition)
book
by Alfred V. Aho, Monica S. Lam, Ravi Sethi, Jeffrey D. Ullman

Steve Yegge's Review:

This is the (in)famous "Dragon Book", and it's by far the hardest book in the list so far, even more so than The Algorithm Design Manual, in no small part because it's extremely dense. That, or I'm extremely dense. Or both.

However, all the other compilers books I've tried out have been unsatisfactory. We used this one in school, and I pretty much hated it. Every few years I'd pull it out and try to puzzle through it, and it would put me right to sleep. Wonderful soporific, for those of you with occasional bouts of insomnia. The authors have evidently released a new version in C (the old one was in Ada), and maybe it's gotten better, but I haven't looked at it.

After several years of fighting with the Fisher and LeBlanc book, I finally bought myself a copy of the Dragon Book. I'd heard the most awful horror stories about it, so you can imagine this was an act of sheer desperation. And much to my surprise, I found it to be a wonderful book.

I can appreciate the arguments to the effect that it's not a good text for undergraduate students. But that's clearly not the intent of the book. The book was obviously written for the educated researcher or working professional who wants to write a compiler, and doesn't want to mess around. It covers virtually all of the issues known to compiler writers at the time it was published, except for some of the fancier optimization techniques. I have no doubt that Richard Stallman possesses a dog-eared copy, and so do the teams that have built virtually all production-quality compilers in the past 20 years.

I'm going to argue in a yet-to-be-published essay that Compilers and Operating Systems are the most important courses in an undergraduate CS degree, and that both of them should be required for graduation. Unfortunately I don't know of any CS degrees that require them both; usually they let you get by with one or the other (or neither).

Suffice it to say for now that a working knowledge of compiler construction is the thing that differentiates good programmers from average ones, and expertise with compilers is something you find in all great programmers. Even if you never plan on writing or working on a compiler yourself, it's still the most important CS subject, and it's a damned shame that most schools don't tell you how and why it's so important.

There are other books on compilers, and you'll probably need to struggle with many of them before it all starts to really come together. Compilers are among the most complex programs a person can write, and it's taken fifty years for the world to figure out as much as we know about them -- which isn't enough by a long shot, but the situation is improving.

But I think once you've really started to master the subject, the Dragon Book is the one you'll keep coming back to. So it makes the list.

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Steve Yegge's Review:

Our first O'Reilly title in the list! It has an owl on the front; owls are known for their, uh, regular, erm, never mind. It's not always clear how O'Reilly picks their colophons.

This is a great book for exactly, precisely the reason that all O'Reilly books are great: it covers complex material in a way that's accessible to uncomplex people. Ever notice that "O'Reilly" sounds just like "for Dummies" underwater? And quite frankly, I'm the proud owner of several "for Dummies" books (publisher: IDG, which I believe stands for "IDiot's Guide"); they're very similar to O'Reilly books in their general approach and target audience. It might sound like I'm bashing on for-Dummies books, but quite the contrary -- I hate badly-written, pretentious books that don't talk to me like a person. I've often wished that O'Reilly would publish a Computer Science series.

Anyway, regular expressions are a mini-language for generating and matching regular languages, a concept introduced by the famous linguist Noam Chomsky. A "mini-language" is a special-purpose language with its own jargon and structure. A famous example is StarbucksSpeak, a Turing-complete coffee-ordering mini-language with a rich, free-form syntax and domain-specific jargon, allowing well-formed expressions such as: "Grande quad-shot no-room light-foam half-caf half-decaf half-lowfat half-nonfat 190-degree sugar-free vanilla medium-roast half-white chocolate half-regular chocolate Mocha Valencia with 1 pump sugar-free hazelnut and a sprig of nutmeg. Oh, and make that iced."

As one Starbucks employee put it: "More words means more money." I believe the drink above costs over seventeen dollars. You need to learn the idioms and efficiency considerations for each minilanguage to help optimize its performance.

Other widespread minilanguages include: Pizza-Ordering Language (which has many dialects but is more or less universal), Swearing Like A Drunken Sailor (which is useful when you receive the bill for your car repairs, written in the Auto Repair Theft mini-language), and of course Pig Latin, which is helpful for talking about slower co-workers ("ob-Bay's ot-nay oo-tay ight-bray, is he?"). Mini-languages are everywhere, and can be quite fun.

Regular expressions are no exception. They let you parse a log file faster than you can say: "does Python's case-insensitivity metacharacter span the entire expression, or is that just in Perl?" Like the syntax for printf's format string, regexps are a tool that will be useful in almost any language you use.

Strongly recommended. Oh, and make mine iced.

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

The Little Schemer, Fourth Edition
book
by Daniel P. Friedman, Matthias Felleisen

Steve Yegge's Review:

This is without question one of the weirdest technical books you'll ever encounter. But don't be put off by the format. Well, you WILL be put off by it, but try not to be dogmatic about it.

This book makes my top-10 list because it helped me understand recursion and think recursively better than any other approach. Scheme is a fine language for doing this, although they could probably have just as easily done the book in Haskell or Ruby. It doesn't matter, though -- the concepts transcend the language.

A lot of people simply avoid recursion because they've heard it doesn't perform very well. They don't practice it, so when they run into situations where recursion is the most natural approach, they have a LOT of trouble with it.

Recursion is the most natural way to express many algorithms, including tree and graph traversals, linear and dynamic programming, parsing of computer languages and natural languages, and plenty of others. If you aren't comfortable thinking recursively, you'll tend to steer clear of recursive solutions, which means that for many problems you'll wind up with code that's a lot uglier and error-prone than it should have been.

The Little Schemer is not a book that you can sit down and read like a novel, or even like a J2EE technical manual. You have to work through all of the examples yourself, by hand, in order, and you can't skip any of them.

The painful way (IMO) is to use a Scheme interpreter; I found it easier to translate the examples into Emacs-Lisp and run them in lisp-interaction-mode. There are only a few simple rules to remember. Or perhaps you can find a Scheme plug-in for your favorite editor. However you decide to do it, you need to do it -- you have to solve the problems yourself.

They recommend that you don't try doing the book all in one sitting; it has about 10 chapters, and I was doing about 2 a day, so I got through it in about a week (about an hour a day).

About halfway through, you really start getting the hang of it, and by then they're mostly teaching you common idioms for recursion. If you really do the examples, it gradually becomes fairly trivial to express things as singly- or doubly-recursive functions.

I haven't made it through the Seasoned Schemer yet -- that'll undoubtedly be in my "Ten Wishes" blog entry about books that I want to read. But I'm looking forward to it.

Summary: wonderful book. Definitely deserves a spot in my Top 10 list.

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Design Patterns: Elements of Reusable Object-Oriented Software
book
by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Steve Yegge's Review:

This book was incredible. When it came out in early 1995, it offered a set of 23 little reprieves from the blind, crawling, Lovecraftian madness of C++ programming. (Ever notice how "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn" and "Protected abstract virtual typedef'd copy constructor function" sound identical underwater? Yup. The Elder Gods are lumbering and gibbering around Redmond right now.)

Well, it was 22 reprieves, really, since the Interpreter pattern was put in there as sort of an in-joke. 1994, the year the book was being prepared, was in fact the 40th anniversary of John Backus's 1954 observation that most programmers detested the idea of a "compiler":

At that time, most programmers wrote symbolic machine instructions exclusively (some even used absolute octal or decimal machine instructions). Almost to a man, they firmly believed that any mechanical coding method would fail to apply that versatile ingenuity which each programmer felt he possessed and constantly needed in his work. Therefore, it was agreed, compilers could only turn out code which would be intolerably less efficient than human coding..."   [John Backus in the 1954 Fortran report]

 

So true! Compilers are for sissies. Just ask anyone from Geoworks, if you can find anyone left now that they've gone out of business. We all wrote everything in assembly language; it's obvious that computer time is more expensive than programmer time, and good programmers can hand-generate code that outperforms anything any compiler can generate. If-statements and for-loops were for pansies. We had "jcxz" and that was enough.

Most of the programming world who believed that you should write everything in assembly language have moved on (that's a euphemism for "died".) Their children and grandchildren today (that's you!) realize that, well, compilers are pretty important. We'll begrudge them their place. But programmers today firmly believe that any Interpreted coding method such as Java or Ruby fails to apply that versatile ingenuity which each programmer feels he/she possesses and constantly needs in his/her work, etc.

The authors of Design Patterns thought this was pretty funny. The machines change; the languages change, but people don't change. So they threw in the Interpreter pattern as a sort of practical joke, a gag that no real programmers with hairs on their chests would actually understand, let alone agree with.

Other than that, the book was great!

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Steve Yegge's Review:

This is one of my favorite books on programming, although I burned through it in about 3 or 4 hours, and didn't learn a huge amount from it. The point is that it was fun to read, it made a lot of sense, and it was helpful in reinforcing the habits I knew were good ones.

The primary focus of the book is on how to be an effective and efficient programmer, and how to have fun practicing your craft. So, for instance, they'll recommend that you learn how to touch-type with all ten of your fingers. And that you choose a powerful extensible editor and learn how to write extensions for it. And that you use a programming language that supports metaprogramming, so you can code your way out of holes without using hundreds of thousands of lines of code.

Sounds a bit like some of my blogs, doesn't it?

Honestly, though, I worry that the book is somewhat futile. It may be one of those books that you either understand and agree with already, or you never will.

I've sent out suggestions on mailing lists that were more or less directly out of the book, and received responses from so-called engineers who proudly claim, pecking their response out with their index fingers, that they've "gotten by" for 4 years without ever writing a script. Then they mail the same list asking if anyone knows of a refactoring tool that will do a global name-change inside comment headers. Or they'll refuse to listen when the entire community tells them that an identifer name needs to be changed, because it's now "used in too many places". (Yes, I kept those emails; they're in my "broken SDEs" folder.)

Or during a discussion about metaprogramming and code-squishing techniques, someone will just snap, and start ranting about how any OOP book will tell you that EJB is the only thing you need to know.

I'm going to put the book on my Top 10 list in the hopes that there are some programmers out there who haven't yet realized the merits of practicing at being more efficient, and who aren't so set in their ways that the mere thought of learning something new sends them off the deep end into a spittle-emitting rage. It really is a good book, and a fast read. And everything it really does matter, so pay the most attention to the parts that seem to matter the least. Those are the ones you should work on.

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Refactoring: Improving the Design of Existing Code 1st Edition
book
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

Steve Yegge's Review:

When I read this book for the first time, in October 2003, I felt this horrid cold feeling, the way you might feel if you just realized you've been coming to work for 5 years with your pants down around your ankles. I asked around casually the next day: "Yeah, uh, you've read that, um, Refactoring book, of course, right? Ha, ha, I only ask because I read it a very long time ago, not just now, of course." Only 1 person of 20 I surveyed had read it. Thank goodness all of us had our pants down, not just me.

This is a wonderful book about how to write good code, and there aren't many books like it. None, maybe. They don't typically teach you how to write good code in school, and you may never learn on the job. It may take years, but you may still be missing some key ideas. I certainly was.

The book talks about production code at the level of individual functions, and even snippets of code within a function. It starts by showing you ugly functions that work, then shows you, step by step, how to make them clean and beautiful without breaking them. Some of the techniques are quite powerful, and many can be automated. The book simultaneously showed me why some of my functions had grown large and gnarled, despite my best efforts, and then gave me tools and confidence for fixing it.

The book's examples are in Java, but don't let that put you off. The ideas are relevant for every programming language. I know a guy who read through it without knowing any Java, and immediately began putting the ideas to work in refactoring his Perl code. I even factor and refactor my Lisp code these days.

If you're a relatively experienced engineer, you'll recognize 80% or more of the techniques in the book as things you've already figured out and started doing out of habit. But it gives them all names and discusses their pros and cons objectively, which I found very useful. And it debunked two or three practices that I had cherished since my earliest days as a programmer. Don't comment your code? Local variables are the root of all evil? Is this guy a madman? Read it and decide for yourself!

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Steve Yegge's Review:

 I read a neat book called Predictably Irrational: The Hidden Forces That Shape Our Decisions, by Dan Ariely. The book is a fascinating glimpse into several bizarre and unfortunate bugs in our mental software. These bugs cause us to behave in weird but highly predictable ways in a bunch of everyday situations.

For instance, one chapter explains why bringing an uglier version of yourself to a party is guaranteed to get you more attention than other people who are arguably better-looking than you are. I personally do this all the time, except that I'm usually the ugly one. The same principle explains a ploy used by real-estate agents to get you to buy ugly houses.

Another chapter explains the bug that causes you to be a packrat, and shows why you desperately hold on to things you own, even if you know deep down that they would rate lower than pocket lint on eBay.

In any case, well, good book. I'm going to harsh on it a teeny bit here, but it's only one tiny part towards the end, one that actually has little to do with the rest of the research presented in the book. I still highly recommend it. It's only about a 4- or 5-hour read: beyond the reach of most social-network commenters, perhaps, but you can probably handle it just fine.

So: about that harshing. Dan Ariely, who seems like a pretty fascinating guy in his own right, independent of his nifty book, says something that's kinda naïve towards the end. It doesn't seem naïve at all when you first read it. But naïve it is.

Towards the end of the book — and I apologize here, since my copy is on loan to a friend at the moment, and you can't search inside the book on Amazon.com no-thanks to the book's publisher, so I can't double check the exact details — but towards the end, Dan works himself into a minor frenzy over what seems like a neat idea about credit cards.

Ref: http://steve-yegge.blogspot.in/search?q=book

The Algorithm Design Manual
book
by Steven S Skiena

Steve Yegge's Review:

This book came highly recommended from a friend of mine who reads a lot (great programmer, too) -- in fact, the same person who was the only one (out of 20) who had read Refactoring, back when I was polling people about it in October of last year.

I've read through most of the book, although I'm not certain I've read all of it, because it's more like an encyclopedia than a continuous narrative. It took me a while to appreciate how useful it is, in part because I wasn't really grokking its organization, which is part narrative, part cookbook, and part bibliography.

But it works! It provides fairly comprehensive coverage of the most common data structures and algorithms, but with a focus on teaching you how to model problems and select the right algorithm. It's filled with "War Stories" and real-life examples.

Most of the examples are wgah'nagl and take several pages of explanation, often with detailed diagrams. If you work through them carefully, you'll gain real familiarity with some useful techniques for solving NP-complete problems. And I have to confess that I didn't fully appreciate how widespread graphing problems are, and how many things can be modeled (and solved) with graph algorithms, until I read this book.

I've read a ton of data-structures and algorithms books, and I've never found one like this one. Its unconventional approach is refreshing and keeps you interested. I find myself coming back to it frequently, and always learning something new.

Summary: this one's a keeper.

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Steve Yegge's Review:

Excellent book on concurrency. Doug Lea wisely steers clear of Quantum Chu Spaces and even basic arithmetic, preferring to focus on "sound engineering principles" that can help your multi-threaded programs run for as long as possible without context-switching. Haha, just kidding. It helps them run as long as possible with context-switching. Jest seein' if yer awake.

Doug really does a wonderful job, at least the second time around; the first edition read like it was by Ph.D's forPh.D's, which means it was primarily targeted at ineffectual companies like Google.[1] But the second edition is far more manly, hence the cover-art color-scheme switch from cold Vulcan blood-green to manly human blood-red. Really.

The nice thing about this book is that as long as you're using a von Neumann computer, you're going to have to worry about how to fake parallelism on a sequential device, and that's nontrivial. ("Nontrivial" is a computer science term that sounds just like "wgah'nagl" underwater. 'Nuff said.) So even though the subtitle of this book is "in Java", the principles apply to just about any programming language, including Hasturese. Strongly recommended.

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Operating Systems

This is just a plug, from me, for you to know about processes, threads and concurrency issues. A lot of interviewers ask about that stuff, and it's pretty fundamental, so you should know it. Know about locks and mutexes and semaphores and monitors and how they work. Know about deadlock and livelock and how to avoid them. Know what resources a processes needs, and a thread needs, and how context switching works, and how it's initiated by the operating system and underlying hardware. Know a little about scheduling. The world is rapidly moving towards multi-core, and you'll be a dinosaur in a real hurry if you don't understand the fundamentals of "modern" (which is to say, "kinda broken") concurrency constructs.

The best, most practical book I've ever personally read on the subject is Doug Lea'sConcurrent Programming in Java. It got me the most bang per page. There are obviously lots of other books on concurrency. I'd avoid the academic ones and focus on the practical stuff, since it's most likely to get asked in interviews.

Ref: http://steve-yegge.blogspot.in/search?q=book

Steve Yegge's Review:

OK, but what about Firefox? Why don't they, you know, innovate? Well, they're trying, I think, but for what I'm guessing are probably tangled historical reasons — which manifest as the developers often being gridlocked politically — Mozilla lacks what Fred Brooks Jr. calls "conceptual integrity" in his classic "The Mythical Man-Month". [Which, incidentally, remains today the most vitally relevant book on software engineering, over 30 years after it was written.] The Mozilla folks would have to do a lotof serious re-thinking in order to reduce XUL's "Hello, World" down to a few lines of code in a single language. And I'm not convinced that kind of thinking is happening in the Firefox camp right now. It's not that they're not thinking at all; don't get me wrong. They're just not thinking about radical, revolutionary user-level simplifications to the basic framework.

Ref: http://steve-yegge.blogspot.in/search?q=book

Ajax: The Definitive Guide
book
by Anthony T. Holdener III

Steve Yegge's Review:

Hang on — you're not still a thick-client programmer, are you? Oh dear. You'd better get yourself a DHTML book and an AJAX book, and right-quick. Oh, you're above that client stuff, you're a server-side programmer then, are you? Bully for you! I don't blame you. I hid there for many years myself; server-side is a haven of sanity, isn't it? But I think you'll find that adding web programming to your skills lineup will go a long way; you'll be able to wire up those nifty backends you're writing in ways that real-live people will appreciate. Like, say, your family. And real employers too. They like the web. There's money there. So DHTML/AJAX a great Mixin skill; it complements just about anything else you know how to do.
 

Ref: http://steve-yegge.blogspot.in/search?q=book

CSS: The Definitive Guide
book
by Eric A. Meyer

Steve Yegge's Review:

I've been doing a lot of JavaScript and DHTML and AJAX programming lately. Increasing quantities of it. Boy howdy. The O'Reilly DHTML book has gotten big enough to crush a Volkswagon Bug, hasn't it? And my CSS book has gone from pristine to war-torn in under a month. I've managed to stay in the Dark Ages of web programming for the past 10 years: you know, HTML, a little CGI, font color="red". Way old school. And now I'm getting the crash-course. The more I learn, the more I wish I'd known it for longer. Although then I'd have had to live through the long transition from Dark Ages to the muchly-improved situation we have today. Far from good, to be sure, but it's improved dramatically since last I looked.

Ref: http://steve-yegge.blogspot.in/search?q=book

HTML & XHTML: The Definitive Guide (6th Edition)
book
by Chuck Musciano, Bill Kennedy

Steve Yegge's Review:

I've been doing a lot of JavaScript and DHTML and AJAX programming lately. Increasing quantities of it. Boy howdy. The O'Reilly DHTML book has gotten big enough to crush a Volkswagon Bug, hasn't it? And my CSS book has gone from pristine to war-torn in under a month. I've managed to stay in the Dark Ages of web programming for the past 10 years: you know, HTML, a little CGI, font color="red". Way old school. And now I'm getting the crash-course. The more I learn, the more I wish I'd known it for longer. Although then I'd have had to live through the long transition from Dark Ages to the muchly-improved situation we have today. Far from good, to be sure, but it's improved dramatically since last I looked.

Ref: http://steve-yegge.blogspot.in/search?q=book

The Algorithm Design Manual
book
by Steven S Skiena

Steve Yegge's Review:

My absolute favorite for this kind of interview preparation is Steven Skiena's The Algorithm Design Manual. More than any other book it helped me understand just how astonishingly commonplace (and important) graph problems are – they should be part of every working programmer's toolkit. The book also covers basic data structures and sorting algorithms, which is a nice bonus. But the gold mine is the second half of the book, which is a sort of encyclopedia of 1-pagers on zillions of useful problems and various ways to solve them, without too much detail. Almost every 1-pager has a simple picture, making it easy to remember. This is a great way to learn how to identify hundreds of problem types.

Ref: http://steve-yegge.blogspot.in/search?q=book

Introduction to Algorithms, 3rd Edition (MIT Press)
book
by Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, Clifford Stein

Steve Yegge's Review:

Other interviewers I know recommend Introduction to Algorithms. It's a true classic and an invaluable resource, but it will probably take you more than 2 weeks to get through it. But if you want to come into your interviews prepped, then consider deferring your application until you've made your way through that book.

Ref: http://steve-yegge.blogspot.in/search?q=book

The C Programming Language
book
by Brian W. Kernighan, Dennis M. Ritchie

Steve Yegge's Review:

This is an odd little book. It's frequently mistaken for an introductory programming book, which inevitably leads to frustration. It's not a good way to learn how to program; it expects that you're already familiar with machine architecture, assembly language, compilers, and at least one other high-level language.

It's not even a very good way to learn C. The idioms and best-practices for C programming have evolved substantially, even since the second edition was published, and some of the code samples look a bit dated.

However, with all that said, it's still an amazing little book. The C language is a remarkably elegant balancing act between efficiency and expressiveness. By today's standards, perhaps, it doesn't seem very feature-rich, and many people feel that programming in C can be tedious. Perhaps so. It depends, I think, on the size of the system you're trying to build, and on your overall familiarity with the language and tools.

C isn't really suitable for building huge systems, but it was never intended to be. C was created for making Unix, and Unix isn't a large system; it's a large collection of small systems that work together cleanly and effectively (for the most part).

C is an elegant language, and is in my opinion quite a breath of fresh air if you've been working in C++ for very long. People who try use C++ to build giant, hairy systems often wind up being giant, hairy programmers as a result. If you're trying to build a large system in C, you'll inevitably wind up making a choice between two alternatives:

 

  1. Use the AlternateHardAndSoftLayers design pattern, in which you write most of your code in a high-level language, and the performance-critical parts in optimized C.

  2. Try to make C a high-level language itself, which either leads to the madness of choosing C++, or the madness of implementing your own high-level language in C, without any actual syntactic support.

 

Most companies choose the second option, usually because they haven't learned the hard way that 90% of your code never needs to be optimized, and doing so won't produce any human-observable difference in runtime performance.

Java is essentially a pre-packaged, turnkey solution for option #1; hence it has all the pros and cons of a turnkey solution. It's easier -- you only have to learn one language, and you can avoid most of the low-level programming and porting issues. The downside is that you're not using a true high-level language, and it's not as easy to optimize the performance-critical parts. But on the whole, it's better than trying option #2.

When it comes right down to it, though, C is a beautiful little language. Many (most?) computer games these days use the AlternateHardAndSoftLayers pattern; the game engine is written in C, and the games themselves are written in higher-level languages. And the game industry is one of the most obsessively performance-focused software industries out there, so that's pretty strong evidence in favor of that pattern.

I guess what I'm trying to say is that writing in C is a pleasure, as long as you don't try anything too ambitious by yourself. And the K&R book may just be the best way to see this. It's certainly a great way to come back to the language after you've been a way for a while.

Summary: after a long hard day of C++ programming, it's nice to revisit something simple and elegant.

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Compilers: Principles, Techniques, and Tools (2nd Edition)
book
by Alfred V. Aho, Monica S. Lam, Ravi Sethi, Jeffrey D. Ullman

Steve Yegge's Review:

This is the (in)famous "Dragon Book", and it's by far the hardest book in the list so far, even more so than The Algorithm Design Manual, in no small part because it's extremely dense. That, or I'm extremely dense. Or both.

However, all the other compilers books I've tried out have been unsatisfactory. We used this one in school, and I pretty much hated it. Every few years I'd pull it out and try to puzzle through it, and it would put me right to sleep. Wonderful soporific, for those of you with occasional bouts of insomnia. The authors have evidently released a new version in C (the old one was in Ada), and maybe it's gotten better, but I haven't looked at it.

After several years of fighting with the Fisher and LeBlanc book, I finally bought myself a copy of the Dragon Book. I'd heard the most awful horror stories about it, so you can imagine this was an act of sheer desperation. And much to my surprise, I found it to be a wonderful book.

I can appreciate the arguments to the effect that it's not a good text for undergraduate students. But that's clearly not the intent of the book. The book was obviously written for the educated researcher or working professional who wants to write a compiler, and doesn't want to mess around. It covers virtually all of the issues known to compiler writers at the time it was published, except for some of the fancier optimization techniques. I have no doubt that Richard Stallman possesses a dog-eared copy, and so do the teams that have built virtually all production-quality compilers in the past 20 years.

I'm going to argue in a yet-to-be-published essay that Compilers and Operating Systems are the most important courses in an undergraduate CS degree, and that both of them should be required for graduation. Unfortunately I don't know of any CS degrees that require them both; usually they let you get by with one or the other (or neither).

Suffice it to say for now that a working knowledge of compiler construction is the thing that differentiates good programmers from average ones, and expertise with compilers is something you find in all great programmers. Even if you never plan on writing or working on a compiler yourself, it's still the most important CS subject, and it's a damned shame that most schools don't tell you how and why it's so important.

There are other books on compilers, and you'll probably need to struggle with many of them before it all starts to really come together. Compilers are among the most complex programs a person can write, and it's taken fifty years for the world to figure out as much as we know about them -- which isn't enough by a long shot, but the situation is improving.

But I think once you've really started to master the subject, the Dragon Book is the one you'll keep coming back to. So it makes the list.

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Steve Yegge's Review:

Our first O'Reilly title in the list! It has an owl on the front; owls are known for their, uh, regular, erm, never mind. It's not always clear how O'Reilly picks their colophons.

This is a great book for exactly, precisely the reason that all O'Reilly books are great: it covers complex material in a way that's accessible to uncomplex people. Ever notice that "O'Reilly" sounds just like "for Dummies" underwater? And quite frankly, I'm the proud owner of several "for Dummies" books (publisher: IDG, which I believe stands for "IDiot's Guide"); they're very similar to O'Reilly books in their general approach and target audience. It might sound like I'm bashing on for-Dummies books, but quite the contrary -- I hate badly-written, pretentious books that don't talk to me like a person. I've often wished that O'Reilly would publish a Computer Science series.

Anyway, regular expressions are a mini-language for generating and matching regular languages, a concept introduced by the famous linguist Noam Chomsky. A "mini-language" is a special-purpose language with its own jargon and structure. A famous example is StarbucksSpeak, a Turing-complete coffee-ordering mini-language with a rich, free-form syntax and domain-specific jargon, allowing well-formed expressions such as: "Grande quad-shot no-room light-foam half-caf half-decaf half-lowfat half-nonfat 190-degree sugar-free vanilla medium-roast half-white chocolate half-regular chocolate Mocha Valencia with 1 pump sugar-free hazelnut and a sprig of nutmeg. Oh, and make that iced."

As one Starbucks employee put it: "More words means more money." I believe the drink above costs over seventeen dollars. You need to learn the idioms and efficiency considerations for each minilanguage to help optimize its performance.

Other widespread minilanguages include: Pizza-Ordering Language (which has many dialects but is more or less universal), Swearing Like A Drunken Sailor (which is useful when you receive the bill for your car repairs, written in the Auto Repair Theft mini-language), and of course Pig Latin, which is helpful for talking about slower co-workers ("ob-Bay's ot-nay oo-tay ight-bray, is he?"). Mini-languages are everywhere, and can be quite fun.

Regular expressions are no exception. They let you parse a log file faster than you can say: "does Python's case-insensitivity metacharacter span the entire expression, or is that just in Perl?" Like the syntax for printf's format string, regexps are a tool that will be useful in almost any language you use.

Strongly recommended. Oh, and make mine iced.

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

The Little Schemer, Fourth Edition
book
by Daniel P. Friedman, Matthias Felleisen

Steve Yegge's Review:

This is without question one of the weirdest technical books you'll ever encounter. But don't be put off by the format. Well, you WILL be put off by it, but try not to be dogmatic about it.

This book makes my top-10 list because it helped me understand recursion and think recursively better than any other approach. Scheme is a fine language for doing this, although they could probably have just as easily done the book in Haskell or Ruby. It doesn't matter, though -- the concepts transcend the language.

A lot of people simply avoid recursion because they've heard it doesn't perform very well. They don't practice it, so when they run into situations where recursion is the most natural approach, they have a LOT of trouble with it.

Recursion is the most natural way to express many algorithms, including tree and graph traversals, linear and dynamic programming, parsing of computer languages and natural languages, and plenty of others. If you aren't comfortable thinking recursively, you'll tend to steer clear of recursive solutions, which means that for many problems you'll wind up with code that's a lot uglier and error-prone than it should have been.

The Little Schemer is not a book that you can sit down and read like a novel, or even like a J2EE technical manual. You have to work through all of the examples yourself, by hand, in order, and you can't skip any of them.

The painful way (IMO) is to use a Scheme interpreter; I found it easier to translate the examples into Emacs-Lisp and run them in lisp-interaction-mode. There are only a few simple rules to remember. Or perhaps you can find a Scheme plug-in for your favorite editor. However you decide to do it, you need to do it -- you have to solve the problems yourself.

They recommend that you don't try doing the book all in one sitting; it has about 10 chapters, and I was doing about 2 a day, so I got through it in about a week (about an hour a day).

About halfway through, you really start getting the hang of it, and by then they're mostly teaching you common idioms for recursion. If you really do the examples, it gradually becomes fairly trivial to express things as singly- or doubly-recursive functions.

I haven't made it through the Seasoned Schemer yet -- that'll undoubtedly be in my "Ten Wishes" blog entry about books that I want to read. But I'm looking forward to it.

Summary: wonderful book. Definitely deserves a spot in my Top 10 list.

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Design Patterns: Elements of Reusable Object-Oriented Software
book
by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Steve Yegge's Review:

This book was incredible. When it came out in early 1995, it offered a set of 23 little reprieves from the blind, crawling, Lovecraftian madness of C++ programming. (Ever notice how "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn" and "Protected abstract virtual typedef'd copy constructor function" sound identical underwater? Yup. The Elder Gods are lumbering and gibbering around Redmond right now.)

Well, it was 22 reprieves, really, since the Interpreter pattern was put in there as sort of an in-joke. 1994, the year the book was being prepared, was in fact the 40th anniversary of John Backus's 1954 observation that most programmers detested the idea of a "compiler":

At that time, most programmers wrote symbolic machine instructions exclusively (some even used absolute octal or decimal machine instructions). Almost to a man, they firmly believed that any mechanical coding method would fail to apply that versatile ingenuity which each programmer felt he possessed and constantly needed in his work. Therefore, it was agreed, compilers could only turn out code which would be intolerably less efficient than human coding..."   [John Backus in the 1954 Fortran report]

 

So true! Compilers are for sissies. Just ask anyone from Geoworks, if you can find anyone left now that they've gone out of business. We all wrote everything in assembly language; it's obvious that computer time is more expensive than programmer time, and good programmers can hand-generate code that outperforms anything any compiler can generate. If-statements and for-loops were for pansies. We had "jcxz" and that was enough.

Most of the programming world who believed that you should write everything in assembly language have moved on (that's a euphemism for "died".) Their children and grandchildren today (that's you!) realize that, well, compilers are pretty important. We'll begrudge them their place. But programmers today firmly believe that any Interpreted coding method such as Java or Ruby fails to apply that versatile ingenuity which each programmer feels he/she possesses and constantly needs in his/her work, etc.

The authors of Design Patterns thought this was pretty funny. The machines change; the languages change, but people don't change. So they threw in the Interpreter pattern as a sort of practical joke, a gag that no real programmers with hairs on their chests would actually understand, let alone agree with.

Other than that, the book was great!

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Steve Yegge's Review:

This is one of my favorite books on programming, although I burned through it in about 3 or 4 hours, and didn't learn a huge amount from it. The point is that it was fun to read, it made a lot of sense, and it was helpful in reinforcing the habits I knew were good ones.

The primary focus of the book is on how to be an effective and efficient programmer, and how to have fun practicing your craft. So, for instance, they'll recommend that you learn how to touch-type with all ten of your fingers. And that you choose a powerful extensible editor and learn how to write extensions for it. And that you use a programming language that supports metaprogramming, so you can code your way out of holes without using hundreds of thousands of lines of code.

Sounds a bit like some of my blogs, doesn't it?

Honestly, though, I worry that the book is somewhat futile. It may be one of those books that you either understand and agree with already, or you never will.

I've sent out suggestions on mailing lists that were more or less directly out of the book, and received responses from so-called engineers who proudly claim, pecking their response out with their index fingers, that they've "gotten by" for 4 years without ever writing a script. Then they mail the same list asking if anyone knows of a refactoring tool that will do a global name-change inside comment headers. Or they'll refuse to listen when the entire community tells them that an identifer name needs to be changed, because it's now "used in too many places". (Yes, I kept those emails; they're in my "broken SDEs" folder.)

Or during a discussion about metaprogramming and code-squishing techniques, someone will just snap, and start ranting about how any OOP book will tell you that EJB is the only thing you need to know.

I'm going to put the book on my Top 10 list in the hopes that there are some programmers out there who haven't yet realized the merits of practicing at being more efficient, and who aren't so set in their ways that the mere thought of learning something new sends them off the deep end into a spittle-emitting rage. It really is a good book, and a fast read. And everything it really does matter, so pay the most attention to the parts that seem to matter the least. Those are the ones you should work on.

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Refactoring: Improving the Design of Existing Code 1st Edition
book
by Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts

Steve Yegge's Review:

When I read this book for the first time, in October 2003, I felt this horrid cold feeling, the way you might feel if you just realized you've been coming to work for 5 years with your pants down around your ankles. I asked around casually the next day: "Yeah, uh, you've read that, um, Refactoring book, of course, right? Ha, ha, I only ask because I read it a very long time ago, not just now, of course." Only 1 person of 20 I surveyed had read it. Thank goodness all of us had our pants down, not just me.

This is a wonderful book about how to write good code, and there aren't many books like it. None, maybe. They don't typically teach you how to write good code in school, and you may never learn on the job. It may take years, but you may still be missing some key ideas. I certainly was.

The book talks about production code at the level of individual functions, and even snippets of code within a function. It starts by showing you ugly functions that work, then shows you, step by step, how to make them clean and beautiful without breaking them. Some of the techniques are quite powerful, and many can be automated. The book simultaneously showed me why some of my functions had grown large and gnarled, despite my best efforts, and then gave me tools and confidence for fixing it.

The book's examples are in Java, but don't let that put you off. The ideas are relevant for every programming language. I know a guy who read through it without knowing any Java, and immediately began putting the ideas to work in refactoring his Perl code. I even factor and refactor my Lisp code these days.

If you're a relatively experienced engineer, you'll recognize 80% or more of the techniques in the book as things you've already figured out and started doing out of habit. But it gives them all names and discusses their pros and cons objectively, which I found very useful. And it debunked two or three practices that I had cherished since my earliest days as a programmer. Don't comment your code? Local variables are the root of all evil? Is this guy a madman? Read it and decide for yourself!

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Steve Yegge's Review:

 I read a neat book called Predictably Irrational: The Hidden Forces That Shape Our Decisions, by Dan Ariely. The book is a fascinating glimpse into several bizarre and unfortunate bugs in our mental software. These bugs cause us to behave in weird but highly predictable ways in a bunch of everyday situations.

For instance, one chapter explains why bringing an uglier version of yourself to a party is guaranteed to get you more attention than other people who are arguably better-looking than you are. I personally do this all the time, except that I'm usually the ugly one. The same principle explains a ploy used by real-estate agents to get you to buy ugly houses.

Another chapter explains the bug that causes you to be a packrat, and shows why you desperately hold on to things you own, even if you know deep down that they would rate lower than pocket lint on eBay.

In any case, well, good book. I'm going to harsh on it a teeny bit here, but it's only one tiny part towards the end, one that actually has little to do with the rest of the research presented in the book. I still highly recommend it. It's only about a 4- or 5-hour read: beyond the reach of most social-network commenters, perhaps, but you can probably handle it just fine.

So: about that harshing. Dan Ariely, who seems like a pretty fascinating guy in his own right, independent of his nifty book, says something that's kinda naïve towards the end. It doesn't seem naïve at all when you first read it. But naïve it is.

Towards the end of the book — and I apologize here, since my copy is on loan to a friend at the moment, and you can't search inside the book on Amazon.com no-thanks to the book's publisher, so I can't double check the exact details — but towards the end, Dan works himself into a minor frenzy over what seems like a neat idea about credit cards.

Ref: http://steve-yegge.blogspot.in/search?q=book

The Algorithm Design Manual
book
by Steven S Skiena

Steve Yegge's Review:

This book came highly recommended from a friend of mine who reads a lot (great programmer, too) -- in fact, the same person who was the only one (out of 20) who had read Refactoring, back when I was polling people about it in October of last year.

I've read through most of the book, although I'm not certain I've read all of it, because it's more like an encyclopedia than a continuous narrative. It took me a while to appreciate how useful it is, in part because I wasn't really grokking its organization, which is part narrative, part cookbook, and part bibliography.

But it works! It provides fairly comprehensive coverage of the most common data structures and algorithms, but with a focus on teaching you how to model problems and select the right algorithm. It's filled with "War Stories" and real-life examples.

Most of the examples are wgah'nagl and take several pages of explanation, often with detailed diagrams. If you work through them carefully, you'll gain real familiarity with some useful techniques for solving NP-complete problems. And I have to confess that I didn't fully appreciate how widespread graphing problems are, and how many things can be modeled (and solved) with graph algorithms, until I read this book.

I've read a ton of data-structures and algorithms books, and I've never found one like this one. Its unconventional approach is refreshing and keeps you interested. I find myself coming back to it frequently, and always learning something new.

Summary: this one's a keeper.

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Steve Yegge's Review:

Excellent book on concurrency. Doug Lea wisely steers clear of Quantum Chu Spaces and even basic arithmetic, preferring to focus on "sound engineering principles" that can help your multi-threaded programs run for as long as possible without context-switching. Haha, just kidding. It helps them run as long as possible with context-switching. Jest seein' if yer awake.

Doug really does a wonderful job, at least the second time around; the first edition read like it was by Ph.D's forPh.D's, which means it was primarily targeted at ineffectual companies like Google.[1] But the second edition is far more manly, hence the cover-art color-scheme switch from cold Vulcan blood-green to manly human blood-red. Really.

The nice thing about this book is that as long as you're using a von Neumann computer, you're going to have to worry about how to fake parallelism on a sequential device, and that's nontrivial. ("Nontrivial" is a computer science term that sounds just like "wgah'nagl" underwater. 'Nuff said.) So even though the subtitle of this book is "in Java", the principles apply to just about any programming language, including Hasturese. Strongly recommended.

Ref: https://sites.google.com/site/steveyegge2/ten-great-books

Operating Systems

This is just a plug, from me, for you to know about processes, threads and concurrency issues. A lot of interviewers ask about that stuff, and it's pretty fundamental, so you should know it. Know about locks and mutexes and semaphores and monitors and how they work. Know about deadlock and livelock and how to avoid them. Know what resources a processes needs, and a thread needs, and how context switching works, and how it's initiated by the operating system and underlying hardware. Know a little about scheduling. The world is rapidly moving towards multi-core, and you'll be a dinosaur in a real hurry if you don't understand the fundamentals of "modern" (which is to say, "kinda broken") concurrency constructs.

The best, most practical book I've ever personally read on the subject is Doug Lea'sConcurrent Programming in Java. It got me the most bang per page. There are obviously lots of other books on concurrency. I'd avoid the academic ones and focus on the practical stuff, since it's most likely to get asked in interviews.

Ref: http://steve-yegge.blogspot.in/search?q=book

Steve Yegge's Review:

OK, but what about Firefox? Why don't they, you know, innovate? Well, they're trying, I think, but for what I'm guessing are probably tangled historical reasons — which manifest as the developers often being gridlocked politically — Mozilla lacks what Fred Brooks Jr. calls "conceptual integrity" in his classic "The Mythical Man-Month". [Which, incidentally, remains today the most vitally relevant book on software engineering, over 30 years after it was written.] The Mozilla folks would have to do a lotof serious re-thinking in order to reduce XUL's "Hello, World" down to a few lines of code in a single language. And I'm not convinced that kind of thinking is happening in the Firefox camp right now. It's not that they're not thinking at all; don't get me wrong. They're just not thinking about radical, revolutionary user-level simplifications to the basic framework.

Ref: http://steve-yegge.blogspot.in/search?q=book

Ajax: The Definitive Guide
book
by Anthony T. Holdener III

Steve Yegge's Review:

Hang on — you're not still a thick-client programmer, are you? Oh dear. You'd better get yourself a DHTML book and an AJAX book, and right-quick. Oh, you're above that client stuff, you're a server-side programmer then, are you? Bully for you! I don't blame you. I hid there for many years myself; server-side is a haven of sanity, isn't it? But I think you'll find that adding web programming to your skills lineup will go a long way; you'll be able to wire up those nifty backends you're writing in ways that real-live people will appreciate. Like, say, your family. And real employers too. They like the web. There's money there. So DHTML/AJAX a great Mixin skill; it complements just about anything else you know how to do.
 

Ref: http://steve-yegge.blogspot.in/search?q=book

CSS: The Definitive Guide
book
by Eric A. Meyer

Steve Yegge's Review:

I've been doing a lot of JavaScript and DHTML and AJAX programming lately. Increasing quantities of it. Boy howdy. The O'Reilly DHTML book has gotten big enough to crush a Volkswagon Bug, hasn't it? And my CSS book has gone from pristine to war-torn in under a month. I've managed to stay in the Dark Ages of web programming for the past 10 years: you know, HTML, a little CGI, font color="red". Way old school. And now I'm getting the crash-course. The more I learn, the more I wish I'd known it for longer. Although then I'd have had to live through the long transition from Dark Ages to the muchly-improved situation we have today. Far from good, to be sure, but it's improved dramatically since last I looked.

Ref: http://steve-yegge.blogspot.in/search?q=book

HTML & XHTML: The Definitive Guide (6th Edition)
book
by Chuck Musciano, Bill Kennedy

Steve Yegge's Review:

I've been doing a lot of JavaScript and DHTML and AJAX programming lately. Increasing quantities of it. Boy howdy. The O'Reilly DHTML book has gotten big enough to crush a Volkswagon Bug, hasn't it? And my CSS book has gone from pristine to war-torn in under a month. I've managed to stay in the Dark Ages of web programming for the past 10 years: you know, HTML, a little CGI, font color="red". Way old school. And now I'm getting the crash-course. The more I learn, the more I wish I'd known it for longer. Although then I'd have had to live through the long transition from Dark Ages to the muchly-improved situation we have today. Far from good, to be sure, but it's improved dramatically since last I looked.

Ref: http://steve-yegge.blogspot.in/search?q=book

The Algorithm Design Manual
book
by Steven S Skiena

Steve Yegge's Review:

My absolute favorite for this kind of interview preparation is Steven Skiena's The Algorithm Design Manual. More than any other book it helped me understand just how astonishingly commonplace (and important) graph problems are – they should be part of every working programmer's toolkit. The book also covers basic data structures and sorting algorithms, which is a nice bonus. But the gold mine is the second half of the book, which is a sort of encyclopedia of 1-pagers on zillions of useful problems and various ways to solve them, without too much detail. Almost every 1-pager has a simple picture, making it easy to remember. This is a great way to learn how to identify hundreds of problem types.

Ref: http://steve-yegge.blogspot.in/search?q=book

Introduction to Algorithms, 3rd Edition (MIT Press)
book
by Thomas H. Cormen, Charles E. Leiserson, Ronald L. Rivest, Clifford Stein

Steve Yegge's Review:

Other interviewers I know recommend Introduction to Algorithms. It's a true classic and an invaluable resource, but it will probably take you more than 2 weeks to get through it. But if you want to come into your interviews prepped, then consider deferring your application until you've made your way through that book.

Ref: http://steve-yegge.blogspot.in/search?q=book

You might also be interested in

Ben Horowitz
9 recommendations
Mark Cuban
12 recommendations
Danielle Morrill
51 recommendations
Casey Neistat
2 recommendations
Warren Buffett
35 recommendations