Steve Yegge has a way with words. I like Stevey’s Drunken Blog Rants (and plain Blog Rants) because he says things that need to be said in an engaging and entertaining way, and he takes the proper amount of time to say things without being too terse or dragging things out. Some people think his posts are too long, but I disagree. He goes into more depth and explores his ideas much more thoroughly than he could in a shorter format. I enjoy spending time on these topics, time that a short blog post wouldn’t give me. In fact, I would welcome a book because the longer format would do thoughtful topics like Steve’s even more justice.

Reading all of Steve’s posts would be much like reading a book, although a somewhat disjointed one. Some posts wouldn’t fit in at all. To get some feel for what a Steve Yegge book would be like, I’ve put together 15 of what I think are Steve’s best rants. It wouldn’t be a long book, taking only a night or two to read through, but the topics are good and it sticks to his more timeless writings. I reread them all for this post, doing one per day and really enjoying it. Each one of these posts is here because it’s either an entertaining read or great food for thought, or both.

Nonesuch Beast

This post covers fundamental trade offs and irreducible complexity. Steve uses the example of a document management system and how a Wiki is good enough for most practical purposes. People want to use the simplest tool possible. They don’t want to spend time learning something complicated when they run the risk of never using it again. It’s a defense mechanism for pain minimization. Where things start to fall apart is when different people using the system want different things from it, so each user’s feature requests add complexity to the system. He also goes through a second, more extended example of a general purpose metrics system, and comes to the conclusion:

Metrics systems, much like documentation systems, have a fundamental tradeoff: you can have a complex system with lots of features, or you can have a simple system with few features. But not both.

The solution he ended up with was to create custom systems from simple components to address the specific problem at hand.

Practical Magic

Wherein Steve ponders whether or not you should intimately understand the abstractions you use. It is a really hard problem. How much time do you spend understanding how your tools are built and how they work? There are arguments for both sides. Plenty of programmers are effective only knowing high-level languages and even higher-level frameworks while chalking all of the underlying technology up to magic. Other programmers make awesome stuff hacking away on low-level things, probably making the high-level languages and frameworks that everyone else uses. Knowing where and how your abstractions leak can save you when they break down and you have to work around the mess. Plus, I find learning and understanding how your tools work to be fascinating and well worth the effort for personal development.

Being the Averagest

Steve tackles the issue of programmers judging how good they are and how they can get better. One flawed way is for companies to create metrics for programmers that the programmers then proceed to dissect and game for all they’re worth. Another one is the stack-rank method of rating programmers, and it over-simplifies a programmers worth by projecting all of a programmer’s qualities onto a single ‘goodness’ axis. Turning to how a programmer should get better, he looks at how almost every other profession has methods of competition to incentivise people to practice and get better, while very few programmers practice. Programmers that don’t practice or try to learn things they don’t already know tend to think they know enough to do their job and there’s no reason to learn more. If they need something new to do their job, they can learn it in real time. It’s a case of not knowing what you don’t know that could make you a much better programmer all the time, not just for some particular task. To overcome that attitude, you need to be cognizant of holes in your knowledge that could be potentially useful to know, and make an effort to learn those things. Then the hard part of actually learning and improving begins.

Ten Challenges

Steve wrote a top ten list of great books that every programmer should read. What follows is not that list. He also wrote a Ten Challenges list that puts forward ten books that you will have to chew on and struggle through to get the valuable stuff out, but they’re completely worth it. They’re all on my To Read list, and the first one I’ll tackle will probably be the classic, SICP (using this great interactive site). Here’s Steve’s full Ten Challenges list:

• Gödel, Escher, Back: An Eternal Golden Braid by Douglas R. Hofstadter
• Structure and Interpretation of Computer Programs by Harold Abelson and Gerald Sussman
• Digital Typography by Donald Knuth
• Programming Language Pragmatics by Michael Scott
• The Essentials of Programming Languages by Daniel P. Friedman and Mitchell Wand
• Types and Programming Languages by Benjamin C. Pierce
• The Seasoned Schemer by Daniel P. Friedman and Matthias Felleisen
• The Scheme Programming Language by R Kent Dybvig
• How to Design Programs by Felleisen, Findler, Flatt, and Krishnamurthi
• Purely Functional Data Structures by Chris Okasaki

Allocation Styles

Programming styles can be classified in the normal way as imperative, functional, or declarative, but they can also be classified as six different memory allocation styles. Steve’s made-up allocation styles are allocation-free programming, buffer-oriented programming, collection-oriented programming, list-oriented programming, query-oriented programming, and pattern-match programming. He explains each style in detail, the trade-offs involved in each one, what problems are easy or hard when using each style, and which programming languages make the most use of each style. He hits on a lot of important points about problem analysis, optimization, and code organization. He also starts what becomes a long-running theme of Java-bashing.

Is Weak Typing Strong Enough?

