Choices And Consequences

Apple’s iOS and Mac App Stores employ a crude system of ratings and reviews that nonetheless has an impact on how marketable an app is, and accordingly, how much money it brings in.

Since very early in the history of these stores, developers looking to raise the average “star rating” on their apps, and to garner gushing words of praise in their reviews, have dealt with a conundrum: users do not typically review apps unless angered or … encouraged.

So developers have encouraged users to review their apps, using techniques that span a spectrum from what most users would consider harmless, to tactics that even the most naive users recognize as badgering, condescending, and manipulative.

At the harmless end of the spectrum, you find gentle reminders on Twitter, links in the about boxes of apps, and earnest pleas in the signature footer of email correspondence. These are not a huge deal to most people, and are usually phrased in a way that extracts empathy and a sense of obligation from passionate users: “We know it takes time and effort to review an app, but if you value our work please consider leaving a positive review. It means a lot. Thank you!”

At the other end, you find blatant harassment and tricky language meant to confuse users into capitulating. Modal alert panels might interrupt a user’s workflow at inopportune times, demanding that they either leave a review now or be reminded later to do so. The natural reaction of any user in this situation would be to try to determine which series of hoops must be jumped through to get the app to leave one friggin’ alone!

Recently John Gruber addressed the problem of apps on the badgering end of the spectrum, and merely hinted at a grass-roots campaign that might make a dent in the problem:

I’ve long considered a public campaign against this particular practice, wherein I’d encourage Daring Fireball readers, whenever they encounter these “Please rate this app” prompts, to go ahead and take the time to do it — but to rate the app with just one star and to leave a review along the lines of, “One star for annoying me with a prompt to review the app.”

Of course, by alluding to such a campaign in the plain view of hundreds of thousands of readers, Gruber may in fact have launched it. I witnessed many hoots of agreement among folks on Twitter, but also this more considerate reaction from Cabel Sasser of Panic:

That said, ‘give apps that do this 1 star’ suggestion bummed me out — stoops to the level of ’1 star until you add X feature!’

Damn you, Cabel, and your empathetic rationality. There’s something to his call for civility and for taking the high road. On the other hand, damn it, too many developers have chosen the low road and users are entitled to react accordingly!

Probably the most uncomfortable aspect for me of this debate is that the temptation to … encourage users to write reviews and to rate software is completely rational. It makes perfect sense for us as developers to do everything we can to maximize the positive marketing of our apps.

But every choice in business comes with consequences, positive and negative. You implement a new feature that wows half your audience and increases sales among them by 10%, only to discover you’ve pissed off the other half and cut sales by 50% in their camp. It’s not fair or necessarily even rational. It’s just the mechanics of choices, reactions, and consequences.

Many developers cling tightly to the belief that because positive reviews can lead to increased sales, it’s unambiguously right to encourage more of them. And if producing a small number of reviews is a good thing, then producing a huge number of reviews must be a great thing. Mo’ reviews, mo’ money. What’s the problem?

The problem is that except to the least soulful among us, maximizing sales is not the only goal of writing software or developing a business. We need sales to keep ourselves and our families comfortable, but we need other things too. To many of us, these priorities are at least, if not more important than the specific need to make a living somehow:

  • The satisfaction that our customers are being treated well.
  • The ongoing support of customers for months and years to come.
  • The sense of pride in owning and stewarding a well-crafted product.

It’s smart to take it as given that something should be done to encourage users to leave positive ratings and reviews. That’s good business sense. But also take it as given that the farther you tread in the direction of badgering and disrespecting users, the more you chip away at the meaningful non-monetary benefits listed above.

If somebody like John Gruber incites your customers to rebel against the choices you’ve made in designing and marketing your product, take a step back before condemning him as the problem. Whether they knew it or not, your customers were already pissed at you before reading Gruber’s opinions. He’s only providing them with a context for expressing that rage. Take it as a wake up call and as an opportunity to re-evaluate your behavior before too many additional customers are moved to act.

Heavy-handed efforts to drum up reviews that produce a cash influx today might lead to unwanted consequences down the road. You might end up unsatisfied and ashamed that your otherwise brilliant app stoops to nagging and infuriating its users on a regular basis. And to top it all off, somebody like Gruber might light the match that sets them off revolting against you. It won’t be his fault, because the choices were yours all along. The consequences? Those are yours as well.

Instant Gratification

