Infinite Jest and fanatics

Infinite Jest on patriotism, fanatics, love, attachments, and temples:

‘Your U.S.A. word for fanatic, “fanatic,” do they teach you it comes from the Latin for “temple”? It is meaning, literally, “worshipper at the temple.”‘

I found this passage striking as well. On the one hand, Wallace writes great dialog. Even when most of the dialog is a monologue with ignored interjections by the other character. On the other hand, some great etymology and word-play here.

And then there’s the point: choose your core philosophies carefully. Is it really worthwhile to identify yourself as a Rails person, a libertarian, or a connoisseur of fart jokes?

Side note: I’m doing this whole Infinite Summer thing because, at my core, I enjoy the challenge of reading books that are just too long. This is very borderline hipster, so I promise never to refer to David Foster Wallace by his initials, because that’s just confusing when you live in Dallas.


Freakonomics. Its not about economics in the dry, dismal sense that I remember from college. This is more about counterintuitive turns of logic, data showing causations that no one really supposed made sense. In the end, its about economics in the sense that real estate agents, sumo wrestlers and criminals respond to financial, social and lifestyle incentives.

Oh, and the book features twenty misspellings of the name “Jasmine”, a bit on two brothers named Winner and Loser, and a person named Shithead. Predictably, the last was my favorite.

Guns, Germs and Steel

_Guns, Germs and Steel_ is one of those essential books that makes more sense of the world. Specifically, it address in rational terms, how it came to be that the modern world is arranged as it is where it concerns the haves and have-nots on the global scale.

The author, Jared Diamond, does so by taking an extremely long view on history, over the course of the last ten thousand plus years). From there he tries to build models and theories that predict why some societies advanced faster than others. To make a long story short, the societies that have become the contemporary first world were able to:

* Move knowledge and technology on an east-west axis, an axis that allows easy migration and translation of farming knowledge because the climate is roughly the same
* Develop immunity to epidemic diseases like small-pox that are tied to living near agriculture, thus making them less likely to get killed off by certain foreign invaders or to kill off natives as they travel to foreign lands
* Organize people into ever-large structures that can sustain invasions, research and other useful forms of specialization

Of course there’s more to it than that. It’s a great read and illuminates all sorts of topics I’d never even thought of, let alone correlated. If you, like me, seek a greater understanding of the abstracts that define the world, this is a book for you.

Domain Driven Design

Designing software is a tricky thing. It’s tempting to front-load it on a project. That won’t work because the start of a project is when you know the least about it. So some folks try to do as little design as possible. I’m guilty of this. However, that can lead to software that doesn’t adequately express the problem it’s trying to solve. Further, there is often a temptation to over-design software with lots of ceremony and architecture. Contrary to this is the temptation to not design it at all, which again leads to software that doesn’t express itself.

There’s a book that draws a reasonable compromise between these forces. I’ve been meaning to read Eric Evans’ _Domain Driven Design_ for a while now. The emphasis of the book is in collaborating with domain experts and other developers to find the essence of the problem space and then express that in software (as objects). I’ve often pointed out the utility of building applications from the language up and the problem domain down. DDD focuses precisely on the latter.

One of the core concepts in the book is the _ubiquitous language_ that is used to describe the problem at hand. This language is used by the domain experts (customers) *and* the developers. The language is then woven into the design of the system. This leads to software that is more likely to succeed, both in business terms and in terms of development effort. Evans spends the first part of the book describing the particulars of this language.

He then moves on to describing the technical side of the software. Entities, value objects, services, factories, modules and repositories are terms I was already somewhat familiar with that Evans gave a more crisp and satisfying definition to. For most people, this is probably the tasty meat of the book, illuminating the way from a competent developer to an outstanding developer.

The last part of the book focuses on the larger scale issues of deep design. I was particularly pleased that he covers how software design is affected by various good and bad social issues. It also gives a strategic view of the forest, where most books on software development focus on a more tactical view of each tree.

I’m fond of pointing out books that are inflection points in my way of thinking about software development. Code Complete, The Pragmatic Programmer, The Dragon Book and My Job Went To India all fall under this category. Domain Driven Design is certainly the latest edition. It makes sense of trends I see in great software and illuminates a path to make software like it myself.

If reading this review didn’t make you want to vomit, you should probably read the book posthaste.