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 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.

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.)

Soroush Khanlou:

As a professional programmer, there are two main types of tasks you work on. I’ve started thinking about them as the context and the logic. […]

This framing, context vs logic, illustrates two things for me:

First, that we all tell ourselves a lie: this job is primarily about the logic, interview candidates should mainly be tested on their ability to think about the logic, a “good” programmer is someone who can write the logic really well. In fact, an overwhelming amount of the job is making the context work. […]

I’m primarily a context programmer. I wish I weren’t — I enjoy writing the logic a lot more — but it is the reality. I should embrace that and treat the context as my job, rather than as an impediment to “my real job”.

Second, if you can make your context simpler and smaller, you can spend less time on it.

(Via Michael Tsai.)

Joel Spolsky:

The “cost” of code inventory is huge. It might add up to six or twelve months of work that is stuck in the assembly line and not yet in customers’ hands. This could be the difference between having a cutting-edge product (iPhone) or constantly playing catchup (Windows Phone).

A great line when it was written in 2012, now aged to perfection.

The reason I’m linking to this article though, is the timeless wisdom about bug tracking that has stuck with me since the first time I read it:

At some point you realize that you’ve put too much work into the bug database and not quite enough work into the product.

• Suggestion: use a triage system to decide if a bug is even worth recording.
• Do not allow more than two weeks (in fix time) of bugs to get into the bug database.
• If you have more than that, stop and fix bugs until you feel like you’re fixing stupid bugs. Then close as “won’t fix” everything left in the bug database. Don’t worry, the severe bugs will come back.

Brent Simmons:

I don’t know about other senior developers, but I can tell you about me. I have decades of experience and an amount of wisdom. I’ve written some bad, some good, and a couple great apps over the years.

But I’m no Jedi.

Chris Liscio:

Despite my long history of writing (and debugging) pretty “hardcore” software for Mac and iOS, I still managed to miss a (now-)obvious red flag in my configuration.

We’re all just a bunch of dummies flailing about wildly out here!

Years ago a similarly “hardcore” developer told me that if he gets to lunchtime without realizing he made a colossally simple mistake, the day is a win. Count me in with him, Brent, and Chris: nobody knows it all, and sometimes we even miss things that we do know.

There’s a lot of peace to be found accepting that this happens to everybody.

I haven’t written much code in Swift. But as a C++ developer, I found John Sundell’s interview with Dave Abrahams (recommended by Michael Tsai) on the Swift by Sundell podcast fascinating.

Abrahams, on first encountering the C++ STL:

But there were no libraries. And when the STL came along, it really changed my life, because not only did it give me some tools that I could just use, but these tools were composable in a way that I had never seen before.

[…]

They were documented in a way that you could really use these components without looking inside them at their implementations. And they provided kind of a framework for thinking about a whole range of problems.

I never programmed in C++ without the STL being available. It’s so fundamental to my personal notion of ideal C++ code, I cannot imagine writing C++ without it.

On value semantics:

The other aspect of protocol-oriented programming that I left out was how it enables polymorphism with value semantics. And when I say value semantics I mean something very specific. There are functional programming languages where everything is immutable. And those are all values. But that’s not what I think of as interesting value semantics. Interesting value semantics is mutable value semantics.

Later:

One of the fundamental sources of bugs that we have in software today is shared mutable state. It’s terrible for threading, and it’s sort of an invitation to race conditions if you’re doing multi-threading. But it’s also just a source of bugs in regular code. I mentioned functional programming languages deal with this by making things immutable. Which is a really interesting approach, but it’s really costly. Because, the basic model of your machine is one with mutation. You’ve got a memory and you can write to it, right? So what happens when your language takes you a good distance away from the machine model? That means that the compiler has to do a huge amount of work to recover the efficiency of using the features of the machine.

If you are interested in language or library design, give this episode a listen.