Guns, Germs, and Steel

All I could think about while reading this book is that a much more appropriate title would be “Plants, Animals, and Geography.” Alas, I bet the publisher would have vetoed such a bland choice. In the end, those are the three key factors that influenced the long term success of every civilization on the planet. Ultimately, yes, guns, germs, and steel allowed one civilization to “engulf” another but the reason the dominant civilization had guns, germs, and steel in the first place was due to prehistoric luck. It found itself with plants that were amenable to farming, animals amenable to domestication and geography that enabled the extension and expansion of the young civilization when it was ready.

History unfolded the way it did, paraphrasing Einstein, not because any one civilization has (or had) smarter people than the others. But rather, the aforementioned plants, animals, and geography, provided a sort of head start to the civilizations that, in hindsight, appear “better” and they were able to spend more time working on the problems, challenges and technologies that ultimately developed into guns, germs, and steel. This is a reassuring conclusion. It means that if we could teleport prehistoric hunter-gatherers from one region to another we would still find that a civilization based in Europe ultimately engulfs much of the world. And more importantly, this conclusion renders racism that proclaims the superiority of one genetic group over another baseless.

Following the high-level but thorough analysis of how the modern world came to be, Diamond couches his conclusions a bit. He recognizes that there are some notable outliers that don’t fit the pattern he describes. China, in particular, which stepped backwards from its position as technology leader suggests that plants, animals, and geography were only a starting point. There were and still are a multitude of factors that impact the longterm success of a civilization.

After spending quite a bit of time on this book (it’s dense, dry and long) I’m left wondering about the utility of this knowledge. The author’s conclusions about racism are heartening and the discussion of technology/idea diffusion seems relevant to the distribution of information in large organizations—something he talks about a bit in his second edition follow-up. Something to ponder…

(Amazon.com)

Cutting for Stone

First book in a while that I didn’t enjoy and left me with negative feelings. Things did not go well from the very beginning: the story could have easily proceeded without the interminable first 120 pages—nothing happens that we don’t already know about. And I while I grant that it is a book centered on the lives of surgeons (something I did not know when it was recommended to me), some of the surgery scenes veer from detailed descriptions to unnecessary gore. I also never felt particularly good about the protagonist: he is portrayed often as weak, or at least always uncertain, and yet this same person is strong enough to flee a war-torn country and put himself through medical school. It just didn’t add up. In the end, I feel like the author started with the idea of the story’s climactic scene (no spoilers!) and then wrote the narrative in reverse to fit that unique sequence. Maybe that’s what all authors do, but here it felt obvious. Do not recommend.

(Amazon.com)

The Early History Of Smalltalk

Reading about the invention of object oriented programming feels a bit like reading about the invention of the wheel. Not that I’ve read anything about the invention of the wheel, but of course that’s because I take the wheel for granted. I guess OOP sometimes feels like the programming equivalent of the wheel: I suppose I’ve also taken object oriented programming for granted. To be reminded of the fact that someone had to sit down and develop the kernel of that idea and see it through into useable system was refreshing and a little frightening. 

An engineering education requires reading a huge amount of technical literature but very little of what’s read is a first-person historical narrative and that made reading Alan Kay’s account of Smalltalk’s development particularly engaging. A strange byproduct of the technology industry’s rapid pace of advancement is that we rarely have time or inclination to read historical technical documents. We never seem to devote time to the process of how the technologies we use were developed. 

(Github)

Getting Real

Getting Real is a bit of a classic in the software startup world and as a quick read, it was useful and encouraging. Useful in that the 37signals crew provide numerous specific recommendations for how to build software quickly and in a way that results in a high quality product. The encouraging elements were those recommendations that we’ve already been pursuing on projects at work. That said, while I enjoyed the to-the-point style of the writing, overall I felt that many of the book’s key messages were spoiled by contradictions.

On the one hand they advocate for diving right in to building your product and not to bother with a specification because, “Functional specs are just words on paper,” but then explain how you should start with pen and paper mockups for your design because, “A paper sketch is cheap and easy to change.” Well, a sketch is just lines on paper, so what makes that okay but not a spec? The value of both tools is that they’re cheap and easy to change (unlike the code that will eventually get written to fulfill them).