Technology consistently upgrades our standard of living, often in ways that we inevitably take for granted shortly after.

One of the best upgrades of the past few decades for so-called individual contributors like myself has been the extent to which we can now publish our work, receive feedback, and move forward in the process of perfecting our art. All within a few days or weeks rather than months or years.

In the old days, people like us worked in solitude or with the feedback of only a few confidants. A wider audience would evaluate the work only at major milestones: when a story was published, when an illustration was printed, or when a piece of software had passed through so many internal hoops and jumps that a publishing company agreed to release it to the open market.

These days, people who are confident they can do good work face one primary obstacle: the challenge of doing that good work. When the job is done, or even half-done, a dozen, hundreds, or thousands of eager constituents stand ready to judge it.

That’s terribly frightening and terribly enlivening. No more waiting for permission to share your thoughts, arts, or inventions with the world. And no more excuses for holding back. Got something to give? Put it out there and see what sticks.

Of course this freedom of expression comes at a cost: anybody can publish anything at any time. Most of it will be terrible, and much of it will be of lower quality than the highly-edited content of yesteryear. On the one hand, it encourages flippant blog posts like this, where perhaps the content should have gone through more than a ten-minute review process. On the other hand? Nobody with something profound to share should ever be silenced again.

The Integrity Prize

Alicia Liu paints a compelling picture of Salesforce as scoundrels, or at least oblivious, in their recent hackathon. They promised a $1M USD prize to whichever team of developers could present the “best” product submitted in compliance with the contest’s rules. The questions being raised have to do primarily with whether or not the rules were upheld.

Liu participated in the hackathon, and shares her first hand experiences of problems she observed. I learned about this story from Marco Arment, who points out that Salesforce will likely suffer a developer backlash from the airing of all this dirty laundry. It would be unfair to condemn a company based on the testimony of one participant, but her account reads authentic to me, and seems to be supported by comments on Hacker News. (I know, not the world’s most reliable source).

The most galling points to me from Liu’s report are:

  1. The winners of the contest seemed to be in violation of both the spirit and the letter of the rules.
  2. Multiple participants’ submissions seem to not even have been evaluated.

I believe that in general bending the rules is a valuable exercise. But when it comes to judged competition of any kind, whether it be on the sporting field, at the local trivia quiz, or in a $1M cash prize hackathon, a contest is only as good as its compliance with the rules. Any participant in the Salesforce event whose diligent, rule-abiding effort was either ignored completely or dismissed as inferior to the work of a rules-shirking participant, is right to be indignant about the outcome of the event. The rules of this contest, both the grandiose prize, and the significant surrender of IP rights required by the rules, make the apparent jerking around of participants that much more distasteful.

As much as it irks me to learn of companies exploiting programmers, it bothers me on a more personal level that so many developers are eager to surrender both their time and their integrity to participate in such events. Whether it’s out of hope for a $1M jackpot or, perhaps more troublingly, based in the desperate pursuit of any external validation of their work, these are not ideal outlets for the most talented developers in any field.

Few of us are immune to the lure of prizes and recognition. Every spring, most of my friends and I start gossiping about, maybe dreaming about, the potential winners of the Apple Design Awards. These are conveyed every year at Apple’s Worldwide Developer Conference. While Apple seems to stick to the letter of its rules pretty well, the rules themselves sometimes seem capricious, and are not announced until a few months before the “contest.” Nonetheless, myself and others have been caught up some years toiling away on products or features that we wouldn’t otherwise be focused on, all in the vain hope of winning the coveted prize. At least in this scenario with Apple, we may be sacrificing a small amount of integrity, but aren’t outright donating our IP to the company.

I’m reminded by hackathons like Salesforce’s, by Apple’s Design Awards, and even by awards I’ve been humbled to receive such as the Macworld Editor’s Choice Award, that as great as it feels to win a contest, prizes like these shouldn’t be our primary goal. I’ve joked about it some years, when I inevitably don’t win an Apple Design Award, that at least I’m still winning the Customer Design Award. With that quip I mean to remind myself that winning the favor of these small groups of people with power should never be seen as more valuable than winning the favor of the people who really matter.

Who really matters? Yourself, those who are close to you, and the customers you aim to serve. Start each day determined to win the hearts of those people, and strive to remain indifferent about the judgements of Salesforce, Apple, or any other small group of judges that aims to string you along for their gain. You may not win $1M, but you’ll hold on to the most valuable prize of all: your integrity.

