This is one of those “N technical things every programmer must read” lists, except that “programmer” is way too broad a term and the styles of writing people find helpful for them are too different for any such list to contain a non-zero number of items (if you want the entire list to be helpful to everyone). So here’s a list of some things you might want to read, and why you might (or might not) want to read them.
This post on why making a competitor to Google search is a post in classic Alex Clemmer style
. The post looks at a position that’s commonly believed (web search isn’t all that hard and someone should come up with a better Google) and explains why that’s not an obviously correct position. That’s also a common theme of his comments elsewhere, such as these comments on, stack ranking at MS
, implementing POSIX on Windows
, the size of the Windows codebase
, and Bing
There’s a lot of depth behind these comments and I’m hoping I can goad Alex into blogging more about these and other comments.
Explorations of various areas, often Python related, such as this this series on the Python interpreter
and this series on the CPython peephole optimizer
. Also, thoughts on broader topics like debugging
Often detailed, with inline code that’s meant to be read an understood (with the help of exposition that’s genereally quite clear).
Computer related projects, by which I mean things like reconstructing the Cray-1A
and building mechanical computers
. Rarely updated, presumably due to the amount of work that goes into the creations, but almost always interesting.
The blog posts tend to be high-level, more like pitch decks than design docs, but there’s often source code available if you want more detail.
This is a quarterly publication from RC
. Posts vary from floating point implementations in various languages
to how git works
to image processing
I wonder why web publications like this don’t get more press. There’s been a bit of a revival lately, and we’ve seen plenty of high quality publications, from high-profile efforts like The Macro
to unpublisized gems like Snowsuit
, but you don’t really see people talking about these much. Or I don’t, anyway.
A lot of great material on how engineering companies should be run. He has a lot of ideas that sound like common sense, e.g., choose boring technology
, until you realize that it’s actually uncommon to find opinions that are so sensible.
Mostly distilled wisdom (as opposed to, say, detailed explanations of code).
A mix of things from writing a 64-bit kernel from scratch shortly after learning assembly
to a high-level overview of computer systems
. Rarely updated, with few posts, but each post has a lot to think about.
I think of this as “ the C++ blog
”, but it’s much wider ranging that that. It’s too wide ranging for me to sum up, but if I had to commit to a description I might say that it’s a collection of deep dives into various topics, often (but not always) relatively low-level, along with short blurbs about books, often (but not always) technical.
The book reviews tend to be easy reading, but the programming blog posts are often a mix of code and exposition that really demands your attention; usually not a light read.
A wide variety of bite-sized technical tidbits, from how integer division behavior varies by language
to data corruption that isn’t corrected by Ethernet or TCP checksums
. Usually bite-sized and easily read.
Low-level. A good example of a relatively high-level post from this blog is this post on the low fragmentation heap in Windows
. Posts like how to hack a pinball machine
and how to design a 386 compatible dev board
Posts are often quite detailed, with schematic/circuit diagrams. This is relatively heavy reading and I try to have pen and paper handy when I’m reading this blog.
Another “not exactly a blog”, but it’s more informative than most blogs, not to mention more entertaining. This is the best “blog” on the pervasive brokenness of modern software
that I know of.
Writeups of papers that (should) have an impact on how people write software, like this paper on what causes failures in distributed systems
or this paper on what makes people feel productive
. Not updated much, but Greg still blogs on his personal site
The posts tend to be extended abstracts that tease you into reading the paper, rather than detailed explanations of the methodology and results.
If you’ve read Love’s book on Linux, Duarte’s explanations are similar, but tend to be more about the idea and less about the implementation. They’re also heavier on providing diagrams and context. “0xAX” is a lot more focused on walking through the code than either Love or Duarte.
Jessica is probably better known for her talks
than her blog? Her talks are great! My favorite is probably this talk with explains different concurrency models in an easy to understand way
, but the blog also has a lot of material I like
As is the case with her talks, the diagrams often take a concept and clarify it, making something that wasn’t obvious seem very obvious in retrospect.
I think of this as the “C is harder than you think, even if you think C is really hard” blog
, although the blog actually covers a lot more than that. Some commonly covered topics are fuzzing, compiler optimization, and testing in general.
Posts tend to be conceptual. There’s often code as examples, but it tends to be light and easy to read, making this a relatively easy read even though it covers a lot of important ideas.
A lot of posts about networking
, generally written so that they make sense even with minimal networking background
. I wish more people with this kind of knowledge (in depth knowledge of systems, not just networking knowledge in particular) would write up explanations for a general audience. Also has interesting non-networking content, like this post on Finnish elections
AFAICT, the theme is “things Julia has learned recently”, which can be anything from Huffman coding
to how to be happy when working in a remote job
. When the posts are on a topic I don’t already know, I learn something new. When they’re on a topic I know, they remind me that the topic is exciting and contains a lot of wonder and mystery.
Many posts have more questions than answers, and are more of a live-blogged exploration of a topic than an explanation of the topic.
The technical explorations often get into enough nitty gritty detail that this is something you probably want to sit down to read, as opposed to skim on your phone.
90% of Kyle’s posts are explanations of distributed systems testing, which expose bugs in real systems that most of us rely on
. The other 10% are musings on programming that are as rigorous as Kyle’s posts on distributed systems
. Possibly the most educational programming blog of all time.
For those of us without a distributed systems background, understanding posts often requires a bit of Googling, despite the exensive explanations in the posts.
This used to be a blog about random experiments Marek was doing, like this post on bitsliced SipHash
. Since Marek joined Cloudflare, this has turned into a list of things Marek has learned while working in Cloudflare’s networking stack, like this story about debugging slow downloads
Posts tend to be relatively short, but with enough technical specifics that they’re not light reads.
The selection of topics is eclectic, and explained at a level of detail such that you’ll come away with a solid understanding of the topic. The explanations are usually fine grained enough that it’s hard to miss what’s going on, even if you’re a beginner programmer.
Posts tend to involve lots of Java code, but the takeaways are often language agnostic.
Adventures in signal processing. Everything from deblurring barcodes
to figuring out what those signals from helicopters mean
. If I’d known that signals and systems could be this interesting, I would have paid more attention in class.
Posts are usualy relatively long and self-contained explanations of technical ideas with very little fluff.
Years of debugging stories
from a long-time SRE, along with strories about big company nonsense
. The stories often have details that make them sound like they come from Google, but anyone who’s worked at Microsoft, IBM, Oracle, or another large company will find them familiar.
This reminds me a bit ofGoogle’s SRE book, except that the content is ordered chronologically instead of by topic, and it’s conveyed through personal stories rather than impersonal case studies.
Posts tend to have a fair bit of detail, down to diagrams explaining parts of circuits, but the posts aren’t as detailed as specs. But there are usually links to resources that will teach you enough to reproduce the project, if you want.
This is one of the few programming blogs where I regularly go back and re-read posts from the archive. I learn something new every time. Posts span the entire stack, from how individual programmers can improve at programming
to how orgs can improve at recruiting
. I re-read that last post before posting the link here and this bit jumped out:
Well, in case you hadn’t noticed, they’re kicking our butts at recruiting. Even in our own backyard. Professor Ed Lazowska at the University of Washington told us last year that Google’s getting about 3 times as many UW hires as we are. A candidate at last week’s recruiting trip told me that of the nine or ten students he considered to be the best programmers at the UW, about half of them went to Google; only two went to Amazon, and the rest went to “no-name” places.
Actually, his story had one more interesting tidbit: he said that although Microsoft is considered one of the top three places to work by the UW CS students (along with Google and Amazon), he claims that Microsoft is hiring lots of mediocre programmers. He said they gave offers to a whole bunch of programmers who he knows aren’t any good — and this guy was my strongest interviewee of the trip, so I was inclined to trust his judgement. He said that in his eyes, this disqualified Microsoft as a potential employer.
That’s not to say we don’t lose candidates to Microsoft. We do! Microsoft has determined that Amazon is very good at talent assessment, but crappy at selling the candidates and clinching the deal. So when Microsoft hears from a candidate that they’ve got a full-time offer from us, Microsoft doesn’t even interview the person. They take the candidate for a ride in the company hummer, have execs wine and dine them, let them spend the day with the team they’re going to join, show them the private office with a door they’ll get so they can concentrate on innovation… it’s a straight sell job after we’ve made an offer.
This is exactly what happened to me with Microsoft – I had a number of offers from other companies (though not Amazon), and someone from Microsoft called me up and sold me on Microsoft. I technically had an interview, but the interview was basically a sales job. Basically every time I re-read a Steve Yegge post, I notice that the post reflects some recent experience of mine.
Even when there’s code, the posts tend to be about a high-level idea that just happens to be illustrated by the code, which makes this a lighter read than you’d expect from sheer amount of code.
As far as I know, Rebecca doesn’t have a programming blog, but if you look at her apparently off-the-cuff comments on other people’s posts as a blog, it’s one of the best written programming blogs out there. She used to be prolific onPiaw’s Buzz (and probably elsewhere, although I don’t know where), and you occasionally see comments elsewhere, like on this Steve Yegge blog post about brilliant engineers
. I wish I could write like that.
This isn’t updated anymore, but I find the archives to be fun reading for insight into what people were thinking about microprocessors and computer architecture
over the past two decades. It can be a bit depressing to see that the same benchmarking contreversies we had 15 years ago
are being repeated today, sometimes with the same players
. If anything, I’d say that the average benchmark you see passed around today
is worse than what you would have seen 15 years ago, even though the industry as a whole has learned a lot about benchmarking since then.
on how V8 works and how various constructs get optimized
by a compiler dev on the V8 team. If I knew compilers were this interesting, I would have taken a compilers class back when I was in college.
Often takes topics that are considered hard and explains them in a way that makes them seem easy. Lots of diagrams, where appropriate, and detailed exposition on all the tricky bits.
Mostly dormant since the author started doing art
, but the archives have a lot of great content about hardware, low-level software, and general programming-related topics that aren’t strictly programming.
90% of the time, when I get the desire to write a post about a common misconception software folks have about hardware, Yossi has already written the post
and taken a lot of flak for it
so I don’t have to :-).
I also really like Yossi’s career advice, like this response to Patrick McKenzie
and this post on how managers get what they want and not what they ask for
Note that this list is relatively tilted towards blogs I find to be underrated. So it doesn’t include, for example, the high scalability blog, mechanical sympathy, or Patrick McKenzie even though I think they’re great. You might say that it’s strange that I have folks like Steve Yegge and Kyle Kingsbury listed. What I can say? I still consider them underrated. This list also doesn’t include blogs that mostly aren’t about programming, so it doesn’t include, for example, Ben Kuhn’s excellent blog
Anyway, that’s all for now, but this list is pretty much off the top of my head, so I’ll add more as more blogs come to mind. I’ll also keep this list updated with what I’m reading as I find new blogs. Please please please suggest other blogs I might like
, and don’t assume that I already know about a blog because it’s popular. Just for example, I had no idea who either Jeff Atwood or Zed Shaw were until a few years ago, and were and still are probably two of the most well known programming bloggers in existence. Even with centralized link aggregators like HN and reddit, blog discovery has become haphazard and random with the decline of blogging as conversation and blogrolls.
This post was inspired by the two posts Julia Evans has on blogs she reads and by the Chicago undergraduate mathematics bilbiography
, which I’ve found to be the most useful set of book reviews I’ve ever encoutered.