My initial reaction, like Caterina’s, was to assume there is something wrong in the Gravatar model. Why should somebody be able to masquerade as me simply by guessing the email address I associated with Gravatar? But Matt Mullenweg of Automattic, which owns Gravatar, explained concisely that the fundamental problem of impersonation cannot be prevented by their service. An impersonator could just as easily have associated a new email, “fakecaterina@example.com” with Gravatar, and uploaded a copy of her avatar.

A Hopeless Situation?

I am convinced by Matt’s claim that Gravatar is not in a position to prevent impersonation. However, it’s possible to imagine ways in which Gravatar could promote authenticity. Gravatar already allows me to create an account through which I claim email addresses and can control which avatars should appear for these addresses. In addition, it allows me to confirm that account’s association with certain services such as Blogger.com, Facebook, Twitter, etc. This, combined with the fact that use of Gravatar is already widespread on the web, makes it a great candidate for serving as an arbiter of trust in arbitrary contexts on the web.

Web sites that make use of Gravatar’s services are currently able to fetch an image associated with a particular email address, by manipulating (hashing) the user’s email address in such a way that the email address is no longer discernable, but Gravatar can easily look up the associated avatar image.

There are steps that Gravatar could take to make possible the “authentication” of specific Gravatar appearances on the web. It would be exhausting to elaborate on the variety of ways this might be done, and many of the options that spring to mind also bring to mind many pitfalls and annoyances, not to mention significant service demands on Gravatar. Maybe the authentication would require hosting sites to present authentication keys, or maybe users would just whitelist particular comment URLs. Let’s not get bogged down in details: the details are for companies like Gravatar to take on if they choose to meet the challenge.

In a world where Gravatar offered some form of per-use authentication, a site like GigaOm could show a trust icon next to commenters’ avatars, or maybe it would be integrated into the avatar as a form check-mark badge or something. Click on the trust icon and it might take you to a Gravatar page where a curious reader could gauge authenticity with Gravatar’s help:

The Gravatar being shown at <link to e.g. a comment url> was verified by Daniel Jalkut, a registered Gravatar user. Daniel is known to be associated with Twitter ID “danielpunkass”, and controls the web site domain http://www.red-sweater.com. For more information, view his profile here.

The current Gravatar user profiles already lean strongly towards identity confirmation. Some clever techniques for authenticating comments would not eliminate impersonation, but would allow identity-concerned users such as Caterina a means of participating in web conversations while proactively confirming their own identities.

Long time readers of this blog will note that I’ve had my dry periods as well. But watch closely: I’m blogging now about a thought I had just earlier this evening, while reading Twitter updates and responding to them. Colin Barrett complained that his perfectionism is limiting his blogging:

I plan to write more; I think my @secondconf talk on freelancing would work well as a series of posts. Just gotta get past my perfectionism.

I’m incredibly familiar with this line of thinking. In fact, it’s a variant of the indefinitely postponed software releases that I just wrote about. I read Colin’s tweet and, before I had even noticed that the neurons in my brain were firing, I had responded with a bit of encouragement:

@cbarrett The modern business model for solo writing is to blog your first draft and sell your final.

I’m referring to the fact that very few blogs are edited to the level of professionalism you might find in literary or scientific journals. On the contrary, some of the web’s most celebrated bloggers have let their essays loose in a semi-rambling form, only to piece them together later into a more refined, salable volume. Rands in Repose and Joel on Software spring to mind in the techie world, while writers such as Heather Armstrong and Julie Powell turned their respective parenting and cooking blogs into million-dollar enterprises.

The ever-so-thinly veiled message? Don’t worry so much. Just blog it. If you are among the lucky few who achieves perfection effortlessly, then by all means carry forth. The rest of us are lucky if we coerce a unit of coherent thinking out our brains and onto the web. Perfectionism? Your editor will help you achieve it after you’re famous.

I was lucky to join one of the most cavalier and competent teams in the company: the Mac OS system integration team. In a nutshell, we were in charge of the Mac OS System File, “System Enabler,” and other crucial bits that made your Mac a Mac. Whoo-hoo! Power! We made or broke your Mac experience, hopefully making more than breaking. I took my new job seriously and stepped carefully with every change. It felt great, and I cherished every contribution I made.

