Category Archives: Links

Push Notification Traps

Recently Marco Arment bemoaned Apple’s use of push notifications for promotional purposes. Apple sent a notification promoting their project (RED) products for sale in the App Store, which Marco judged as user-hostile and in poor taste, even if it can be argued it was “for a good cause.” I tend to agree with Marco on this point.

In the latest episode of the Accidental Tech Podcast, Marco, along with co-hosts John Siracusa and Casey Liss, talked more about the problem of notification spam in general and the difficulty of enforcing it at app review time. They seemed to be in agreement that the only realistic tool at Apple’s disposal is to devise a crowd-sourced flagging system for inappropriate notifications, and to use that collective information to pinpoint the worst offenders, and then to use that information to impose consequences upon them.

They went on to lament that Apple is not very good at these kinds of crowd-sourcing solutions, and that in all probability the vast majority of iOS users are not concerned or aware that they should be concerned about notification spam. The lack of consumer awareness about the nature of the problem could itself be a limiting factor in any crowd-sourced solution.

But I propose that Apple does have tools at its disposal that could help flag the worst offenders immediately, without the cooperation of the public, and without violating any user’s privacy.

All remote push notifications are delivered from an app’s developer to an end-user’s device via the Apple Push Notification service. This is good, because it puts Apple in a position to intercept and e.g. immediately shut down a bad actor from delivering notifications to any of its intended recipients. However, the content of all these notifications passing through Apple’s service is encrypted. This is good, even required, because it protects developer and company data from being eavesdropped. But it’s bad from an enforcement sense because it thwarts possible solutions such as using a Bayesian filter on content to flag spam, similarly to the way an app like SpamSieve works on the Mac.

So Apple has complete control over the distribution mechanism, but zero ability (apart from metadata including the originating company and the target device) to examine the content passing through. Game over? I don’t think so.

Apple can still use its unique role as the center of all things iOS to devise a system through which they would themselves be virtually subscribed to all unremarkable notifications from a particular app’s developer. Think about the worst notification spam you’ve seen. In my experience it’s not super-personalized. In fact, it’s liable to be an inducement to keep using the app, to advance in a game, to become more engaged, etc. I think Apple would collect a ton of useful information about spammy developers if they simply arranged that every app on the App Store that is capable of sending push notifications included, among its list of registered devices, a “pseudo-device” in Cupertino whose sole purpose was to receive notifications, scan them for spammy keywords, apply Bayesian filters, and flag questionable developers.

Because Apple controls the namespace for device IDs, has access to the executables for all the apps in the store, and is technically equipped to run these apps in contrived environments, they could coax applications to perceive themselves as having been installed and run on a device with ID of Apple’s choosing. In fact, it’s probably simplest if this very thing happens while App Store reviewers are evaluating apps. It’s true that they won’t see the spammy notifications during review, but the mechanics of triggering an app’s registration for future notifications would ensure delivery to a “trap device,” actually a giant database against which arbitrary research could be conducted.

This would not be a violation of anybody’s privacy, because only the artificial App Store review team’s data (if any) would be involved. Most likely, it would not capture most bona fide useful notifications, because reviewers wouldn’t use the app to the extent that such notifications are generated. But it would capture all the “send a notice to everybody whose every launched the app” and “send a notice to folks who haven’t launched lately” type spam. That seems like a pretty big deal.

At the very least, such a system could serve as a baseline mechanism for flagging developers, and in the event that some future crowd-sourced solution was unveiled, it would layer nicely on a system in which Apple was already collecting massive amounts of data about the most humdrum, spammy notifications that developers send.

Manton’s Twitter Apps

My long-time friend and podcasting partner, Manton Reece, is finally saying a painful goodbye to all of his apps that use Twitter’s API. Reacting to Twitter’s recent announcements about full-history search:

I was thrilled by this upgrade to the Twitter service. That the search was so limited for so long was the primary reason I built Tweet Library and Watermark to begin with. Unfortunately, this functionality is only for the official Twitter apps. It will not be made available to third-party developers.

Manton is probably the most earnest developer I know. He is eager and ambitious in his indie pursuits, but always slightly more interested in serving the greater good than in serving his own interests. To me this is a charming, admirable quality, even if it has lead to some inevitable frustrations and disappointment.

It’s easy to imagine how a developer like Manton Reece would have been so eager to participate in the Twitter developer platform of 2007, and how devastating it must have been for him to watch as his ambitions for the platform became less and less viable over time.

Brent Goes To Omni

Well, I’ll be darned.

Brent is a great developer and a great friend, who will now be working, in addition to his capacities at Q Branch, for the great, great Omni Group.

There are a few people in the Mac/iOS realm whose reputations are almost universally celebrated and admired. And there are a few companies that enjoy the same kind of respect. Brent and Omni are each of that ilk and it’s going to be very interesting to see what kinds of work they do together.

