Now, the discourse around cross-platform app technologies has traditionally revolved around a simple idea: cross-platform development is cheaper, while native development leads to better apps.

And this is kinda true. Like, it’s true enough for a hand wavey explanation of why cross-platform tools are popular. But it is wrong enough that this mental model tends to obscure exactly why the latest large, profitable company has gone down this path.

I’m still forming my own thoughts around this discussion, but I found this article insightful.

(Via Gus Mueller.)

I’ve been using Apple computers for many years. The first one that I owned was an iBook back in 2003. Early on, I spent a lot of time trying to convince family and friends that Macs were great, and more specifically were a superior choice versus Windows PCs.

Then, in 2007, the iPhone was released.

It required no convincing.

Within that same circle of people, everyone who used an iPhone immediately thought it was an amazing product. They said that in spite of the original iPhone’s severe technical limitations. The iPhone was instantly recognizable as great.

It’s useful to be aware of the difference. At times when pitching products, features, and projects we have to make a convincing case for the return on investment. Other times, the return is as immediately obvious as the first interaction with an iPhone.

The right convincing story either needs to be told or needs to be trimmed.

All journeys of significance have high points and low points. Debugging a difficult problem is no different.

I’ve been at this for a while, but the thrill of fully understanding a problem and the solution after a debugging journey has not worn off yet. Or as a friend puts it, “the one part of this job that never gets old is when things go from not making any sense to making sense again.”

That point is the peak. But to get there requires grit in the valley.

In the valley, things still don’t make any sense. Often it seems there’s no way out.

Press on.

Because as soon as you have exhausted every possibility and absolutely cannot figure it out, you’re close.

I recently spent some time reading up on the Rust programming language. The documentation is superb across the board. But one piece particularly impressed me: rustlings, a series of small Rust exercises to learn the language.

Just like learning a spoken language, the best way to learn a programming language is to really use it (as opposed to only reading about it). The idea and implementation of the rustlings project is a great experience in that vein.

The most important question to evaluate in a potential hire is “are they teachable?”.

By teachable I do not mean “we do everything perfectly here, so they must be able to learn from us.” In fact, that attitude would represent the opposite of teachable.

Beyond a desire to learn, being teachable means being humble enough to consider that you might be wrong. And being open to changing your opinion when that’s the case. That’s a quality critical to both the established organization and the potential hire, assuming both sides want to grow. (It’s also important because software developers are usually wrong before lunch.)

The second most important question to evaluate is “are they stubborn enough?”.

Those two qualities appear to be in conflict. But you cannot solve difficult problems without being exactly the right kind of stubborn. (Sure, the words “diligent” or “persistent” could be used here, but “stubborn” captures the required vigor.)

Be teachable, but don’t forget to also be stubborn.

Tooling to assist software development has never been more available or more advanced. Tools, both commercial and open source, have been purpose-built to identify code that is provably incorrect (and even code that might be incorrect). Some examples of C++ tooling available from LLVM:

• clang warning flags; clang-tidy (C++ linting)
• clang static analyzer (static analysis, naturally)
• clang sanitizers such as AddressSanitizer, MemorySanitizer, ThreadSanitizer, and UndefinedBehaviorSanitizer; -fstack-protector compilation flag (dynamic analysis)

This is a minuscule list in comparison to what’s available from LLVM and elsewhere. The problem is not, therefore, that the tools don’t exist. The problem is not that the tools don’t report any errors when used either.

The problem that I see more often than any other is that developers don’t believe what the tooling reports.

I don’t know why. Is it pressure to ignore all roadblocks in delivering a feature on a deadline? Is it hubris? Laziness? Is it some mistrust of the tooling itself?

I don’t suspect malice. But I don’t know the answer.

Is the tooling always perfect? Absolutely not. That doesn’t change the advice I’m going to offer:

Assume the tool is right.

If you dig into what’s being reported and believe you have a case where the tool is wrong, you should be able to completely explain why it’s a false positive. If you can’t confidently provide that explanation, check the error report again. At some point you will conclude that your code is at fault (almost always the case), the tool is pedantically correct about your code but the consequences are benign (fix it anyway to remove the noise), or the tool has a bug (which you should file).

And if you have a tool that’s consistently wrong, stop using that tool.

It’s all about perspective. A well-built code analysis tool is better than a human at detecting errors. For some, that’s hard to accept.

For others, myself included, we recognize that we need all the help we can get. Start by assuming the tool is on your side. That perspective will let you understand (and benefit from) what it’s telling you.

Robert Mays, in a 2017 profile of Marshal Yanda for The Ringer:

He also is a man of ingrained habits. To hear Wagner tell it, players don’t need a clock to know what time it is in the Ravens’ facility. All they have to do is locate Yanda at a given moment, and it’s obvious. “Hot tub, breakfast—it was the same thing every day,” Wagner says.

[…]

Listening to Yanda talk about the league’s best interior rushers, it’s clear that his homework goes beyond due diligence. It borders on obsession. Each week, Yanda downloads his upcoming opponent’s previous six games to his iPad. With no need for internet connection, he’s able to consume game tape anywhere. “In the corner of the hotel, or the training room, or at lunch, he always had that iPad,” Wagner says. Yanda’s favorite spot is the cloth recliner in his living room, where he takes in about a game a night while his wife, Shannon, watches Nashville from the couch after their three kids have been put to bed. “You never want to be surprised by a guy,” Yanda says. “I want to know every single move that he does. When it’s third down, and they’re down by seven points, and they need to win and get off the field, what is he doing to win? What has he naturally done his entire life?”

Let’s ignore the fact that Yanda played for a bitter rival of the Steelers.

A theme from it has stuck with me since reading it years ago: Yanda’s craftsmanship.

Yanda, now retired, was dedicated to being a great NFL guard. His discipline and his willingness to embrace the grind were exceptional. And while professional football is a wildly different career than software development, craftsmanship translates universally.

The craftsmanship ingredients are always the same: discipline, habits, and focus.

Jason Snell, at Six Colors:

I know you’ve heard it a million times before, so many times that you skim past it when you read it. And you’ll probably do it again this time, but I’ve got to try. I’m looking out for your best interests here.

However much you’re backing up your Mac, you’re probably not backing it up enough.

Purely coincidental timing, but this is a nice addition to the link I posted earlier today.

Adam Engst, writing at TidBITS:

Allow me to update what I consider to be the pieces you can assemble into a comprehensive backup strategy that acknowledges the reality of today’s tech world.

In summary:

• A versioned backup, such as Time Machine
• An offsite backup, such as Backblaze
• A backup device, such as a secondary Mac or an iPad
• Cloud-accessible essential data, such as iCloud Drive for photos
• A nightly duplicate of the primary Mac, via software such as Carbon Copy Cloner or SuperDuper!

I’ll admit I spend a lot more time than the average person thinking about data loss (personally and professionally). But to me, the above list is not overkill. Everyone within the Apple ecosystem should be using the first four, and I strongly recommend all five.

This reminds me of a post from the author of SuperDuper!, Dave Nanian:

Don’t let your data loss story serve as a warning to others. Be the hero who planned ahead and saved your family’s precious photographs.

Scott Wolchok:

Why, in 2021, does anyone need to learn about assembly language? First, reading assembly language is the way to know exactly what your program is doing. Why, exactly, is that C++ program 1 MiB (say) instead of 100 KiB? Is it possible to squeeze some more performance out of that function that gets called all the time?

There’s also an increasingly relevant ARM64 version.

Jacob Kaplan-Moss:

People said I did the impossible, but that’s wrong: I merely did something so boring that nobody else had been willing to do it.

Sometimes, programming feels like magic: you chant some arcane incantation and a fleet of robots do your bidding. But sometimes, magic is mundane. If you’re willing to embrace the grind, you can pull off the impossible.

This is the most important trait of a software developer. The willingness to embrace the grind, every day, is more important than technical knowledge or skill of any kind.

(Via Daring Fireball.)

Apple’s money and resources are effectively limitless. They have the ability to create any piece of hardware or software they desire to create.

Almost.

I don’t think Apple could have made Fantastical, the calendar application that won Mac App of the Year. Fantastical is a great app, but its greatness does not come from being a revolutionary re-imagining of a calendar. It isn’t that. Its greatness does not come from one specific feature that can’t be found anywhere else either.

Fantastical is great because the people who made it sweat the details.

Flexibits, creators of Fantastical, put in the work. They carefully thought through how users would perform each action a user needs to perform with a calendar. They designed an interface with smooth, delightful animations. One that is always responsive to input, and clearly presents the required information. Every user interaction, every interface detail, every small code change that improved performance: they all add up to Fantastical.

The word that keeps coming to mind with Fantastical is polish. This is what the most polished calendar app you could imagine looks and feels like.

Apple sweats the details on a lot of things. But “polished calendar app” is not going to sell a new iPhone (and thus won’t receive the engineering resources to make it happen). The target they’ve chosen for most of their default software is “good enough.” That creates an opportunity to create something for users who want more than “good enough.” A subset of users want the best calendar app.

Like Apple, we can’t focus on every detail of every project. But like Flexibits, we can seize opportunities to sweat details that others don’t.

First ask where you can sweat the details. Then ask where you should.