Later, I moved to the Mac OS X team and did similar work on the infrastructure of Mac OS X. In particular, with how it deals with older applications that rely on the “Carbon” framework. After years of using a custom Mac-only environment called MPW, I was using standard UNIX tools and building UNIX libraries. This felt awesome! I had grown up using an Amiga, then switched to Sun OS, where I spent a lot of time getting familiar with UNIX. There I was, and Apple decides to put the best UI in the world on top of Unix. I was in heaven.

While I was at Apple I saw a lot of failure. I saw the Newton fail. I saw Pippin fail. I saw PowerTalk fail. I saw Cyberdog fail. I saw Apple desperate to sell even a few hundred thousand Macs in a quarter. I saw the press lambast us and declare us dead. “Beleaguered” became an unfortunately common word in our office life.

But I kept looking around me, and I saw nothing but signs of success. I marveled at QuickTime, speech recognition, networking technologies like ZeroConf (Bonjour), and other things that have never seen the light of day. This company is awesome! I want to work here! They’re going to change the world!

Of course, they already had changed the world with the Apple II and the Macintosh, but as a young 20 year old, I was anticipating future growth. It was a bad time for Apple: competitors and the press were declaring our obsolescence. Michael Dell said we should give the money back to the shareholders and close the company. We persisted on a wing and a prayer, driven by Steve Jobs’s admonition that we could beat Dell. I believed in that mission, and I believe in it still.

In 2005, I wrote boldly about the end of Dell, and I have to confess I was a little over-ambitious. I could see a path where Apple would take Dell down faster than they have. I was wrong. Dell is still a strong  company. But that will change soon.

I joined Apple because they were threatening to change the world. I stayed on at Apple because they were changing the world. And I remain loyal to that company because, in spite of my absence, they have changed the world. In more ways than I can imagine, they’re inventing the future. And I’m along for the ride.

Dell is not changing the world, Microsoft is not changing the world. Hewlett-Packard is not changing the world.

Apple is changing the world, and damn it feels good to be part-Apple today.

• Mac developers are perfectionists.
• Mac developers are community-oriented.
• Mac developers are not obsessed with the bottom line.
• Mac developers are passionate.

But admit it: these characteristics are common to developers on all platforms. So why do Mac developers consistently produce the most refined, friendly, user-empowering, beautiful software on the planet? (My opinion only! You’re welcome to yours). I believe that excellence is achieved by these passionate, community-oriented perfectionists who are not obsessed with the bottom line, and that the Mac ecosystem supports these four characteristics in a more balanced manner than any other platform.

The Four Characteristics

How do these characteristics help to propel a developer towards success? What does it mean to exude these qualities, and how do they concretely impact one’s ability to produce excellent software?

Perfectionism is commonly considered to be a fault, and in excess it can certainly be one. For the purposes of this discussion I consider perfectionism to describe the quality in a developer that drives her to always go “one step further” with the elegance of a solution. One step further than what? Than an average peer would expect of her. By consistently exceeding expectations, even by a small amount, a software perfectionist goes a long way towards producing those “this is freaking amazing!” reactions among users, and helps to raise the expectations bar among peers ever higher.

Community-orientation describes the extent to which developers choose not to work inside a vacuum. A platform whose developers share ideas, code, criticism, and praise over social networking technologies, mailing lists, and blogs like this, is a stronger community. Each participant gains access to a percentage of the other members’ experience and equipment, producing a multiplier effect on productivity and the consensus standard of excellence.

A developer who is not obsessed with the bottom line clings to a non-monetary motivation as the primary reason for his work. Whether that motivation is to create software that is beautiful in appearance, smaller in code size, or more shareable among community members, the lack of financial obsession will permit him to travel further down that path than he otherwise would. Developers who are obsessed with the bottom line understand that in identifying and filling a specific need among users, they reap the maximum return on their development investment, without wasting resources on frivolous refinements.