Stagnation Or Stability?

Michael Lopp is moving on from Things, a popular to-do management app.

That’s an understatement. The title of the post is “R.I.P. Things,” and he wastes no time explaining that he is “throwing away” the app. This sounds juicy. What could have him so riled up?

How can I trust that I’m using the state of the art in productivity systems when I’m using an application that took over two years to land sync I could easily use? What other innovations are they struggling to land in the application? Why hasn’t the artwork changed in forever? What is that smell? That smell is stagnation.

The nut of Lopp’s rationale for tossing Things to the curb is the relatively slow pace of its development over the years. Delays in delivering long-desired features, namely sync, made him conclude that the software will not evolve in ways that suit his needs moving forward. He’s not giving up on Things because of specific shortcomings, but because of anticipated shortcomings and a loss of confidence in the developers of the app.

This line of reasoning gets my hackles up in part because I’m a cautious, deliberate developer. I tend to add features, rework user interfaces, and adopt new platforms at a pace that frustrates even my most loyal customers. I’m slow, but I’m good! When Lopp attacks Cultured Code, the makers of Things, and questions their core competence, I feel that I am being attacked as well.

But what really frustrates me in this case is the software has served him perfectly, and he thanks it with a slap to the face. It’s one thing to denigrate a product for failing to meet your expectations, or for exhibiting a clear lack of craftsmanship, but Lopp admits that those problems do not apply:

Part of me has been fine with this lack of change because I don’t need my productivity system to do much more than capture a task, allow me to easily categorize and prioritize tasks, make it easy to search and filter them, and do all this work frictionlessly. “Things does these things well,” I thought to myself, “I don’t need anything else.”

He applauds the app for allowing him to do his work “frictionlessly.” How does a software developer achieve this level of performance? By first building a quality product and then working deliberately over months and years to address the minor issues that remain. Woodworking makes a reasonable analogy: after a chair has been carved and assembled the job is functionally complete. It’s a chair, you can sit in it. It’s done. But customers will gripe with good cause about its crudeness unless the hard work of detailing, sanding, and lacquering are carried out. Only then will it be considered finely crafted.

As a seasoned software manager, I know Lopp appreciates how hard it is to achieve the stability Things has provided for him. But as a user, he’s as excited as any of us to see new, fresh designs. As an onlooker, it’s easy to associate dramatic change and motion with competence, and quiet refinement with laziness. We must draw on our own experiences attempting to build great things to appreciate how much work takes place in stillness, to have faith that even though things may appear stagnant, a benefit of frictionlessness is resulting. An app at rest may be in that long, arduous phase of becoming finely crafted.

There is a time for dramatic change as well, but it comes with costs. If after years of careful refinement a product is found to be lacking in some important way, bring out the hatchets. Chop it all to bits and rebuild from scratch. The possibilities of positive change in major reworks are exhilarating as a developer, and tantalizing to customers. But every reworked component of a product also resets that process of refinement.

Software should be criticized. Even apps that consistently wow me with their intuitiveness and polish leave me scratching my head about perplexing, nuanced failures. But criticize an app for its failure to do something important, not for an unspecific failure to change in general.

I’ve whined about stagnation, too. I waited years for an update to Keynote and over time, become more and more grumpy about the lack of change. The fact that it’s just about the best application I’ve ever used slowly lost sway in my judgement of the software and, by association, the team of developers who build it.

The next time I’m tempted to think harshly of a developer working at a slower pace than I’d like, I’ll try to step back and appreciate that I care enough about their software to be concerned. And more importantly to appreciate that they care about their software too. So much that they work slowly, deliberately, painstakingly in the pursuit of a frictionless experience for myself and other users.

Fingerprints As Access Tokens

Everybody seems to have an opinion about the new TouchID fingerprint sensor on Apple’s iPhone 5S. I suppose I do, as well.

Critics object to the idea that a fingerprint sensor, no matter how good, should be used to safeguard critical data. Dustin Kirkland makes the case (via John Moltz) that biometric information is inherently bad as a substitute for a password, because it cannot be “independently chosen, changed, and rotated.”

