Recent criticism of Apple’s AI efforts has been juicy to say the least, but this shouldn’t distract us from continuing to criticize one of Apple’s most deserving targets: App Review. Especially now that there’s a perfectly good AI lens through which to do so.

It’s one thing for Apple’s AI product offerings to be non-competitive. Perhaps even worse is that as Apple stands still, software development is moving forward faster than ever before. Like it or not, LLMs—both through general chat interfaces and purpose-built developer tools—have meaningfully increased the rate at which new software can be produced. And they’ve done so both by making skilled developers more productive while also lowering the bar for less-experienced participants.

Barring a sharp correction, Apple looks increasingly likely to miss out on a generation of developers conditioned to first reach for tools like Cursor, Replit, or v0—especially as Apple’s own AI tooling remains notably absent. This goes well beyond enabling new entrants to “vibe code”—experienced mobile developers who, despite history with Xcode and a predilection for building native apps, are begrudgingly swapping out their tools in acknowledgement of the inarguable productivity benefits.

Sure, AI-assisted developer tools can be used to generate native iOS apps, but they’re not nearly as good at this as they are at generating e.g. React, whose developer experience advantage predates the LLM wave and has only since accelerated. While Mobile Safari can run webapps quite well, and native apps can be built using React Native, those clearly aren’t strategically ideal for Apple¹.

So iOS apps may increasingly be built using Cursor, and perhaps a larger percentage of them end up being built using React Native. And yet iPhones remain massively popular, so what’s the problem as long as they’re being built?

The wall that you’ll hit when actually trying to distribute them:

App Review has always long been a major source of developer frustration. Authoritarian yet inconsistent policy enforcement aside², it’s simply too hard to distribute software even to your own Apple devices, let alone someone else’s. This isn’t new by any means, but as the time to build an app shrinks from weeks/months to hours/days, it feels more egregious—and thus like more of a liability—than ever before.

I recently built a small iOS app for myself. I can install it on my phone directly from Xcode but it expires after seven days because I’m using a free Apple Developer account. I’m not trying to avoid paying Apple, but there’s enough friction involved in switching to a paid account that I simply haven’t been bothered. And I used to wrangle provisioning profiles for a living! I can’t imagine that I’m alone here, or that others with less tribal iOS development knowledge are going to have a higher tolerance for this. A friend asked me to send the app to them but that’d involve creating a TestFlight group, submitting a build to Apple, waiting for them to approve it, etc. Compare this to simply pushing to Cloudflare or Netlify and automatically having a URL you can send to a friend or share via Twitter. Or using tools like v0 or Replit, where hosting/distribution are already baked in.

Again, this isn’t new—but being able to build this much software this fast is new. App distribution friction has stayed constant while friction in all other stages of software development has largely evaporated. It’s the difference between inconvenient and untenable.

So what’s the alternative? Tech platforms are dominant until they aren’t and—obviously—iPhone hegemony won’t last forever. When sufficiently zoomed in, it’s really hard to see the first few cracks in the foundation—the harbingers of the beginning of the end, even if we’re a long way from the actual end. I would’ve recently laughed at the suggestion that webapps could legitimately contend on mobile but I’m no longer laughing. OpenAI building an iPhone competitor might sound similarly hard to believe, but don’t forget that such skepticism—“The PC guys are not going to just, you know, knock this out. I guarantee it”—was levied by incumbents towards the iPhone itself.

If Apple sees its developer tooling and policies as neatly-paved sidewalks, new desire paths are forming—paths increasingly designed to minimize touchpoints with Apple. Alarm bells should be ringing for those concerned with what remains of Apple’s developer goodwill, and consequently, its market position.

In January I wrote:

It’ll be pretty embarassing if this is still my latest post a year from now.

Technically I needn’t be embarassed, but let’s be honest, not writing at all until now clearly isn’t what I intended. It’s been a busy year! I moved into a new house, which honestly took up more time and energy than I ever could have imagined.

But still. More to come.

Studies have shown that algorithmic timelines drive more engagement than reverse-chronological timelines comprised exclusively of content that the user has explicitly chosen to follow. This makes sense—the overwhelming majority of social media users don’t build and cultivate robust networks on these platforms. As such, it shouldn’t be much of a surprise that algorithmic timelines “outperform” what would likely otherwise be a pretty desolate experience.

That said, the few of us who did invest in curation got something even better. Every launch of Twitter or Reddit was comprised purely of exactly what you actually wanted to see. And if you used certain clients—an option that users of both services had until very recently—you could pick up right where you left off.

Exactly what you wanted and right where you left off, always. Without ads! The pure uncut experience. No wonder so many of us were addicted.

Things are very different today. Twitter and Reddit no longer let you use clients that provide this experience. “Following” timelines, while often still possible, no longer sync one’s position and routinely switch back to the algorithmic default. Low-quality ads fill every nook and cranny.

But beyond this, most importantly, there’s just no longer a single Twitter.

When everyone used Twitter, even the algorithmic feed—a worse experience than “Following,” to be sure—was OK. It was primarily comprised of tweets from accounts that you had actually followed, just in a different sort order. Now, with users spread across a myriad of different services, “For You” is full of performative, SEO’d clickbait—the likes of previously only seen on LinkedIn.