Given the obsession with financial return by society at large, a developer who chooses perfectionism, community, and the pursuit of excellence for its own sake would be judged a fool by many. Prioritization of these values over cold hard hash is such an uphill battle in society, that only a person who is incredibly passionate about what they do is likely to overcome the forces that fight against it. Passion drives individual developers to continue bucking the trend, and to carry on relentlessly towards the idealistic goals of the community as a whole.

Bringing It All Together

To reiterate my point: I believe that the Mac platform rewards for these characteristics in a more balanced manner than any other platform. Which is not to say that Mac developers have the “best” of these characteristics. On the contrary, we have lucked into a scenario where we have the most pragmatic proportions of each, which sometimes means more, and sometimes means less.

Now we come to the part of the article where I offend everybody, by offering my painfully stereotypical views of the three major platforms: Linux, Windows, and Mac OS X. Look, I realize I’m generalizing, but try to find the kernel of truth in what I’m offering. Sure, I’m talking out of my ass, but maybe it has something interesting to say.

Take Linux, for example. Developers on this platform are undeniably passionate, community-oriented, and intensely unobsessed with the bottom line. But this is not enough to produce excellent software. Possibly because perfectionism (at least in user-facing interfaces) has never become a priority among Linux developers, their solutions are inevitably disappointing to those of us who have grown to appreciate the usability of the Mac. But their passionate rebuke of the bottom line has nonetheless allowed them to advance their priority for intensely shareable and well-optimized low-level code.

Windows developers are most likely to recognize a market opportunity and to run towards that goal, producing software that is imperfect but which meets the letter of user requirements. It’s uncommon for Windows users to celebrate a perfectionist nuance of some application, because applying those refinements takes valuable development time and doesn’t obviously advance towards the goal of a marketable product. Because this standard of excellence has been maintained at a relatively low level over the years, Windows users on the whole are not even aware that there exists a higher standard to be met.

So what makes the Mac so freaking special? We’re a small enough group that community cohesion is practically fulfilled by default. If you spend a few years in the Mac developer community, there’s a good chance you’ll meet everybody else who cares to meet everybody else. Because of this strong community bond, we have a situation where this mythical expectations bar is not only being constantly raised, but everybody in the community can see that it’s so, and encourages one another to push it still higher.

Because we are not obsessed with the bottom line, we can pursue our quaint preference for usability and beautiful design, without the constant fear of “missing an easy sell.” We restrict features for the good of the product, even when adding them might prove financially rewarding in the short term. But we are not unconscious of the financial implications of our products. We understand that in order to continue propelling ourselves down this path towards software Shangri-La, we need to earn enough money to keep our enterprises going. We embrace the techniques of earning money as a means to further the primary goal of producing excellent software.

Because the allure of the market has us constantly considering the financial rewards, it would be easy to lose track of our sights and become obsessed with the cash. But passion in the community has remained so strong, that we tend to remain fixated on excellence and pragmatically curious about the cash. Because the user base that has evolved over time on the Mac does acknowledge this excellence, we’re more likely to continue making a reasonable income even as we deprioritize that as the main goal.

Patting Ourselves On The Back

We feel so good about our lofty development ideals, that we spend a lot of time kicking back and reflecting on what a great job we’re doing. Some of us even write lengthy blog posts sycophantically congratulating ourselves on a collective “job well done.” Jerks.

In spite of our skillful self-adulation, we also appreciate and seek the opportunity to be rewarded with admiration from presumably unbiased groups. That is to say, we’re interested in awards.

In the Mac developer world the most prestigious awards are the Apple Design Award and the Macworld “Editor’s Choice Awards”, or Eddys. Outside of these two major commendations, there is little structured limelight for developers who are pursuing excellence. Understandably, it is a great honor to receive one of these awards, but given the relatively small number of developers who are recognized each year, most developers are unlikely to ever receive one.

Sensing the thirst for additional developer recognition, Michael McCracken proposes a community run version of the Apple Design Awards, where developers would themselves determine and dole out rewards for what we respect most among our peers. A major rationale is to remove Apple’s bias for applications that make most use of the technologies that Apple is pushing, and this seems like a laudable goal. Of course, Macworld’s Eddys are already fulfilling this to some extent, and the “Reader’s Choice Awards” that they also hand out do a good job of capturing the priorities of the customer base.