File A Bug

My friend Marco Arment laments that of the 15 bugs he’s filed since 2009, eight have been marked as duplicates, and seven have received no significant response.

Since 2009, I’ve reported 161 bugs. It’s much harder for me to do a stone-cold analysis of the results of my efforts. Yes, I’ve “wasted some time,” but often in the process of doing so I have also gained a deeper understanding of the problems I was reporting.

Having filed 161 bugs over six years, I can guarantee you that I’ve had far more bugs ignored or filed as duplicate than Marco has. I’ve had my share of bugs for which I’ve had to send back a sternly worded note to the bug screeners, implying in as polite a language as I could muster that they were not doing their jobs well.

I’ve also burdened Apple with a good number of false alarms: bug reports that I filed hastily only to discover were actually my own problem. Sometimes these were reported with confident, dismissive words that I later felt like eating. Sometimes I am not a great bug reporter.

And sometimes I am a great bug reporter. I’ve received notes of personal thanks on Twitter, via email, and in person at conferences such as WWDC. Engineers at Apple have said things such as “I wish all bug reports were as good as yours,” and “your bug report spelled out exactly how to fix the bug, so that’s exactly what we did.” I can’t remember a major OS X release when at least one of my reported bugs was not addressed during the beta release period, before the software ever saw the light of day. If we stretch the timeline back to 2008, I’ve even had the unexpected honor of being credited in a security update for what I thought was a simple networking bug.

I’ve had my share of frustrations with Apple’s bug reporting system, but I’m a developer. I can take it. I’m used to rejection. 9 times out of 10 when we developers press Cmd-R in Xcode to “Build and Run” our projects, they don’t even make it past the compile phase. But we keep trying. Why? Because we know how great it feels when we finally get something to work. We don’t need to be constantly reassured that we’re great, that our input matters, or that our concerns have been heard. Would it be nice? Sure. But so would Objective-C namespaces and a pony.

If we developers want Apple’s platforms to work as well as they can, the sad and short truth of the matter is we have to report bugs. If you’ve only reported 15 bugs over 6 years, as Marco has, I’m afraid to say that you haven’t done enough. To stand a statistical chance of either helping the cause or of being gratified by a personalized response, you’ll have to step it up, grin and bear the frustration and continue to press “Build and Run” on the Apple Bug Reporter and see what comes out the other end.

Core Intuition Jobs

On Wednesday, my podcasting colleague Manton Reece and I launched a new site: Core Intuition Jobs.

I’ve been in the Cocoa business for a long time. I started to learn the frameworks at Apple in the early 2000s, and got more serious after leaving Apple and building up Red Sweater Software as a consulting business and then as a direct-sale software business. When I started looking for Cocoa jobs on my own around 2004, there was no go-to place to search, so I resorted to a series of Craigslist RSS feed searches, tuned to each of the major markets in the US where I anticipated jobs would show up. That was a real drag.

Ten years later, I am no longer in the market for jobs. But after all this time in the community, working as a developer, blogger, podcaster, and occasional speaker, I’ve gained enough of a reputation that other people ask me where to find the jobs. To make matters worse, employers also ask me where to find the talent. The terrible thing is after all these years the situation is not much different than it was in 2004. There are a heck of a lot more jobs, and there is a heck of a lot more talent, but neither knows how to efficiently find the other.

Core Intuition Jobs aims to solve this problem by becoming the go-to source for both employers and job-seekers in the Cocoa development market. Other sites like StackOverflow Careers take a stab at solving the problem, but they suffer from a problem in that they are too large, and serve too many different needs to be uniquely valuable to a niche market such as ours.

I was talking with my wife in the car today about the value of niche job listing sites, and she shared an insight that seems obvious in hindsight: job sites are like dating sites. Matchmakers. If you’re looking for a romantic partner, you’d like to think you’re choosing a service that is teeming with suitable partners, or at least happens by some circumstance or other to be used only by other people who have a higher than average chance of clicking with you. This explains the preponderance of specialized dating services such as Salon Personals (for “smart” people), JDate (for Jewish people), or Silver Singles (for “mature” people).

If you’re looking for a partner, the last thing you need is a single database of every unmatched person in the world. Questions of religion, sexuality, musical taste, politics, and affinity for long walks on the beach may help to narrow the overwhelmingly large field, but some of these categories are significant enough to people that they warrant organizing at a higher level.

Most employers who are seeking Cocoa developers, and most developers seeking Cocoa jobs, are frankly inflexible about one sticking point: the match must involve one Cocoa expert providing a Mac or iOS solution to one company. That’s it. Android, ASP.NET, Java, jQuery, PHP, Ruby on Rails, and so on need not apply.

