Skip to content

Home

  • 1 min read

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)

  • 1 min read

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)

  • 2 min read

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!)

  • 2 min read

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.

Press the snooze button...

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.

  • 2 min read

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)

  • 1 min read

This is the state of our

> “This is the state of our military-industrial-scientific complex in miniature: The military has so much money that it has two extra telescopes better than anything civilians have; meanwhile, NASA will need eight years to find enough change in the couches at Cape Canaveral to turn these gifts into something they can use.”
— [Alexis Madrigal for the Atlantic](http://www.theatlantic.com/technology/archive/12/06/hey-brother-can-you-spare-a-hubble-dod-sure-have-two/258061/ "Hey, Brother, Can You Spare a Hubble?")
  • 1 min read

UI Consistency Fail

This has been bugging me for a while and I finally had a chance to record this strangely inconsistent behavior from our washer/dryer set. The preset modes for the washing machine can be adjusted as you see fit, but for no apparent reason, the same modes on the dryer can’t be modified. You have to select a “manual” mode before you can change the drying parameters.

Makes perfect sense!

  • 2 min read

Fixing the Game

As someone who spends an inordinate amount of time reading blog posts and news articles from technology analysts, I am already somewhat biased against analysts in the first place. At some point after reading for the nth time about how Company X is running their business into the ground, only to see Company X itself report significant profits, you realize that analysts don’t have any more information than you do. They’re using the exact same publicly reported press releases, blog posts, and financial results that everyone else has access to and presenting their opinion as fact. So what does this have to do with Fixing The Game?

It turns out that an enormous segment of our economy is directly influenced by the whimsy of analysts and how the CEOs of modern corporations meet or miss those analysts’ expectations. Roger Martin makes an extremely apt comparison with the NFL and explains how ridiculous it would be to let sports analysts determine the value of a team rather than letting the actual numbers stand for themselves. In corporate America, our value system has become so twisted that corporations’ successes are measured only in comparison to analysts’ expectations. And of course, with executive compensation being tied more and more closely to the performance of a company’s stock, executives have begun gaming the system. They produce short-term  stock gains to boost the value of their compensation with a complete disregard for the long-term.

The book takes a refreshing look at how companies should deliver value to shareholders, arguing convincingly that the paradigm of shareholder value maximization is broken. And instead of just pointing out all of the problems with the system, the author makes clear and easy to understand recommendations that would make the system better. Definitely worth reading.

(Amazon.com)