Show
Pahlka has been a guest on The Ezra Klein Show multiple times and has some refreshingly original takes on the problems of modern governance, particularly with regards to digital infrastructure. This book is a fascinating and sometimes infuriating look into the misaligned institutional incentives that have led to the creation of ineffective and out-dated digital infrastructure. Pahlka was a member of the task force assigned to untangle California's floundering unemployment insurance systems during COVID, so she brings a lot of personal experience to this book.
The tragedy of it all is that, from Pahlka's perspective, the flaws of these systems are apparent to everyone, policymakers, software developers, agency staff, and the consumers who use them, but no one involved is permitted to make meaningful change. The processes and regulations that government agencies must abide by suffer from a lack overarching design, and instead accrete over decades of marginal "improvements" because substantive change is too expensive and too politically fraught.
I'm sure that Pahlka arrives at a hopeful prognosis and recommendations to get there by the end of the book, but so far it has been a bit dreary.
A long time ago, while I was in middle school, I wrote some very simple games in a dialect of BASIC that included some rudimentary, rule-based AI opponents. A desire to get back into game development, not to mention social science applications in politics, business, and other areas, drew me to seek out an introduction into the formal, mathematical side of game theory.
So far, I have written a couple of simulations wherein a dozen predetermined strategies compete against one another in a simple card game, and I can imagine how the same basic principles could be extended to other "games".
While this edition was published in 1989, the original was published in 1957. This was, apparently, a very active period of research in the field, and the book preserves a lot of the optimism and disappointment about how game theory could and could not be applied to the social sciences and perhaps even diffuse Cold War tensions.
This is an introductory book on the branch of mathematics known as category theory, which has been described as the "mathematics of mathematics".
Category theory forms an important theoretical basis for functional programming, including concepts like functors and monads, and that was what drew me to this book as an accessible introduction.
Two videos by Oliver Lugg piqued my interest and lured me to this book: 27 Unhelpful Facts About Category Theory and the slightly more serious A Sensible Introduction to Category Theory
A very fun book on emerging technologies. It keeps a light and comedic tone (including a lot of cartoons) while also providing rather satisfying explanations of the problems and potential solutions for technologies like fusion power and space elevators.
The architecture-focused companion to the classic Clean Code. It's fine overall, but seems a bit shallow. It also seems to be overly biased toward OOP principles, and it's clear that the author felt obliged to include cursory mentions of functional programming. It may have been better to own the OOP focus.
I found Fundamentals of Software Architecture, which I read several years ago, to be a much better introduction to software architecture.
I found this while on a visit to Berkeley, California. I suspected that Berkeley's proximity to the Bay Area and its important role in the history of computing might be conducive to some rare finds at the secondhand bookstore, and I was not disappointed.
Since reading Homage to Catalonia as a teenager, I've always felt like George Orwell deserves more credit for his other works beyond 1984 and Animal Farm. This one, however, was admittedly not my favorite.
The title, for the curious, is a reference to a house plant popular in Britain at the time. It was seen as emblematic of middle class respectability, which the protagonist of the novel ultimately comes to embrace after failing to make it as a "starving artist".
Lem is a classic sci-fi author that is relatively unknown (to Americans at least) as a result of writing his books on the other side of the Iron Curtain.
This was an excellent book that seemed both far ahead of its time and laughably stuck in it. The main premise is that the crew of a spaceship discover that a seemingly desert planet is in fact inhabited by lifeforms resembling plants and swarming insects that have evolved over millions of years from self-replicating robots introduced to the planet by some long-gone alien civilization.
On the other hand, Lem at one point describes rolled paper maps rattling in their tubes as a rocket takes off. While he could imagine a drastically different trajectory for the evolution of life, he still couldn't imagine interstellar travel without paper maps.
While staying in Romania for a "visa break" from Germany, I had the bright idea to practice two languages at once by studying Romanian via German.
It went poorly.
I found that, even though I consciously understood the lessons and vocabulary and was able to read grammatical explanations without too much trouble, the information did not cement itself in my memory nearly as well as studying via English.
An interesting experiment in the psychology of language acquisition, I suppose.
I picked this more or less at random from Spotify's audiobook offerings and have been hooked ever since.
The world-building is very rich, with a nearish-future solar system populated by distinct cultures and political factions. One of the authors (the "author" is actually a pen name for a pair of writers) was a long-time assistant to George R.R. Martin, and the plot has similarly engrossing, episodic structure to that of the Game of Thrones series.
I've since watched the TV series as well, which, aside from a low-budget first season, is also excellent.
I picked this up on a visit to Munich as a way to practice my German. I read it in English years ago and remembered it being short and with simple language. Still as good as I remembered it, even if it took me twice as long to read.
I knew that Stephenson had a reputation for eclecticism, but I had no idea how wacky this novel would be, and I've barely even gotten into the Sumerian mythology. The genre is cyberpunk, and the setting is mostly near-future (or at this point, retro-futuristic), but the tone is predominantly absurd, comedic, and satirical.
Overall, this book has been a lot of fun, and is a fun glimpse into expectations of technology in the early 90s.
So far I've found this book a bit disappointing. What I expected was techniques for developers to make growing and changing a system safer and easier. Instead, the perspective is very detached and top-down. The target audience of this book is people-managers at big companies who bear the title of "architect" and who hardly ever write any code. Nothing wrong with that, but I certainly don't fit into that category.
I think this books depends on an artificial divide between design and implementation (something Evans brings up in Domain-Driven Design), and I'm skeptical that that divide is helpful.
This is a new Stack Exchange, still in a trial period, and so far I've been pleasantly suprised to see a lot of engagement!
Programming language design has always been an area of interest to me. In the workplace, language choice is often a foregone conclusion (perhaps especially in web dev, where JS is unavoidable), so it's refreshing to see some very knowledgeable people discussing the various design choices that go into languages both familiar and obscure.
Link to the forum here
I recently took a trip to Juneau, Alaska, and encountered this book at the Sealaska Heritage Institute's gift shop.
Tlingit is an endangered language spoken in the Alaskan panhandle by only around 50 speakers. It's a distant relative of Navajo, spoken in the American southwest, and languages of that family are famous for the complexity of their verbal morphology. While the book is designed mostly as a textbook for heritage speakers (perhaps high-schoolers and college students), it does occasionally delve into the verbal morphology, and the phonology has been interesting to learn about as well.
Scott is a popular author in the world of anthropology, so I was already primed to be interested when I kept hearing this title mentioned in podcasts. It has lived up to its reputation.
In a nutshell, the main argument is that when we flatten the complexity of the real world into simplified models in order to better control it, we sometimes end up enforcing that model upon the world, often to our detriment. While the prototypical culprit of this pattern is government, Scott emphasizes that the same could be said about companies or other actors.
I think there are parallels in software developement, since that also relies on modeling real-world systems.
Reading Domain-Driven Design, I noticed that it bore certain assumptions that were true in 2003 but not today. Namely, that any serious software development is object-oriented, and that you are almost certainly doing it in Java or maybe C++.
I sought this book out to hear the core concepts of domain-driven design reformulated in functional terms, and the first 30% of the book was exactly that. I've encountered videos and articles by this author before, however, and sooner or later he always turns the topic into an advertisement for F#. It seems like a lovely language but I would prefer if he would keep the principles more general.
Recently I've been interested in how the architecture of a project affects its long-term growth. With my own projects (especially my Language Workshop project), but to a lesser extent even professional projects I've worked on, I notice that the natural trajectory for any project is to become more complex and less comprehensible, and the gradual drift of the implementation away from the domain that it models adds more and more cognitive load in translating requirements from one to the other.
It seems that domain-driven design offers a potential solution. By consciously keeping the system tightly coupled to the domain, you can mitigate the difficulty of working on mature projects.
A quote from the book that I particularly liked:
Manufacturing is a popular metaphor for software development. One inference from this metaphor: highly skilled engineeers design; less skilled laborers assemble the products. This metaphor has messed up a lot of projects for one simple reason—software development is all design.
I sometimes use Docker Compose when developing multiple interacting services, just because it keeps things simple. All the ports are in one YAML file, and Docker hooks them all up for me, recompiling when necessary, and in the order that I specify.
My interest in Terraform was similar, though more theoretical than practical. Books about Dev Ops, strangely, tend to be aimed at a non-technical audience, and as a result the practical lessons have to be sifted out of a lot of fluff. But reading about Terraform, you can get all the relevant aspects of managing complicated infrastructure distilled into a concise interface.
Since I was mostly using it as a window into the world of Dev Ops, I didn't really absorb much practical information about Terraform, but I have a much better sense of what it does, along with similar tools like Ansible.
This was a really fun book. It explores a lot of unusual programming languages, which Kneusel groups into atypical languages like SNOBOL, which are practical languages that work according to very different ideas of what a programming language even is, and esoteric languages like BF, which aren't meant to be useful, but instead are some sort of experiment or parody.
The vast majority of programming in real-world projects is firmly in the ALGOL- or C-family of languages, so seeing the languages described in this book really makes you wonder how things could be different. What common but difficult tasks in C-family languages might be trivial in another language? Do our usual languages give us blind spots in our thought processes and problem solving?