Well, we launched Core Intuition Jobs on Wednesday and by my estimation it is already the go-to source for pairing Cocoa employers with Cocoa developers. Take a look and see the impressive list of companies with openings in North America, Australia, the UK, Germany, as well as a handful of “anywhere” listings. The calibre of the companies on the site is also staggeringly great. This is no run-of-the-mill list of Cocoa jobs, which is a good thing, because we have no run-of-the-mill audience of developers.

Apart from the number and quality of employers who have responded so quickly by listing positions, I’ve been thrilled by the response from developers who, regardless of whether they are actively seeking, see the jobs board as a gift from us to them. This is incredibly charming because we do see it as a gift, but we also see it as a business venture. We got tired of telling people, often friends, that we had no good advice for how to find or a fill a job.

At some point we took a step back and realized that we’re being asked from both sides, and with our unique position as the hosts of a popular developer-oriented podcast, we have the ability to fill this niche quite nicely. We can give the gift of connecting developers and employers who, up to now, have had no common meeting place to discover one another. In return, we expect to build the job board into a sustainable business that complements our indie software businesses and the podcast.

We are selling 30-day listings on the site at an introductory price of $100. After February 25 (Tuesday) the standard price of $200 goes into effect. Buoyed by the positive reaction over the first few days, we’re hard at work adding new features, particularly to facilitate better tracking of new listings by job-seekers, and considering options for employers who want to maintain a consistent presence on the board.

We’ve already made one improvement with the addition of an RSS feed, so you can keep on top of every new listing we add. We’ll also be building similar notifications into the @coreintjobs Twitter and ADN accounts.

It’s a big world out there, filled with many potential career partners. We’re doing our part to bring passionate Cocoa developers together with companies that are looking to shine on Mac and iOS. In 2014, there is finally a go-to source for Cocoa job listings, and Manton and I happen to run it.

Addicted To Threes

While the rest of the world frets about the loss of Flappy Bird, some of us have become unexpectedly dependent upon a dazzling numerical puzzle game from Sirvo LLC called Threes.

I learned about the game through my friend Marco Arment, who gave a ringing endorsement of the game when he said it “doesn’t suck.” He’s right, in many, many ways. I was moved by his assessment to download and play the game. I’m glad I did, and I’m also devastated that I did.

It turns out Threes is a better game than I quite know how to comprehend. I want to play it again, and again, and again. It’s dangerous.

What is the secret sauce of Threes, and games like it? I’m not sure, but I have some impressions. If I were designing a game and I wanted to hope for anything near the irresistibility of Threes, these are the lessons I’d be taking from it:

  1. It’s easy to learn. The game has a brilliant interactive training mode that guides you through the simple rules that govern the game. Even a game with simple rules will be put aside if it takes more than a minute or two to learn, so luring folks in with a tutorial is a good call.
  2. It’s easy to “do well”. From the moment you start playing Threes you will find yourself making immediate, almost constant progress. The format of the game has smaller number tiles combining with one another from the very start, giving a fast-paced sense of progress that should thrill even novice players.
  3. It’s much harder to “do really well”. Once you’re hooked, you’ll find yourself trying to figure out what it was about your choices in one game that made you do so much better than you did in another game. And if, like me, you’re not some kind of cosmic genius, you’ll be intrigued to figure out what that is. I’ve been balancing my play between “having a good time” and “struggling to understand.” Sometimes the two do overlap. I’ve developed some techniques that seem to be effective, but on the whole I recognize there is a lot of room to grow. There is a lot to understand.
  4. It’s easy to get a reality check. Here’s a real kicker. If i were playing Threes in the privacy of my home without the benefit of Apple’s Game Center to let me know just how well my proud accomplishments stack up to friends and strangers, I’d be feeling pretty good. There’s even a chance that, without the knowledge of just how well other people are doing, I might reach a point where I convinced myself I had the game figured out. A quick glance at the high scores of my friends lets me know that I’ve figured out how to be relatively competent at the game (current high score: 9,132), but nowhere near as lucky and/or skilled as some friends and many strangers.

I’m sure these four points are the tip of the iceberg, but they are what stand out to me. Of course, it doesn’t hurt that the game is well-designed and adopts an honest business model (no ads or scammy upsells). The target audience for Threes is probably dramatically smaller than the audience of Flappy Bird, but especially for nerds or folks who just love a good numerical puzzle, Threes is a great value and an example of how great iOS games can be.

A Billion Dollars Worth Of Work

John Gruber shared a link about Facebook’s Sheryl Sandberg and her new “billionaire” status. He cites Bloomberg’s David de Jong quoting author David Kirkpatrick: “Did she do a billion dollars worth of work?”

I thought Gruber’s criticism of the statement was fair, and thought-provoking:

Would Kirkpatrick have asked this of a man? And if he had, would Bloomberg have run the quote?

It’s probably true that women such as Sandberg are subjected to a greater, unfair amount of speculation regarding the appropriateness of the rewards for their work.

In my opinion, that’s how Gruber’s link should have ended. But he added:

I searched Google for the phrase “Did he do a billion dollars worth of work?” and the only hit was this tweet from Jezebel editor-in-chief Jessica Coen, retweeting this tweet from Alex Leo pointing out the absurd gender bias in this article.

The implication, by my reading, is that the lack of Google results for the searched phrase: “did he do a billion dollars worth of work?” is evidence of a gender bias against women who have earned a billion dollars.

My problem with this line of reasoning is that the naturally contrasting search: “did she do a billion dollars worth of work?” also yields nearly no results. The vast majority, if not all of the results for that search are related to news from the past day related to this issue.

I don’t doubt that people are more critical and dismissive of a woman who has earned herself a billion dollars, but Gruber’s search example doesn’t support the claim. I wonder if there is a search that would support the claim? On Twitter, Gruber pointed out that there are fewer female than male billionaires. So perhaps it’s insufficient to measure disdain for female earnings by searching on the scale of billions? A paraphrased search on the scale of millions yields zero results, and zero for men as well. So “nobody” is complaining about the worthiness of folks, male or female, who earn a million dollars.

I agree with Gruber’s premise, but his own evidence doesn’t support it. I would rather see flimsy evidence omitted from an argument I agree with, because it offers a weakness for naysayers to attack.

Alex Serriere, on Twitter, offers a simplified search that does support Gruber’s premise, albeit indirectly:

@danielpunkass @gruber I think these searches sort of prove the point: “did he do enough” 347k results, “did she do enough” 1.9m results.

Of course I concede that none of this is scientific, but as far as off-the-cuff Google searches go, I find Alex’s results far more compelling and supportive of the argument at hand.

Restart Your Day Job

This timing could not be more perfect. As Matt Gemmell exits the professional software business, my old friend Duncan Davidson returns to it. For the first time in many years, he’s taken a full-time job as a software engineer, working for Wunderlist.

Duncan has a rich history in software development. From his time at Sun, he is the man behind Apache Tomcat and Ant, two Java tools that even I, a person who is mostly oblivious to Java, am familiar with. (As it turns out, I even use Ant in the build process for MarsEdit. That’s a story for another day.) Duncan also made a name for himself within the Cocoa community by writing one of the earliest Cocoa development guidebooks.

But Duncan is also a photographer, and a damned good one at that. I was impressed when, years ago, he put his considerable software abilities aside to focus on that lifelong passion. My first memories of this shift are seeing him roam the halls of Apple’s WWDC conference, not as an attendee but as a paid professional photographer. He went on to photograph for various O’Reilly Media conferences, and to this day he is the the main stage photographer for the illustrious TED Conference.

That’s an important detail to note in Duncan’s story: by returning his focus to the craft of software engineering, he will not be giving up his passion for photography. Professionally, he will continue to work with TED, and privately, I’ll be damned if you ever find him without a camera at close hand.

Duncan had the guts, many years ago, to give up software engineering to pursue photography. That has worked out very well for him. Now, he’s showing he has also has the guts to return to what he left behind. As a “new developer” in 2014, I’m sure there are things for him to learn from his teammates at Wunderlist. But I’m also sure there are many things for him to teach. I look forward to seeing where Duncan’s passions for software and photography take him next.

Quit Your Day Job

My friend Matt Gemmell has long been known as a prolific Mac developer, public speaker, and selfless contributor of open source code to the Mac community. He’s also a writer. He’s shared his thoughts on subjects ranging from coding well to living well, and in a recent post he makes the broad proclamation that he will give up the profession of programming to become a full-time writer. Making Changes:

Maybe it’s foolish, and from a commercial point of view it certainly looks that way, but I must try. As of this moment, I’m no longer developing software, either for myself or for others. I’m writing full-time.

Folks who read about this daring change of course will likely have one of two reactions: to support him unconditionally, or to condemn him as a fool. Count me among the supporters.

Most people who mutter the disgusting, deplorable phrase: “don’t quit your day job,” do so from a position of ignorance, of envy, or of both. “Quitting one’s day job,” so to speak, is the starting point for any major change in one’s career, and most of us could stand to do a lot more quitting and a lot less settling.

Sometimes I wonder what would happen if I quit my career of programming and threw all my energy into being a professional musician, interface designer, or … who knows what? I am at once afraid I would be an utter failure in another field, and worried that I might miss my beloved programming too much. But that’s not to say the day won’t come when I lay down my IDE and move on to another life pursuit.

Congratulations to Matt on making a difficult, important decision. Best of luck to him in his new career as a writer.

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.