I take his points seriously, and they seem well reasoned from a security point of view, but they are based upon the premise that passwords are the end-all be-all of security, when in fact common sense proves they are not. The oldest, most trusted, and most widely deployed method of authentication on the planet is in fact “biometric”: the human ability to recognize a familiar face. The fact that my appearance could technically be spoofed does not change the fact that arriving at the home of a childhood friend after 20 years of separation will still earn me an invitation to the dinner table, if not a bed for the night.

So fingerprints make lousy passwords. Who cares? Their use in practice need not replace other authentication schemes, it only needs to augment other schemes in a manner that increases overall security.

Most authentication systems in society are scaled appropriately for the context in which they are deployed. When I travel by airplane, I am asked to show a government ID to get through the security gate, but thereafter, a simple piece of printed paper will get me on a plane. The government takes it for granted that once I’m in the boarding area, the odds of somebody getting hold of my scrap of paper, or my getting hold of theirs, and neither one of us subsequently complaining, are marginally small. Furthermore, if the two of us mutually agree to swap tickets and travel to the other’s destination, we haven’t really caused any significant harm, except perhaps to the egos of the folks in charge at the TSA.

Boarding passes are little scraps of paper that make lousy identification cards. I can’t use them to reserve a hotel, file a police report, or obtain a marriage license. Yet in the right context, I can use one to travel from Boston to Shanghai without a single person batting an eye or thinking twice about verifying my identity.

In this sense the airline boarding pass is like an access token. On the web, an access token is something obtained by stronger authentication that permits continued access with weaker authentication. For example when I allow a Twitter client to connect to my Twitter account, I must first visit Twitter.com and possibly enter my full account credentials. After the access token has been vended however, it serves much like a boarding pass, allowing free access until and unless I or Twitter registers a complaint.

There’s another sort of abstract access token that has been available to users iOS devices since day one: your continuous use of the device. If you have in your possession an iOS device and you abstain from turning it off or letting it sit idle, you retain free access to the various data on the phone. From a security point of view, this token is even worse than a fingerprint: anybody, including the family cat, can sustain it if they are so inclined. Leave a phone on a table for 5 seconds, somebody else picks it up, they have your “activity token,” and they didn’t even need to scan your fingerprint.

I view the fingerprint sensor on the iPhone 5S and other devices as an opportunity for extending this kind of implicit authentication. It’s not a substitute for a password, but rather a convenient token for obtaining streamlined, continued access to protected resources. It’s the boarding pass that prevents you needing to take out your ID, and go through a body scanner or pat-down again, just to get on the damned plane.

We can argue about whether Apple has chosen the right boundaries for where a fingerprint should be traded for full authentication, but as a technology it stands to fill that gap between the frighteningly insecure “unlocked while active,” and frustratingly unusable “full authentication required when inactive.”

In short, I would like to see fingerprint authentication deployed in a way that pays respect both to the relative convenience and the relative insecurity of a fingerprint. If I can for example configure my phone to require a fingerprint unlock after 1 minute of inactivity, but to require a passcode unlock after 30 minutes of inactivity, my concerns about fingerprint security would be effectively put to rest. Could a malicious person steal a high quality impression of my thumb print, construct a prosthetic, fleshy representation of it, and use it to unlock my phone? Perhaps. But if they can’t do it within half an hour of stealing my phone, they better get to work on cracking the passcode.

A Mockery Of Whom?

Are Marissa Mayer and Yahoo!’s design team playing the fools, or playing us for fools? I honestly am not sure anymore.

When the company announced more than a month ago that they would debut a new logo, I was surprised to learn that before sharing it with us, they would subject themselves and us to 30 days of lackluster logos. It felt to me like a lapse in judgement to:

  1. Put off for even a day the fresh new logo that was prepared to move the company forward.
  2. Accept for even a day, let alone 30, the use of any logo that had not made the cut.

But I sort of laughed it off, snidely and then crudely shared my thoughts on the matter, and waited out the 30 days.

Last night Yahoo! finally revealed the new logo, and the mildest reaction I can possibly muster is that it does not appear to be a professional design:

Yahoo's new logo, September 2013.

Because I myself am not a professional designer, I am tentative about making specific judgements, but my relatively untrained eye reacts to several problems with logo. The beveled characters make the logo appear dated and distractingly three dimensional. The scalloped edges lead the eye away from forming any unified shape. The lightness of the strokes, particularly in the bar of the A and H makes the whole thing feel fragile and not suited to scaling very large or very small.