But what Michael is proposing would be something akin to what the Academy Awards provide to professionals in the film industry: the opportunity to judge and be judged for excellence by your peers. The people who really get what you’re trying to go for, and whether you’ve achieved it.

I think it’s an interesting idea, and I have to admit I take some comfort in the idea of receiving awards. I was lucky enough to win an Eddy award for MarsEdit a few years ago, and it was a major motivator and all-around good feeling. I respect people like Jason Fried of 37signals, who rejects the value of awards in the software and web industry. From the 37signals web site:

37signals does not enter award competitions. We believe that the self-congratulating awards “scene” encourages agencies to misplace their priorities on the opinions of their peers, rather than the needs of clients and their customers.

I can relate to this sentiment, and I have seen some developers have their priorities apparently hijacked by efforts to meet the criteria, for instance, of an Apple Design Award. I recall chatting with Manton Reece on Core Intuition (probably Episode 18: Who Will Be The Lead Singer) about the design awards, where I consoled myself about failing to win the coveted Apple award. I spoke of how gratifying it is simply to get positive feedback from customers in the form of friendly email notes, or yes, the welcome act of purchasing. These small but recurring motivational rewards, I dubbed the “Customer Design Awards.” It’s probably worth reminding ourselves that these are in fact the most important awards of all, but anything new that comes with a cute statue or plaque would still be welcomed!

It’s tempting to think that adding a feature like this is just about adding the functionality — but there’s a bunch more to it than that.

Here you see the gory, deliberate details that a responsible developer must consider when adding even what seems like an incredibly “easy feature.”

Without a doubt, the part of my job that slows me down the most is exactly this kind of consideration. I want to add a new feature, but not until I have evaluated how the feature best fits in the structure of the application as it exists today.

Sometimes even an “easy feature” requires massive overhaul of the application, so that it doesn’t feel tacked-on or cheaply done. If the feature is important enough, it’s worth practically rewriting your application, just to add something that looks like it must have taken all of 10 minutes to do.

I was (mostly) joking, but there’s a philosophical truth in there. All of us have lately learned, or been reminded, that there are no guarantees when it comes to investing money. At the core of most investments is the expectation that one day down the road, we’ll take back more dollars than we put in today. We’re disappointed at best and devastated at worst if we are forced to cash out with less money than we started with.

But many of life’s investments are risk free precisely because we don’t expect anything tangible in return. So be sure to spend at least some of your dollars and time on something more valuable and permanent than money. Education, artistic expression, good health, time with family & friends, travel, or pursuing your own particular favorite pastime.

All of these investments yield immediate, intangible returns that can’t be diminished at the whim of bankers, stockholders, or public policy makers. People who invest only for financial return wind up going mad with money lust. Losing their investments spells catastrophe. A pity they never took the time to write a novel or learn to play guitar.

In short, invest in yourself and you’ll always have plenty of you to value.

1. If you’re the slightest bit curious, buy Mark Dalrymple and Scott Knaster’s affordable book, Learn Objective-C on the Macintosh. It’s great that this book not only starts from the very beginning, but is available as an easy electronic download, for instant gratification.
2. If you’re convinced you’re in for the long haul, but prefer to learn at your own pace and in your spare time, pick up Aaron Hillegass’s Cocoa Programming for Mac OS X.
3. If it’s time to put the pedal to the metal, and you want to minimize the chances of failing as you learn the basics of this art, drop everything and enroll in the Objective-C and Cocoa Bootcamp class at Big Nerd Ranch.

Big Nerd Ranch is run by the very Aaron Hillegass who authored the book you picked up in step 2, and he teaches the Cocoa bootcamp class himself. The class is not cheap, but neither is it exploitatively expensive. You will learn to program for the Macintosh with a group of classmates, living and programming on a bucolic country retreat, where your meals and lodging are taken care of.

The Big Nerd Ranch concept is exciting, and I have often fantasized about attending a class there myself. I’m probably overqualified for the boot camp, though as with most life experiences, you learn something when you review the basics. The ranch offers a variety of classes in addition to the boot camp, including courses on more advanced Cocoa programming, iPhone development, and even on Django and Ruby on Rails web programming.