Before the diaspora there used to be one place to look and one place to post. But everything’s now spread across Twitter, Threads, Mastodon, and (I think?) Bluesky. Before posting, one must double-check if they’re sharing the right content for the right audience subset. Before reading, one must stop to remember if the app that they’re going to open is actually the one most likely to provide what they’re looking for in this moment. The likelihood that you’ll see what you want is reduced. The likelihood that the right audience will see what you posted is reduced. The likelihood that you’ll open multiple apps only to see the same content multiple times is increased. As is the likelihood that none of them provide the high that used to be available at will.

It adds up. It’s exhausting. It’s impossible to imagine that anyone who spent years with the uncut experience would spend nearly as much time doing all of this.

So we won’t. And we’ll be so much better for it. It couldn’t have been ideal for us to have spent so much time that way, but how could we not have?

We didn’t know how good we had it. But you can have too much of a good thing, so it’s better now that it’s worse.

For the third straight year, it was New Year’s Eve and I hadn’t written anything all year. I only had a few hours left to change that, just like last year and the year before that.

But did I really need to? I didn’t. I enjoyed the holiday with my family and made peace with this site not having anything from 2022, the first year without a post since it was launched¹.

How did I get to this point? When did blogging turn from an outlet to an obligation?

As you can see, I used to write a decent amount and simply don’t anymore. Two contributing factors are that I haven’t kept up with the topic I used to primarily cover (iOS development), and I got older and busier².

But more than either, I think the bigger reason is that rather than trying to expand my thoughts beyond 280 characters, I became content just tweeting something out and being done with it. Any medium-sized thought was either compressed into a tweet or, increasingly infrequently, expanded into an essay.

This wasn’t always the case! Here‘s a short post that I’m glad wasn’t a tweet, though almost certainly would have been in recent years. Here’s another.

While the bar for tweeting couldn’t be lower, the bar for publishing here felt like it had grown to be insurmountable. If you’re only going to publish once a year, it had better be good, right³?

No more. This is my space on the Internet and I can change it however I want such that I’ll actually start to use it again. And I will⁴.

While my inability to blog clearly isn’t a recent phenomenon, Twitter’s current managerial situation has unsurprisingly prompted a lot of my recent reflections on the topic. As articulated well in Bring back personal blogging:

The biggest reason personal blogs need to make a comeback is a simple one: we should all be in control of our own platforms.

If what is happening on Twitter hasn’t demonstrated it, our relationship with these social media platforms is tenuous at best. The thing we are using to build our popularity today could very well be destroyed and disappear from the internet tomorrow, and then what?

Owning your content and controlling your platform is essential, and having a personal blog is a great way to do that.

So here I am. It’ll be pretty embarassing if this is still my latest post a year from now.

The web feels a bit more malleable than it did just a couple of years ago. Why might that be?

Knowledge management software has been with us for decades but only recently feels like it’s become a fixture of how early adopters use the web¹. Networking one’s own personal notes might just be a step towards having the web be authored by a much larger subset of its users, doing so from rich text environments rather than IDEs. Great products like Roam Research² have started to popularize the benefits of contributing nodes and edges to a knowledge graph, making their creation feel as frictionless as bolding or italicizing. How does networked note-taking lead to web authoring? I’m confident that we’ll see this new class of tools increasingly lead to our “notes” becoming both collaboratively authored and publicly readable, at which point the lines will have become quite blurry³.

In Neal Stephenson’s The Diamond Age, our young protagonist comes to possess a copy of The Young Lady’s Illustrated Primer, an interactive storybook designed to teach its owner everything they need to know through choose-your-own-adventure edutainment. The more I thought about Roam’s choice to include the word “research” in their product name, the more it helped me reframe my own relationship with the web. “Browsing”⁴ started to feel passive or reactive (if not a bit wasteful), while researching—reading but crucially also writing—felt proactive and enriching, a way to earn compound interest on your thoughts.

Researching made me feel like I was meaningfully investing in myself, not unlike how writing had in the past but now with tools tailor-made to empower. Networked note-taking became my Primer—tangents could be sought out instead of avoided, with backlinks turning the anecdotal into the indexed, the random into the patterned, the hazy into the coherent. Unsurprisingly, the web feels more pliable when you feel like a main character as opposed to an outside observer.

Next, the explosion of blockchains and distributed applications feels like a significant lowering of the barrier to contribution and participation. Yes, open source software predates smart contracts and traditional REST APIs can already be built on top of. But the composability and interoperability inherent in these new ecosystems brings increased opportunity to leverage existing code and data, both to adapt in new ways or to wrap in higher levels of abstraction.

Building on top of existing code, data, and authentication affords the benefit of focusing on novel logic and UX alone, and unsurprisingly has led to an incomprehensible number of new projects. The overwhelming majority won’t succeed, but we can repurpose a Ben Thompson quote about Shopify to understand why this can be reason for optimism:

I would argue that for Shopify a high churn rate is just as much a positive signal as it is a negative one: the easier it is to start an e-commerce business on the platform, the more failures there will be. And, at the same time, the greater likelihood there will be of capturing and supporting successes.