A snarky summary of my criticisms would be to say that it looks like something somebody threw together in a weekend. Upon seeing the new logo I tweeted that I hoped it “was designed by committee, because I don’t want to imagine an individual taking the brunt of reactions.”

Marissa Mayer herself chimed in on the new logo, so now we know that both are true: it was designed by committee, and it was thrown together in a weekend:

So, one weekend this summer, I rolled up my sleeves and dove into the trenches with our logo design team: Bob Stohrer, Marc DeBartolomeis, Russ Khaydarov, and our intern Max Ma. We spent the majority of Saturday and Sunday designing the logo from start to finish, and we had a ton of fun weighing every minute detail.

Expletives are begging to let loose in my typing. You have to be kidding me.

This is not how any company, big or small, cherished or unknown should design a company identity. The more I read about Yahoo!’s process for this redesign, the less respect and confidence I have in them. As a minor Yahoo! shareholder and a long-time, sometimes grudging fan of the company, I am not sure where to go with these feelings.

It’s that point of gullible disbelief where one starts to look around for hidden cameras. Are we being punked? Is Marissa Mayer merely making a mockery of Yahoo! and its identity, or if she is snickering churlishly as she pulls off an elaborate prank, hi-fiving her co-conspirators as they witnesses the world react jaw-gapingly to their purported pride in these actions?

The Imperfect Craft

For much of my career I viewed software development as a craft: a constructive endeavor with fixed standards of excellence. I thought that over a lifetime, I could assiduously refine my skills, inching toward some level of subjective mastery until eventually myself and others would agree that I had become “a real expert.”

Unfortunately it doesn’t work that way with software. The technological context in which software is developed and used changes constantly and dramatically. So most of the stringent guidelines we impose upon ourselves in the name of craftsmanship are at risk of being obsoleted by some new advance in hardware, in programming languages, or in the baseline services of the operating systems we develop for.

Ask yourself, or a software developer of a certain age: what were the guidelines for crafting excellent software 5 years ago? 10 years ago? 20 years ago? The farther back one goes, the less relevant the answers will be to our modern craft. Memory management? Not a significant issue for most programmers today. Multitasking? Obliterated by modern operating systems with efficient context switches. Concurrent programming? Constantly reinvented in the wake of multi-core CPUs, GPUs, and higher-level programming language features.

I have spent a lot of my professional life honing “the skills of programming.” That is, the set of skills that seemed important at the start of my career. But I’ve seen what happens to people who cling to outdated standards of craftsmanship: they become self-righteous, bitter, and delusional. Guided only by the hallowed rules of yesteryear’s geniuses, they and their work become marginalized. Without a foothold in the modern technological context, programmers who should be great are rendered effectively incapable of developing their craft.

I’m sure this problem is not limited to software development, but given the world’s obsession with computers and related technology, the software landscape is changing much faster than many of us can easily keep up with. The world demands that this craft change. The technology for sculpting, firing, and glazing a ceramic bowl has also changed over the years, but not at the same mind-boggling rate as prototyping, programming, and testing a software application has.

What if you happen to enjoy old-school programming? There’s nothing inherently wrong with crafting “retro software.” In fact, I’m sure that dabbling in outdated techniques will serve to round out a modern programmer’s abilities. But while a classics scholar may be intrigued or even obsessed with ancient Greek or Latin, she knows that in order to remain relevant she must publish her papers in modern English. And if Esperanto were to become the lingua franca for her craft, that is the language she would have to use.

In software, the lingua franca is changing all the time, whether by adoption of new programming languages, through nuanced idiomatic changes in the ways that we use languages, or because of evolving operating-system level facilities. We don’t have the luxury of assuming that the tools and techniques of our parents, or even our younger selves, are sufficient to move the profession forward.

As a modern software developer, I derive as much joy from remaining relevant as I do from the thrill of identifying and solving the particular problems in my work. To remain relevant, I have to reject my previous assumption that I would spend a lifetime refining my craft. Instead, I will spend a lifetime adapting the techniques of yesterday’s craft to the sometimes radically different challenges of today. I may never become “a real expert,” as I hoped I might be. But by diligently throwing out the old rules and embracing the new ones, I hope to come close.

Assembled In USA

Apple has reportedly begun promoting the new Mac Pro, of all products, in US movie theaters. John Gruber linked to the story, commenting on the apparent disparity between mass movie-going audiences and a pro-market computer:

Impressive marketing move for a product that is by all means truly “pro”.