Right now, Aaron is busy building a bigger, better, greener, serener (funner? funnest?) Big Nerd Ranch. He’s actually bought a large plot of land and is drafting plans for several new buildings. He’s treating all of us to many glorious details on his personal blog: possible/probable. The blog frames itself as the chronicle of a man in his mid-youth, aiming to improve an already successful life by taking chances and aiming for the stars. It so happens that his stars form a constellation that idealizes and glorifies learning to program on the Mac.

When you check out the blog, be sure to read through the archives. You’ll be riveted by his stories of searching for suitable property, securing bank loans, winning and losing architects, and grappling with the underlying question of just how crazy pursing this dream might be.

Fortunately for us, Aaron seems to be guiding his own life with the words of his blog title, “possible” and “probable.” I interpret these slash/stroke separated terms optimistically, as I expect he does. If you can imagine something, if it seems vaguely possible, then with a little work it is made probable.

I find Aaron’s optimism inspiring, and his stories remind me of my own possible/probable dreams still waiting to be fulfilled. His zeal for the pursuit of happiness rests safely between recklessness and painful deliberation. He recognizes that while frightening risks need to be taken, putting in hours of hard and tedious work will greatly improve the odds of success.

We should all get to work turning our own possibilities into probabilities, because nobody else is going to do it for us. With the help of Aaron’s blog, we might find ourselves inching just a little bit closer.

“I think that I particularly hate strings in code that have programmatic meaning. I’m looking at you, KVC. And you, KVO.”

Reading this was one of those “yeah, that sucks!” moments, and it got me thinking about how the situation might be improved. The problem isn’t that strings are used to drive the logical flow of an application – this is nothing new. Since long before KVC (Key Value Coding) and KVO (Key Value Observing) came along, Cocoa has employed data-driven techniques for dictating logical flow in an application.

Consider Objective-C selectors. These are essentially “key value coded methods.” A selector is conceptually a string, so much so that Objective C offers a shorthand for creating selectors directly from text in your code:

SEL mySelector = @selector(doSomething:);

Apple even recognizes the desire to create selectors dynamically at runtime, and offers the NSSelectorFromString.

A great thing about selectors is that they’re only conceptually strings. The “SEL” data type is defined as an opaque data structure pointer. If you examine the memory of the structure (as of 10.4) you’ll see that it looks quite a lot like a string, which is handy for debugging, but it’s not guaranteed to be a string.

The opaque “obstruction” Apple has inserted between the conceptual and implementation levels mean two things:

1. Apple can change the implementation at any time to something that suits the system better.
2. Compilers can do first-class type checking on methods and functions that expect selector arguments.

Compare the selector situation with its much younger sibling, who seems to have been born in a hurry and without as much planning:

id myValue = [myObject valueForKey:@"hello"];

In contrast to selectors, where semantic meaning is locked into the explicit SEL data type, here we must derive meaning from the context of the constant string data. We only know that “hello” is a key (or we hope it is) because it is preceded by a “valueForKey:” method signature. It would have been a bit more cumbersome for Apple and developers if they’d defined a “KeyCode” type and required it in all key value coding and observing method parameters:

id myValue = [myObject valueForKey:@keycode(hello)];

But suddenly the string itself has a lot more meaning. You might argue that in this example, the problem is the same, but there’s just more context to surround the literal string. That’s kind of true, but with a true compiler type the meaning sticks with the variable long after it’s typed or viewed in the code. Methods could dynamically distinguish plain strings from coding strings, a compiler could produce warnings based on semantic knowledge of keys (“that string doesn’t conform to key coding syntax”), and runtime statistics could be gathered about the number of keys that are used by your application (whatever that is worth).

I haven’t really thought this through too far, but I’m curious why Apple chose not to mimic their own treatment of selectors when it came time to base another critical technology on conceptual strings. I wonder if a “strongly typed” set of key value coding methods as a wrapper on Foundation’s methods would prove useful in my projects, or be a misguided waste of time. What do you think?