When I think of the web, I think of a series of siloed databases and applications: built by engineers, stitched together by crawlers, and served to the masses via search. Too often, this doesn’t feel particularly approachable even to me, someone with a career of experience building exactly these kinds of systems. It’s not purely about having the requisite knowledge⁵—the activation energy currently required to create something out of nothing undeniably keeps far too many good ideas from ever evolving past that.

But I’m optimistic that this can change in a big way. Are networked notes and blockchains really going be meaningful change agents? Perhaps not. But on this last day of 2021, they’re what come to mind.

Let’s start by getting the tropes out of the way: drugs, hippies, Ben & Jerry’s, “the Grateful Dead were better,” that “Gin and Juice” cover from Napster with the wrong MP3 metadata. And say what you will about their music; love it, hate it, or have no opinion whatsoever¹, this essay isn’t really about music. It’s about a unique–and I have to think incredibly successful–digital content strategy unlike anything else I’ve ever seen, and seemingly nearly impossible to replicate.

Before we dig in, let’s jump back a couple of decades.

In the heyday of the aforementioned Napster and during the transition from physical media to streaming video, the music and film industries attempted to combat piracy by clamping down as hard as possible with restrictive DRM, unskippable DVD preambles, and exorbitant lawsuits. Pundits and industry observers bemoaned this approach, countering that an effective defense wouldn’t be through draconian restrictions but by competing on quality and convenience; that DRM and similarly user-hostile approaches would lead to more piracy in service of a better user experience irrespective of cost. That the way to win was by charging a fair price for a superior product.

If services like Netflix and Spotify have proven this to be true², Phish has taken it to an extreme. While most bands would consider their studio records to be more canonical than their live recordings, the opposite is true for Phish. Yet Phish embraces the recording and sharing of their live music rather than trying to stop it–you can legally listen to hundreds of Phish shows right now just by going to this website.

This isn’t because they don’t want you to pay for their music, however. To the contrary, their LivePhish website competes on quality and convenience by making every show since 2002 available:

• In lossless audio quality, straight from the soundboard
• Literally within minutes of each concert ending³
• To either download or stream (via web, iOS/Android/Apple TV apps, Sonos, etc.)
• To purchase either à la carte or through a monthly subscription
• With beautiful, thoughtful, artwork unique to that show or tour

Oh, and they also broadcast the live video streams of these shows. In high-definition. With extremely high-quality camerawork. For a fair price, naturally.

At this point, you might be thinking that this doesn’t actually sound particularly lucrative. After all, if you’ve heard one live show haven’t you heard them all?

This would be the case for most bands but not for Phish. Phish plays with an improvisational style which means no two shows are ever the same. If this sounds like an exaggeration, it isn’t. All four band members are virtuosic in their own right, but have also been playing together for almost 40 years as of this writing. This gives them both an enormous repertoire to draw from⁴, plus the ability to freely experiment with near any track without veering off the rails in a way that often feels impossible.

So that’s the playbook, unemulatable as it may be: pick a musical genre that lends itself incredibly well to improvisation, spend four decades mastering it, stand up the requisite streaming/recording/distribution infrastructure, then turn on the recurring SaaS revenue faucet. Most bands simply do play more-or-less the same set for the entirety of a tour, and there’s nothing wrong with that. Those bands just can’t expect their fans to pre-order a whole tour’s worth of MP3s and/or live-streamed webcasts. Phish can, and they unabashedly lean into it. In 2017, they played thirteen straight shows at Madison Square Garden without repeating a single song⁵.

And Phish fans happily capitulate. Here’s a Mashable article from 2018 that, in addition to detailing the evolution of Phish’s digital streaming empire, nicely summarizes the fan mentality:

Each one is unique, and if you’re a fan, you want to hear every possible version of your favorite song, and to collect them all. As a fan of the band for the last 23 years, I’ve been hell-bent on trying.

The author isn’t alone. Phish fans crowdsource song statistics with the fervor of sabremetricians studying nascent baseball defensive metrics.

So while the band is clearly embracing the opportunity in front of them–each performance capitalizing on the chance to produce new differentiated content–they’re only able to do so because they happen to perform in a style that makes their music uncommoditizable. And that’s, frankly, lucky. When Junta debuted in 1989, foreshadowing their trademark lack of brevity with five tracks stretching beyond the nine minute mark, they certainly didn’t foresee each bespoke incarnation becoming an elaborate snowflake sold to voracious adorers over HTTP. This would be a lot harder if they played e.g. three-chord punk rock instead.

Like most software companies with high multiples, Phish benefits from what Stratechery’s Ben Thompson sums up as the effective elimination of marginal distribution and transaction costs brought about by the Internet. Software companies traditionally have high P/E multiples because of this dynamic–there’s a fixed cost inherent in developing an application but no substantive additional cost to onboarding as many new users as possible over time, subsidizing the original expenditures. Phish benefits similarly–while there are certainly some ongoing costs to film and edit each show, the infrastructure exists and they clearly have it down to a science at this point (see: the truly-hard-to-believe turnaround time).

Is Phish’s audience big enough, though? Of course, when the total addressable market is “anyone with an Internet connection.” Ben Thompson, again:

While quality is relatively binary, the number of ways to be focused — that is, the number of niches in the world — are effectively infinite; success, in other words, is about delivering superior quality in your niche — the former is defined by the latter.

And if you’re lucky enough to be the type of person who enjoys Phish’s music, the quality of their offering is undeniable. So much so that they’re able to charge just as much as Spotify does for Spotify Premium. Put another way by Marco Arment:

If you’ll permit a pretty rough analogy, imagine a world in which the vast majority of published fiction was in the form of 3,000-word short stories, and most people had never read anything longer. Phish is the one outlier publishing novels, and they’re pretty weird, complex novels. No effort to condense such novels into bite-sized short stories will truly capture the appeal.

But if you’re one of just a handful of novel publishers in this rough metaphor, you’re going to slowly accumulate a hell of a fanbase from the people who actually like novels, even if yours get a bit too weird sometimes, because almost nobody else is creating what these fans want and love.

Taking a look at Nathan Baschez’s Why Content is King, it’s pretty remarkable how many of the seven power boxes Phish is able to check⁶:

• Scale economics (free distribution)
• Network economies (crowdsourced cataloging by the fan community)
• Counter positioning (producing new differentiated content in a way that few other bands can)
• Branding
• Cornered resource (a monopoly on soundboard-quality Phish recordings)
• Process power (filming/recording/editing/distribution infrastructure)

And if you find yourself thinking that a shrewd move would be to reuse the underlying LivePhish platform for other bands as well, not unlike how Amazon sells access to AWS despite being its first-and-best-customer, the folks behind nugs.net would agree⁷.

At the end of the day, it‘s not lost on me that no amount of strategic novelty will change your mind if you simply can’t stand Phish’s music (and I truly understand why many cannot). But like them or not, they undoubtedly occupy a unique space amongst their peers. The technologist in me can’t help but also take satisfaction in the alignment of their digital offerings with their strongsuits as musicians.

Many thanks to Ben Reubenstein for his feedback on a draft of this post.

“You’re basically not going to be an iOS engineer anymore?”

When my good friend Soroush asked this upon hearing that I had taken a new job at Stripe, I doubt he thought very much about how it’d be received. It really threw me for a loop, however. I didn’t exactly consider myself to be undergoing a career change, but was I? It’s true that I’m not going to be developing for iOS in my new role, but I hadn’t always worked in this capacity at previous jobs either. Did spending the better part of five years focused on iOS make me an “iOS engineer”? If so, when exactly did I become one and when did I subsequently cease to be? Should this kind of designation be descriptive, based on one’s actual day-to-day, or prescriptive, aspirationally describing the work being primarily sought out and anticipated?

Work as a software engineer for long enough and it’s highly likely that you’ll end up having a say over whether or not you go deep on any particular sub-discipline (and if so, which), or choose to primarily float around the surface, swimming back and forth and maybe holding your breath to go under for a bit here and there, but not taking many dives necessitating special training or equipment.

There’s no right answer here, and it’s really not a strict dichotomy anyway.

While programmers can undeniably be either specialists or generalists, there’s a whole lot of grey in the middle. As opposed to inherently being a specialist, it’s also very common to specialize over a period of time. Perhaps this is a subtle difference, but I think it’s one worth teasing apart; one can act in a specialist capacity when the situation dictates - and I presume that effectively every “generalist” does, from time to time - without self-identifying as such for the long haul.

There isn’t a right answer because one isn’t better than the other, but also because many teams should contain both specialists and generalists in order to perform their best work. The best products are often brought to fruition through a combination of generalist thinking and specialist expertise. Only specialists have the domain knowledge necessary to build best-in-breed software that takes full advantage of the platform being built for; given how advanced the various platforms that we build for in 2019 have gotten, it’d be near impossible to sweat all the right details without having first dedicated yourself to fundamentally understanding a particular one’s intricacies. We’re all very lucky that many have.

At the same time, specialists run the risk of “only having a hammer,” and as such, having every possible project “look like a nail.” With only one tool in your belt - a deep but relatively narrow area of expertise - it’s easy to inadvertently build an app that really should’ve been a website or vice versa. Or to have a great idea that you can’t quite realize, despite your excitement, due to it requiring both frontend and backend work. Said idea might be exactly the provocation that can prompt one who has historically specialized to start branching out a bit. But after having done so, are they still “a frontend developer” or “a backend developer”? Clearly, such labels start to lose their significance as we tear down the boundaries defining what we’re able to do, and perhaps more importantly, what we’re interested in doing.

In the Twitter, Slack, and GitHub circles that modern software developers often travel in, it’s easy for a discrepancy to form between how one is best known vs. how they actually view themselves. Tumblr was quite popular during the time that I led iOS development there, which gave me the opportunity to write and speak about the work that we were doing, and even release some of it as open source. These slide decks and blog posts neglected to mention that I was actually hired to be a web developer and only moved over to iOS as needs arose, subsequently parking myself there for a few years to come. I built Rails backends and React frontends at my next job, but at an early-stage company with a much smaller platform, where we primarily worked heads-down without much outward-facing evangelism for our technology. Few knew.