This post starts out with a list of pros and cons of strong static typing, and by inversion, the cons and pros of weak dynamic typing. Strong and static typing are different concepts, but they’re normally found together (likewise for their opposites, weak and dynamic typing). Strong and weak typing generally serve different development environments and create markedly different systems. Strong typing lends itself to large, rigid systems built from big up-front design, and weak typing is better for highly flexible, changing systems, especially prototypes. It turns out that most systems actually are of the constantly changing variety, and Steve lays out the reasons why he’s converted to the weak typing camp. This point is especially pertinent:

Generally speaking, strong static typing has gotten in our way, time and again, and weak typing has never resulted in more “horribly bad” things happening than the equivalent strong-typing approaches. Horribly bad stuff just happens sometimes, no matter what approach you use.

Besides, the real reason big systems are only written in strongly typed languages may be because using strongly typed languages results in big systems. The same system written in a weakly typed language could be orders of magnitude smaller.

Tour de Babel

This is the post where Steve lays out what he thinks of a bunch of different programming languages. He covers C, C++, LISP, Java, Perl, Ruby, and Python. Notably missing are JavaScript and Haskel, but don’t worry; he covers them often enough in later posts. C# is also missing, but I’m pretty sure it wasn’t even a thing when this post was written and certainly wouldn’t have been applicable to writing software at Amazon. This language tour is chock full of gems like, “If C is the closest language to modeling how computers work, Lisp is the closest to modeling how computation works.” And “Java is simultaneously the best and the worst thing that has happened to computing in the past 10 years.” Most of the commentary is related to the languages in use at Amazon at the time, and the pros and cons of using different languages to build Amazon’s systems. Despite the narrow context, it’s a fascinating read, and the points for or against each language are sharp and witty. The Perl section is especially good; well worth a read.

Blogger’s Block #3: Dreaming in Browser Swamp

Steve tries to address the question of whether or not the browser is a platform. He also talks a lot about how JavaScript is eating the world (which it has) and takes quite a few jabs at Java (which he increasingly does as he continues blogging). He highly praises Ruby on Rails, and goes into extended detail about how well Rails handles the giant mess that was and is web browsers and web development. It’s amazing to look back at this post from 2006 and see how far we’ve come with tooling and frameworks, and how far we still have to go. Some of the things he ranted about have been solved, but others are still big problems that need to be addressed. Who knows if web development will ever be truly elegant. Steve closes this post with an admission that some of the criticism he gets has been getting under his skin, and he thinks he’ll write better if he ignores the comments. Seeing as this is the first of his posts that I thought was really good after he transitioned from Amazon to Google and went public with his blogging, he may have been on to something. He’s still got a number of great posts in him.

Blogger’s Block #4: Ruby and Java and Stuff

Another rant from Steve in his attempt to restart his blogging about the things he really wants to talk about, this post starts off with what I find is a very accurate assessment of Ruby. It’s hard to talk about Ruby because it’s so good that it just steps out of the way, and all you’re left with is the problem at hand. He then rants about some of the Java framework libraries before getting to the real meat of his post—literals in Java. Java essentially doesn’t have literals, except for a few basic types, and that creates some serious problems. The discussion is one of the best I’ve seen on why good literal syntax is important, and it brought up issues that I never thought about but run into all the time. I don’t program in Java, but I do program in C and C++. They have similar issues with literals, although not quite as bad as Java. He also takes some good shots at OOP, showing that it’s not the answer to everything. I think he was right, and more and more programmers are coming around to the realization that other paradigms, like functional programming, can also be very useful for classes of problems that OOP can’t deal with.

Rich Programmer Food

This is the post where Steve tries to convince you of the merits of learning how a compiler works, and he does a pretty good job of it. I’m not only convinced of the merits, but every time I read it, I end up wanting to write one myself. I did write one in college for a toy language that looked vaguely like Java without 90% of Java’s features, and it was written in Java. Now I feel like that didn’t really count, especially because like Steve, I wasn’t fully paying attention in that class. Now that I know more about how important compilers are, I want to explore them more thoroughly. If only I had the time. Anyway, the post goes through why compilers are important, what you can do with compilers (hint: it’s not all machine code generation), and a bit about how compilers work. They generally have three phases: parsing, type checking, and optimization. Each phase is a world of its own, and the way Steve presents it makes for an interesting read. If you’re at all interested in compilers before reading it, you’ll be wanting to write your own compiler by the end. I warned you.

Portrait of a N00b

This is a very long post (and probably my favorite of all of his posts) about how programmers develop from beginners to experts and how they can handle looking at a higher density of code over time. The first half of the post focuses on how new programmers will over-comment their code while experienced programmers strip away most of the meta data (in the form of comments) and compress their code down so they can see more of it at once. When programmers from different ends of the spectrum end up on the same team, conflict ensues because of how differently they look at code and how different their needs are. I tried writing a similar post with many of the same points, but Steve presents the topic in a much more entertaining way, I think. Then he does some literary judo in the middle and ends up transforming the discussion about meta data into a critique on static typing. Inexperienced programmers will overuse comments and static typing in the same way, while experienced programmers don’t need those things and end up getting much more real work done. I can definitely see my own perspectives on programming evolving along similar lines as I gain experience and learn more languages and language features, and the whole post really resonated with me. This summary in no way does the post justice. There is way too much good stuff in it. You have to read it yourself to get the full effect.

