It fills me with ghoulish glee to summon forth the October Flight Deck, a chilling compendium conjured to bewitch our readers with eerie incantations and morbid meditations on the shadowy realms of mobile software engineering and the dark rites of release management. Step cautiously into these paragraphs to uncover more, but beware this forewarning: today’s newsletter is stalked by phantoms and cloaked in moonlit dread.

We considered writing the entire newsletter using Halloween-inspired copy, but it’s perhaps a little too early in October for us to go all in like that, and we don’t know enough spooky words to make it work. Instead, you’ll find the rest of this newsletter written in the usual Flight Deck style as we cover Linear’s commitment to a zero bugs policy, why you should stop wasting context on build output, and the hidden costs of mobile releases.

Read on for this month’s highlights.

Posts we liked

The time investment paradox: why developers won’t pay for what they can build

The only thing developers love more than spotting and fixing inefficiencies is inefficiently creating new inefficiencies. When given the choice of buying a tool that could erase hours of busy work, we’d often prefer to put in many additional hours of busy work building our own bespoke solution, happily burning weekends on home-rolled fixes that only partially work instead of paying a few bucks for something proven. It’ll be fun! Pedro Piñera examines why you shouldn’t build it just because you can.

Stop wasting context on build output

Scarlett Johansson is very compelling in Her, and my Waymo is an incredible driver. But these are not people, we shouldn’t think of them as people, and we ought not treat them like people. This extends to our interactions with AI coding agents. While it’s helpful to provide verbose context to other developers so they can more easily figure out what’s going on, all that gets you with a coding agent is wasted tokens. Łukasz Domaradzki explores how to make build output more AI-friendly with structured data.

Why Linear is committed to maintaining a zero bugs policy

Can you imagine if structural engineers “shipped” the Golden Gate Bridge with a bunch of bugs that they were going to get around to fixing later, after finishing another bridge or two? The only form of engineering where it’s acceptable to have bugs is software engineering. But Linear doesn’t think it’s acceptable. That’s why they maintain a zero bugs policy. Like all developers, they ship plenty of bugs, but no matter how minor, they don’t let those bugs sit and wait to be fixed. Learn how Linear turned zero bugs into a key value.

How I influence tech company politics as a staff software engineer

You probably hate office politics, but would also like to see more things you want to work on get worked on. You could expend a lot of energy demanding that these things get built, or spend years working your way into management and then into leadership, where you can have a say in the planning. Or you can do what Sean Goedecke argues, which is to let executives do their thing and then tailor your own backlog of priorities to fit their goals.

Apple’s quiet shift to Rust: what it means for developers
Orgs like Microsoft, Google, and AWS have been both quietly and loudly embracing Rust over the past few years. Now Apple is joining them. They are not throwing Swift away and rewriting iOS; instead, they are working to evolve it. Goktug Aral examines how Apple utilizes Rust to enhance security and reliability, improve performance, modernize internal code, and boost developer productivity.

Go figure

Did you know that better, centralized tooling could resolve 63% of all incidents related to releases? That’s not just us saying that; that’s the most common answer given by the hundreds of software developers we surveyed for our State of Mobile Release Management report.

Posts we wrote and events we're hosting

[Live event] Mobile DevEx: the hidden cost of releases

In this live discussion on Oct 9th (that’s tomorrow!) at 1pm ET, experts from Runway, Sentry, and leading mobile teams will unpack why automation hasn’t solved release pain, how constant firefighting affects both morale and velocity, and what steps you can take to improve DevEx around releases.

Why fully automated mobile releases aren’t the answer

In this post, we rise against the machines to explain why no amount of automation can completely take over the complex array of decisions and actions your team needs to make as part of every release. It’s essential to find the right balance of tooling and processes to support your human team members, rather than assuming you can automate their (and your) challenges away.

Runway featured feature

Automation may not be THE answer for your releases, as our blog post above argues, but it is still AN answer that can be pretty helpful for some fairly obvious reasons. That is why it’s a significant focus here at Runway.

Building on other recent changes to event timelines in Runway — the revamped, dedicated timeline view, filtering, and additional events — we’ve now expanded the footprint of automations in timelines.

We recently reworked all of Runway’s available automations to ensure each one is fully captured in timeline data — whether one-off and release-level, or recurring and app-level. We also expanded the kind of data that’s captured and surfaced to ensure you have full context alongside every automation run. In addition to including more info around status, Runway also saves and surfaces the exact settings that were configured at the time the automation ran.

Events

Looking for Runway? We are at SwiftLeeds, right now, for like thirty more minutes. Run over there to see us!

If this is too late for you to get over there, you can slowly stroll from Leeds down to London and meet us there on Oct 30th to 31st for the spookiest event in all of mobile software development: droidcon London.

Thus the 26th Flight Deck is laid to rest. Should you wish to commune with the past, open the tomb and revisit any of the 25 editions that came before.