I’m not unique in this regard. One of the best mobile developers from my time at Tumblr has since switched over to the web. Another, an expert in animations, gestures, and UI performance, is now a designer. Since acting as a specialist at a high-profile company can cement your status as such well after you’ve stopped working in that capacity, it’s crucial not to let outside perception prevent you from shaping your career however you see fit.

In August 2014, I gave a talk entitled Don’t be “an Objective-C” or “a Swift Developer” to a room full of new programmers who were learning how to build iOS applications at the Flatiron School. The Swift programming language had been unveiled only two months prior, and reactions amongst iOS developers were divisive, to say the least. Many felt as though it was finally time for a modern language to replace Objective-C, and that such a change was long overdue, while others didn’t believe that Objective-C needed fixing, and would’ve preferred if Apple’s resources and the focus of its community were directed elsewhere. My goal was to try and convince these new engineers that they shouldn’t aspire to land in one camp or the other, but rather to learn the underlying, transferrable programming concepts, and to expose themselves to many different ways of concretely building software. Without understanding what’s out there, how can one make an informed decision as to how they should spend their time? Even if you decide to put down roots in a single community, how can you avoid perceiving the way that that community has historically operated as being the way that it should be going forward?

I feel like I could give this same talk today, to a more experienced set of engineers no less, and simply replace “Objective-C and Swift” with “frontend and backend” or “mobile and web.” The idea is the same - technologies move fast and careers are long, and while you may enjoy being a specialist or a generalist for some time, you never really know when your situation could change and when circumstances may warrant otherwise. Or, when you might simply feel like trying something new.

When I write Ruby, it’s painfully obvious to me that I don’t know Ruby to nearly the same extent that I know Swift. On some days, this makes me sad, but it just as often makes me feel empowered. Perhaps I’ll decide to spend the time needed to achieve Ruby mastery, or maybe I’ll end up retreating back to Swift at some point in the future. Or, more realistically, I’ll get slightly better at the former and slightly worse at the latter and come to peace with that, just in time to shift towards learning something different altogether. In any case, how others describe what I do, and more importantly, how I view it myself, remains a fluid work in progress.

I don’t expect this to change, and this I am at peace with.

Originally published on Better Programming.

A couple of years ago, I asked for a recommendation for a “personal CRM” – a client-relationship management tool intended for individual use. As it turns out, I wasn’t the only one asking, and a solution still hasn’t emerged despite outsized interest from the very designers and developers who should be well-poised to create it. Why?

I’ve come to believe that this is because “personal CRM” means something a bit different to each person who asks for it. To my friend Shane, it’d be akin to a proactive virtual assistant, skewing towards the “magical” end of the spectrum. I myself have envisioned a few different products, all which I’ve lazily described using this umbrella term: one for letting me know when I haven’t seen a certain friend in a while, another for applying “tags” to former coworkers, etc. During my current job search, I’ve needed different tools at different times: one centered around colleague outreach to start, but another for tracking interview processes as the’ve continued to progress.

When faced with a moving target and only concerned with meeting one’s own individual needs, we don’t need an “app” or a “product” per se. A document can be structured in a way that meets today’s needs, with the flexibility to easily evolve as requirements change. My “personal CRM” is currently a spreadsheet – I could’ve built a version using Excel or Google Sheets, but I chose Airtable because it stores data in a more structured, database-like format. This lets me build more powerful, customized views on top of my data.

A database. With custom UI sitting on top of it.

This is “an app,” my friends.

Documents vs. apps

From this perspective, Airtable isn’t necessarily a product in-and-of-itself, but a platform that empowers you to build your own products – and it’s far from the only one. Coda, Notion, Quip, Clay, and Actiondesk are also similar in that they’re democratizing software development under the familiar guise of “collaborating on documents.¹” But their document-sheen is only skin-deep:

A creative palette of app-like functionality that you can mix and match

Build something as unique as your team

We took the quintessential parts of apps and turned them into building blocks for your docs

Our goal is to make it much easier to build software

Forget the back and forth with your tech teams. Build powerful automations yourself

Zapier, IFTTT, and Apple’s Shortcuts focus more on integrations and less on data storage and UI, but they’re also key parts of this emerging space – not all software needs a visual user interface². Even Slack – an enterprise chat application on the face of it, has ingrained itself in no small part due to its integrations platform, allowing teams to build mini-products and workflows that suit their own specific needs.

These aren’t necessarily new ideas – Excel macros and Google Sheets scripts³ are less holistic solutions that nonetheless strive to answer the same question: how can we lower the software development barrier to entry?

Apps for small audiences

Part of what made my own CRM so easy to build was the assumption that I’m going to be the only one who ever uses it. Turning it into a consumer-facing product would be a much taller task, but there’s still a ton of value to be captured by software that’s only used by individuals or teams internal to a company.

Shishir Mehrotra, the co-founder and CEO of Coda, highlighted this very point in a piece titled What Will Software Look Like Once Anyone Can Create It?:

We’ll start designing apps for small audiences, not big. Companies will run on their own apps, hundreds of them, tailor-made for every team, project, and meeting. In this world, there’ll be no such thing as an edge case. All the previously underserved teams and individuals will get a perfect-fitting solution without needing to beg an engineer.