Dynamic Languages Strike Back

This post is a transcription of a talk that Steve gave at the Stanford EE Computer Systems Colloquium in 2008, and it’s both really entertaining and informative about where dynamic languages were headed circa 2008. He talks about all kinds of issues that dynamic languages have (or will) overcome and plenty of myths held by people that haven’t worked with them much. Certain problems, like the how-to-deal-with-millions-of-lines-of-code problem, are completely circumvented by dynamic languages because they simply don’t have code bases with those problems. Steve goes through a ton of stuff in this talk. Don’t let the beginning fool you. It’s a bit rambling and loose at first, but once he gets going, things get interesting. You can see his love for programming languages here, and he is ramping up on the pro-dynamic, anti-C++ and Java language theme that his blog has had for some time. He gets into a fascinating discussion about how many of the dynamic language criticisms are also true of C++ and Java as well; they just aren’t thought of in the same way because the issues crop up when using reflection or storing type information in databases or loading configuration information through XML files. It’s a very good talk, although very long since it was an hour talk with a half hour of questions, but you should go read it instead of continuing to read about it. (By the way, after reading it again, I am reminded that I want to learn Erlang, or maybe Elixir, and of course, LISP!)

Rhinos and Tigers

This post is another transcription of a talk by Steve, this time from a talk at the Google I/O Conference in 2008, and like the last one, it is really long. That’s okay if you don’t mind reading. I love reading, and maybe because I’m more experienced each time I come back to it or I notice different things, every time I reread this post I learn something new. He starts off by explaining a bit about what Rhino is. Rhino is basically JavaScript running on the JVM. He goes into a great discussion about why you would want to use a VM, why you would want to use multiple languages that interoperate on a VM, and why you would want to use a scripting language like JavaScript. It’s all great stuff, and he does an especially good job of excusing JavaScript of some of its ugliness. He pretty convincingly argues that in the end, its benefits outweigh its costs, and in hindsight, it looks like the right recommendation. JavaScript has really taken off over the seven years since Steve gave this talk. The most entertaining part of this epic post has to be the Static Typing’s Paper Tigers section where he simultaneously rags on both Scala’s and Java’s type systems to great effect. After that things kind of tail off, mostly because it’s more specific stuff related to Rhino and Steve’s Rhino’s Not Ruby pet project, and as far as I know, nothing really came of the latter. Still, this is a great post, one I keep coming back to when I need to read something fun and informative.

Done and Gets Things Smart

In this post Steve takes on Joel Spolsky’s well known post and the book that resulted from it, Smart and Gets Things Done. He brings up a lot of good points about how it’s extremely difficult to reliably find people that are smart and get things done, that there are actually a fair number of such people, and for a startup company, that is not actually what you want. You want people that are so good, they are actually Done and Gets Things Smart. Done in the sense that they get things done so fast that it only ever seems like they’re finishing things and moving on to the next big task to knock down. Gets Things Smart in the sense that everything they touch gets much better in ways that you would never have even thought of. It’s an interesting way to think about the truly exceptional programmers, and the big issue is how do you really find these programmers? You wouldn’t ever know who they are unless you worked with them and experienced their incredible productivity and abilities for yourself. The challenge of recognizing, acknowledging, and hiring someone who is much smarter and better than you is not something most people are ready or able to do. It is a humbling and thought-provoking post.

The Universal Design Pattern

The final post I’ll recommend is so long that it needed a table of contents. Here Steve describes and discusses the Properties Pattern, a.k.a. the Prototype Pattern, and he really goes deep on the topic. It’s a very well put together post on the reasons for the pattern, most of the issues that come up when implementing the pattern, and a number of examples of the pattern in the wild. Probably the most commonly known instance of the Properties Pattern today is JavaScript, with its prototype-based inheritance system. Much of the post is, in fact, describing the details of the JavaScript language including how it implements its key/value pairs, how it deals with inheritance, and what the performance issues are. He also touches on transient properties, persistence, and type systems. It’s a great read—another one that I learn more from every time I come back to it—and like most of his posts, it leaves me with the desire to read a book. This time it’s Douglas Hofstadter’s Goedel, Escher, Bach: An Eternal Golden Braid, also from Steve’s Ten Challenges post. I’ll definitely have to give that one a look.

Steve covered a lot of ground not only in these 15 posts, but in all of his blogging. I thoroughly enjoy reading and re-reading his stuff because he has such an entertaining writing style and I learn new things every time I come back to it. He has a couple overarching themes to his posts that resonate quite strongly with me. First, he is passionate about learning to make yourself a better programmer through thorough research and study, especially by reading good books. I completely agree, and I appreciate how that sentiment comes through in his writing. Second, he believes strongly in good tooling for programming and in constantly striving to improve those tools and languages that we use every day. We’re never going to have the one programming language to rule them all, but we can keep making them better and better. Every time I read his posts, I get a renewed interest in learning new languages. Now if you’ll excuse me, I have a book I should be reading.