One objective of the teaser is to remind everyday American movie-goers that Apple continues to innovate in computer hardware. The teaser emphasizes Apple’s ability to design beautiful hardware and to push the envelope of how a computer looks and feels. It serves to remind the public that Apple is both capable and cool.

But I expect the other goal with this spot is to appeal to American pride. Why promote an expensive, niche-market computer like the Mac Pro to everyday Joes and Janes across the country? Because on top of being an innovative, beautiful, envelope-pushing piece of hardware, it will be made right here in the USA.

I haven’t seen a verbatim copy of the trailer as shown in theaters. Apparently it ends with a headline indicating the Mac Pro will be available “Fall 2013.” I will be surprised if it doesn’t also subtly allude to its American manufacture. A small percentage of folks who see the ad will leave the theater committed to purchasing a Mac Pro this Fall. A far greater percentage will leave the theater convinced that the Chinese-manufactured iPhone or iPad they’re considering for Christmas is part of a great American tradition. And they’ll be right.

Update: Reports from folks on Twitter indicate that the movie-trailer features no such mention of the Mac Pro’s US assembly. That strikes me as a shame and a missed opportunity particularly considered the hyper-focused US market for the ads. Another compelling theory from Drew Pickard suggests that running ads for the Mac Pro in movie theaters is a good way to make sure every movie-making professional is aware of the computer, and will consider purchasing them for their production teams.

Mercurial Plugin For Xcode

Raphael Sebbe (@rsebbe) put together a nifty plugin for Xcode (version 4 or 5!) that coerces Xcode into substantially supporting Mercurial, in addition to its native support for Git and Subversion.

The plugin builds upon an existing script that essentially acts as a Git-facade around Mercurial. Swapping the script in for Git is sufficient to cause Xcode to think it’s dealing with Git, when in fact it’s dealing with Mercurial. Pretty clever. The plugin takes this a step further by appyling some runtime patches on Xcode to improve the handling of Mercurial repositories.

Although Raphael calls it a plugin, and it does extend Xcode, it’s important to recognize that Xcode doesn’t provide an official plugin mechanism. Not even for revision control solutions. This makes the achievement even more admirable, but should also inspire you to proceed with caution if you choose to try the plugin out.

As explained in the project documentation, the plugin is still experimental and doesn’t support all of Xcode’s Git-based features. Still, it’s a nice start, and I appreciate the spirit of rallying Mercurial fans to fill the void that Apple has left in choosing not to officially support Mercurial.

Bitsplitting Podcast Hiatus

Earlier this year, I announced the Bitsplitting podcast, explaining that I hoped to establish a new kind of “tech podcast” that is more of the genre perfected by Terry Gross of NPR’s Fresh Air:

I’ll differentiate my show from some others by focusing more on the personal background of my guests, and on trying to discern a philosophical arc to their life and career choices.

Ten episodes later, I am proud to claim that I’ve achieved that. Thanks to an incredible list of thoughtful, well-spoken guests who agreed to join me on the show, I have something fabulous to show for the hard work that went into making this happen.

And now I need a break.

Planning, recording, editing, promoting, and funding the Bitsplitting podcast is both more difficult and more rewarding than I expected. I started off very anxious about the challenge of producing a show that meets my standards, and I have for better and for worse remained very anxious about many aspects of the show. Sticking to a schedule and pep-talking myself into believing that I am doing a good job (I do, most days!), is a lot more tiring, physically and emotionally, than I expected. Not to mention I have lots of other projects on my plate.

By taking a break and adopting an irregular “series” schedule for the show, where I am not committed to the never-ending pressure of pushing out the next show, I hope that it will give listeners a chance to catch up and enjoy the work that has been done, and give me a chance to think about how the show should evolve going forward.

Thank you very much to all the listeners and sponsors who supported the show from its infancy through its still-young, but gratifyingly successful state today.

Bitsplitting With Jason Snell

Episode #10 of the Bitsplitting podcast features my friend Jason Snell of IDG and The Incomparable podcast.

Jason’s role as editor of Macworld made him familiar to me as a Mac enthusiast and indie software developer. After I acquired MarsEdit in 2007, I had the opportunity to chat a bit with Jason about his own use of the app. Over the years since then, I’ve had the fortune to meet with Jason during WWDC and occasionally when he visits the Boston area for his work.

Thanks for joining me on Bitsplitting, Jason!