Internal applications also have lower user experience expectations than their consumer-facing counterparts, and are simpler for users to authenticate with. And by providing value, they don’t require business models of their own to justify the upfront development cost.

That doesn’t mean that these hurdles can’t be overcome, however – we may be building some consumer applications without code sooner than we know it. A product like Squarespace could shift ever-so-slightly towards app development, or Google’s Firebase could aim for broader consumer appeal. Bubble is one platform purporting to already facilitate this sort of codeless development experience today. At least in some cases, it does seem to be working.

Another approach: instead of using one app-building “platform”, what if the makers of the future study the skills necessary to combine existing applications together themselves, instead of studying computer science fundamentals? MakerPad is one such example of a program and community attempting to educate in this regard:

While such an approach may not suffice in perpetuity, it could mean the difference between bootstrapping yourself to profitability and prematurely taking venture capital in order to hire an engineering team.

What happens to software developers?

As a software developer, should I find this concerning? I admittedly do not, and think that Steven Sinofsky succinctly articulates why by providing some key historical context:

The layers of abstraction that software developers work on top of are continually changing, but there will always be problems to solve despite moving higher and higher up the stack. Most of the platforms covered in this essay already integrate with the popular services of the moment, but developers will always have an advantage insofar as being able to build their own integrations to augment whatever a platform vendor happens to provide out-of-the-box. Understanding databases makes it easier to create a complex Airtable sheet, just as being familiar with loops and conditionals makes you better equipped to craft a complicated workflow in the Shortcuts app. The line between what is and isn’t “programming” really starts to blur.

Similarly, there has always been a gradient between what can be done without code and when you’ll eventually hit a wall with that kind of approach. Adobe Dreamweaver never quite obviated writing your own custom HTML, did it? I don’t personally foresee this ceasing to be the case.

But traditional software development being long for this world isn’t an excuse not to keep up with the changing times. Adobe’s new XD/Airtable integration might be marketed as a prototyping tool today, but how long will it be until those prototypes are good enough for a single designer to ship as production software?

If you don’t like change, you’re going to like irrelevance even less.

In traditional client-server development, client-side models don’t often differ too dramatically from server-side models.

Should they?

A standard RESTful API might serialize a server-side user model as such:

{
  "id": 12345,
  "firstName": "Bryan",
  "lastName": "Irace",
  "avatar": {
    "thumbnail": "https://some/s3/url/a39d39fk",
    "large": "https://some/s3/url/39fka39d"
  },
  "profession": "Software developer",
  "location": {
    "city": "Brooklyn",
    "state": "NY"
  },
  "friendCount": 40
}

Instances of this same user model type can be vended by multiple routes, e.g.:

1. /me – A route that returns the currently authenticated user
2. /friends - A route that returns the current user’s friends

RESTful APIs aren’t inherently type-safe, so a frontend developer will generally learn that these routes both return objects of the same User type by looking at the API documentation (and hoping that it’s accurate¹), or by eyeballing the HTTP traffic itself.

After realizing this, a type definition like the following can be manually added to your client-side application, instances of which you can populate when parsing response bodies from either of these two routes:

interface Avatar {
  thumbnail: string;
  large: string;
}

interface User {
  id: number;
  firstName: string;
  lastName: string;
  avatar: Avatar;
  profession: string;
}

This shared, canonical User model can be used by any part of the frontend application that needs any subset of a user’s attributes. You can easily cache these User instances in your client-side key-value store or relational database.

Suppose that your application includes the following capabilities (and is continuing to grow in complexity):

1. Rendering user profiles (requires all user properties)
2. Viewing a list of friends (requires user names and avatars only)
3. Showing the current user’s avatar in the navigation (requires avatar only)

Your server will initially return the same user payload from all of these features’ routes, but this won’t scale particularly well. A model with a large number of properties² will be necessary to render a full profile, but problematic when rendering a long list of users’ names and avatars. It’s unnecessary at best and a performance bottleneck at worst³ to serialize a full user when most of its properties are simply going to be ignored.

Perhaps your API developer changes your server to return only a subset of user properties from the /friends route. This is followed by a change to the API documentation and a hope that your frontend engineer notices, at which point they’ll add a new type to the client-side codebase. Perhaps this new type looks something like:

interface SimpleUser {
  id: number;
  firstName: string;
  lastName: string;
  avatar: Avatar;
}

At this point, your frontend will need to:

1. Keep track of which routes vend User instances vs. SimpleUser instances, when processing HTTP responses
2. Have its caching logic updated to support both of these different types

User vs. SimpleUser is admittedly a coarse and superficial distinction. If we add a third flavor to the mix, what would we reasonably name it?

Instead of SimpleUser, we could instead call this new type FriendListUser, named after the feature that it powers. Having separate user models for each use case is a more scalable approach – we could end up with quite a few different versions, whose names all accurately convey intention better than “simple” does:

• FriendListUser
• EditAccountUser
• ProfileUser
• LoggedOutProfileUser

The risk here is that we’re likely to incur a lot of overhead in terms of keeping track of which routes vend which models, and how to make sense of all of these different variants when modeling our frontend persistence layer.