The other big contradiction is the 37signals quest for simplicity. They recommend keeping products minimal in the interest of code simplicity, but this is the company that built and open-sourced an entire web-development framework from scratch using a relatively obscure language. The complexity of that development has paid off, but that seems like a risky bet for a majority of developers. Surely, working within the limitations of an existing framework would be simpler than trying to build one from the ground up. Of course, someone has to push the limits of what’s available otherwise there’s no progress.

Ultimately, I think the book could be a bit more balanced rather than promoting so many absolutes—some of which are contradictory. Alas, the confidence of “do it this way” is a lot sexier than “you might find success with this method that we used.”

(Free PDF!)

The continued lack of UI for stopping snoozed alarms in iOS

Almost a year ago, I tweeted:

There are plenty of great new features in iOS 5, but there’s still no way to tell if an alarm is currently snoozed.

Well, here we are with freshly launched iOS 6 and there’s still no mechanism for (1) determining if an alarm is currently snoozed (2) stopping that alarm mid snooze without turning it completely off. Surely I am not the only person who snoozes their alarm several times in the morning and sometimes gets up in the middle of snooze period (a period which is not user configurable, but that’s a whole separate complaint).

The reason that this is an issue at all is that my weekday alarm repeats, but if I want to prevent it from going off again after snoozing I have to completely disable it. This strikes me as a dangerous: I might accidentally leave it turned off and not have an alarm the following morning.

 

Here’s the easy solution: when an alarm is snoozed, increment the badge count on the Clock app, making it clear that there’s something in the app that needs the user’s attention. If the same alarm fires again and is subsequently snoozed, the badge count stays the same: there’s still only one alarm that needs attention. Finally, for alarms that are currently snoozed, add a “Reset” button that clears the current snooze without disabling the alarm completely.

And now I’ve set my personal record for most uses of the word “snooze” in single document.

The Idea Factory

I wish this book had been available to read at the start of my electrical engineering degree. The laws, theorems, and inventions that I read about in engineering textbooks are central to The Idea Factory, but not as concepts. Rather, Jon Gertner explores the stories of the people who created these concepts, where they came from, what they were like, and how they worked. In class, these concepts were obviously related by their field of applicability, but I never understood that virtually all of the individuals who shaped the modern electrical engineering discipline worked under one roof at Bell Labs. Noyce, Shannon, Shockley—the book fills in the human story of how they arrived at Bell Labs and changed the world.

And the work done by engineers and scientists at Bell Labs is truly staggering. It feels like nearly every piece of modern communication equipment has its roots at Bell Labs. I had no idea that it was the crucible of innovation that it was. And despite the many inventions described, having done further research on my own, the author makes some significant omissions: most notably the development of the the C programming language and the UNIX operating system—both products of Bell Labs that earn only the briefest recognition in the book.

The overall point of the book (in addition to being a detailed, if not complete, history of Bell Labs) is to ask, “Can this type of innovation be repeated?” Gertner makes a compelling argument that, no, our current corporate paradigm makes the Bell Labs model impossible to implement today. AT&T had a government-sanctioned monopoly that allowed and enabled levels of predictable profitability that no company possesses today. That predictable stream of funding enabled scientists and engineers at the lab to pursue problems that they knew were unlikely to payoff in less than 10 years. And in fact, some of the problems they tackled did not become actual products for more than 20 years after the initial concept.

I was all set to leave the discussion there: projects at that time scale are just unheard of today… But then I thought about Google. It’s too soon to say that Google’s apparent culture of innovation will ever approach the historical significance of the work at Bell Labs, but at least two of their projects suggest that Google is straying from the corporate pack. The self-driving cars and Google Glass both are inventions without markets. In both cases the world seems not quite ready for their introduction much like some of the technologies discussed in The Idea Factory. Both cellular phones and satellite communications were envisioned well before they could be practically turned into profitable businesses. It took many more years for accompanying technologies and markets to mature before they could be sold and take their places in history as innovations. We’ll have to wait and see if Google’s work can achieve similar levels of greatness. I hope it does.

(Amazon.com)

The Commute: the train is faster, but it’s not as fun.