Reducing this overhead by more tightly coupling our client-side type definitions to our API specification would be a big step in the right direction. GraphQL is one tool for facilitating exactly this.

GraphQL

There’s a lot to like about GraphQL – if you’re looking for a comprehensive overview, I’d recommend checking out the official documentation.

One advantage over traditional RESTful interfaces is that GraphQL servers vend strongly-typed schemas. These schemas can be programmatically introspected, making your APIs self-documenting by default⁴. But this is an essay about client-side models, not avoiding stale documentation.

With higher model specificity comes higher clarity and efficiency, the primary downside being the additional work involved to maintain a larger number of models. Let’s dig deeper into how code generation can mitigate this downside.

By introspecting both:

1. Our backend API’s strongly-typed schema
2. Our frontend app’s data needs

We can easily generate bespoke client-side models for each individual use case.

First, we must understand how GraphQL queries work. In a traditional RESTful API server, the same routes always vend the same models. Let’s say that our GraphQL server exposes the following two queries:

1. me: User
2. friends: [User]

While both queries expose the same server-side User model, the client specifies the subset of properties that it’s interested in, and only these properties are returned. Our frontend might make the following query:

me {
  firstName
  lastName
  location {
    city
    state
  }
  avatar {
    large
  }
}

The server will only return the properties specified above, even though the server-side user model contains far more properties than were actually requested.

Similarly, this query will return a different subset:

friends {
  firstName
  lastName
  avatar {
    thumbnail
  }
}

Code generation tools can introspect these client-side queries, plus the API schema definition, in order to:

1. Ensure that only valid properties are being queried for (even directly within your IDE, validating your API calls at compile-time)
2. Generate client-side models specific to each distinct query

In this case, the generated models would look as follows:

// Generated to support our `me` query

interface User_me {
  firstName: string;
  lastName: string;
  location: User_me_location;
  avatar: User_me_avatar;
}

interface User_me_location {
  city: string;
  state: string;
}

interface User_me_avatar {
  large: string;
}

// Generated to support our `friends` query

interface User_friends {
  firstName: string;
  lastName: string;
  avatar: User_friends_avatar;
}

interface User_friends_avatar {
  thumbnail: string;
}

Each of our app’s components can now be supplied with a model perfectly suited to their needs, without the overhead of maintaining all of these type variations ourselves.

Trees of components, trees of queries

User interface libraries like React and UIKit allow encapsulated components to be composed together into a complex hierarchy. Each component has its own state requirements that the other components ideally needn’t concern themselves with.

This is at odds with traditional RESTful API development, where a single route will often return a large swath of data used to populate whole branch of the component tree, rather than just an individual node.

GraphQL query fragments better facilitate the colocation of components and their data requirements:

const FriendListItem = gql`
  fragment FriendListItem on User {
    firstName
    lastName
    avatar {
      thumbnail
    }
  }
`;

const FriendListRow = props => {
  return (
    <Container>
      <Avatar source={props.user.thumbnail} />

      <NameLabel firstName={props.user.firstName}
        lastName={props.user.lastName} />
    </Container>
  );
};

This results in a “query hierarchy” that much better aligns with our component hierarchy.

Just as a UI rendering layer will walk the component tree in order to lay out our full interface hierarchy, a GraphQL networking layer will aggregate queries and fragments into a single, consolidated payload to be requested from our server.

Heterogenous caching made simple

GraphQL is a high-level query language; while you can use it to query a GraphQL server, client-side libraries such as Apollo and Relay can act as abstraction layers on top of both the network as well as an optional local cache⁵.

(Additionally, Apollo and Relay both also handle the code generation and query fragment unification outlined in the sections above 💫)

Traditional client-server applications often end up with logic that looks as follows:

// Check if we have a certain user in our cache
if let user = db.query("SELECT FROM users WHERE id = \(id)").first {
  callback(user)
}
else {
  // Fetch from the network instead
  API.request("/users?id=\(id)").onSuccess { response in
    callback(response.user)
  }
}

In this case, we’re querying for the same user via two different mechanisms: SQL against our local database and a URL-encoded query string against our remote server.

Apollo and similar libraries allow us to more declaratively specify the data that we need in one unified way. This level of abstraction lets us delegate the heavy-lifting – checking whether our request can be fulfilled purely from cache, and augmenting with additional remote data if not.

To continue our example: if you first made a friends query, your cached users would only contain firstName, lastName, and avatar.thumbnail properties. A subsequent me query for one of those same users would hit the server in order to “fill in” the additional properties – location and avatar.large. From this point forward, subsequent friends or me queries could avoid the network roundtrip altogether⁵.

As long as two user models have the same unique identifier, it doesn’t matter which subset of their properties were fetched in which order. Apollo will take care of normalizing them for us.

Sound magical? It certainly can be, for better or for worse. Like all high levels of abstraction, it’s amazing when it’s working and infuriating when it isn’t.

But such is the promise of GraphQL; the sky is the limit for tooling when a typed schema definition is the foundation being built upon. Tooling of this nature can make a premise that would’ve otherwise seemed prohibitively unwieldy – having a distinct client-side model type for every slight use case variation – not only achievable, but ideal.

Yours truly, in January 2013:

Last year I only read two books. I’m disappointed by that, and my goal this year is to read somewhere closer to ten, alternating between fiction and non-fiction. To hold myself accountable, I will try to write a little about each, starting with this one.

I only ended up reading five books in 2013, but read seven in 2017 and seventeen in 2018¹. At risk of jinxing it, I think it’s safe to say that – many years later – I’ve finally adopted a real reading habit for the first time as an adult.

Habits are obviously quite personal, and there’s no shortage of advice out there on how to make one out of reading in particular². Here are the few keys to my own personal success on this front that I hope may prove helpful to you as well.

Committing to a platform

I spent far too long being really indecisive as to whether I should invest in Apple or Amazon:

I eventually committed to Amazon due to Goodreads, local library rentals, and e-ink Kindle devices (more on all of these later). Most important was to simply make a decision, however; I think I’d be doing just fine had I chose Apple instead.

I still prefer Apple for programming books because I find the Apple Books software for macOS to be far superior to Kindle’s desktop web experience, but these are a small percentage of the books that I read overall. I’ve been very happy with Kindle as my default for everything else.

Keeping a streak

If you’re the type of person who finds streaks to be motivational, keeping track of a streak is an easy way to make sure that you’re spending at least a few minutes reading each day. Just five or ten minutes each day is a great place to start; those minutes really do add up, but perhaps more importantly, a streak helps ingrain the habit of dipping into your book during your commute or while waiting in line at the grocery store. Or really, anytime when you might otherwise default to scrolling through Twitter or Instagram.

Allowing myself to take breaks from books

There are some days where I simply don’t want to read a book, but that doesn’t mean I can’t read something else of value. The goal here was to instill a reading habit, not necessarily a book habit.

Maybe I just finished my last book and haven’t decided which my next one will be, or maybe there’s a lot going on in the news that I’d like to catch up on. I use Instapaper to save articles of all different kinds to read at a later date, and on days where I choose to spend at least ten minutes reading these instead of a book, I’m happy to count that against the streak as well.

Using an e-ink Kindle

I resisted getting a dedicated Kindle device until December 2016, primarily because I really don’t mind reading on iOS. I’ve read entire books on iPhones without issue.

I eventually moved to a Kindle as my primary reading device not because I prefer e-ink screens to LCD or OLED, but because I am very bad at avoiding distractions. My Kindle doesn’t have notifications, a web browser, or a Twitter client. I can do nothing but read on it, so read without interruption I do.

Modern Kindles also have the benefit of being quite light and small. I expected to only bring mine along when carrying a bag, but it fits pretty easily in many of my jacket pockets. As such, I’ve carried it far more often than I would’ve originally guessed.

Reading wherever, whenever

Despite having really grown to like my Kindle, it’s only with me a fraction of the time compared to my iPhone. Like with cameras, the best book is the one that’s with you. Kindle sync means that your book is always with you as long as your phone is, even if your primary reading device is not. And as mentioned, I’m definitely not above reading books on my phone.

There are plenty of times where I most certainly do not want to carry anything more than my phone – specifically in the summer – but this doesn’t mean that there can’t still be any number of planned or unplanned reading opportunities along the way.

Drowning out the noise

In the spirit of reading wherever and whenever, it’s often helpful to have something to help you drown out the background noise of your neighborhood coffee shop, or the New York City subway. I’ve been using Brain.fm almost exclusively for the past year but have also used Noizio a lot in the past. They’re both really good at what they do.

Putting a book cover on my lock screen

Whenever I start a new book, I put the book’s cover on my iPhone lock screen³. It’s not exactly subtle, but I benefit from the constant reminder that I could be reading my book whenever I’m tempted to use my phone for something less beneficial.

If you’d like to make your own lock screen wallpaper, here’s the Sketch template that I use.

Using Goodreads

Goodreads is a social network for keeping track of what you and your friends are reading and want to read in the future. It’s owned by Amazon, and as such is able to automatically track any books that you’ve read using Kindle apps or devices.

While the website and iOS app could both use a bit of user interface love, I’ve found it to be a huge help in keeping a reading habit by providing:

1. A steady influx of new book suggestions, specifically from those who share your tastes
2. Encouragement in the form of annual challenges
3. Guilt, if you’ve lapsed a bit yet see all of the books that your friends keep finishing

Renting from the library

Did you know that not only can you borrow physical books for free from your local library, but ebooks as well? More surprising, perhaps: Libby, the iOS app used to do so, is actually quite nice.

The selection isn’t perfect, but I’ve been able to find a lot of books on my reading lists at either the New York or Brooklyn Public Libraries⁴. You may need to wait a few weeks for popular books to become available, but you can put them on hold such that they’re automatically rented once they are. Once rented, you can keep the book for up to 21 days (which I’ve found can serve as a helpful forcing function to make sure you’re moving through it with haste).

These are just a few tactics, but they’ve worked well for me over the past year and I expect will continue in years to come. I still think there’s room for improvement⁵, but the first step to improving a habit is to have said habit in the first place. As of 2018, I can finally say that I do.