Spooky Software

We are stuck with technology when what we really want is just stuff that works.

— Douglas Adams

The technology industry is obsessed with capturing and bottling magic. The VC-fueled segment with which I’m most familiar, in particular, aims to captivate consumers with technology that is constantly visible and engaging. Marketing sites and product decks are rife with phrases such as “grand central” and “the platform hub” for this or that. Tech is touted as the magic charm that everyone will drive to move the next-gen economy. Even businesses that don’t need venture capital are selling this kind of magic: for example, Apple will soon ship an AR/VR appliance that literally takes over our vision and is supposed to re-enchant everything before our eyes. In order to meet today’s financial and social pressures, modern tech business has cultivated a “type.”

Is there room for a different take on magic: one featuring the disappearing act? An overlooked aspect of technology is its ability to become invisible infrastructure and reward us in ways that flashy solutions do not. This kind of magic would not be about doing more: it’s a vision of doing the same with less. Things that don’t require constant attention are magical because they free us to focus on more demanding and important issues in our lives. I don’t think about memory management in the Linux kernel, interact with SSL handshakes, or engage with the software that handles my paycheck. If I step back for a moment and think about what these solutions are doing for me, I am amazed and grateful because I get to spend more time with problems technology can’t help me with. Even if it’s utilizing “boring” technology that doesn’t make the news, if the magic is done well, nobody will even notice at all; products don’t have to be everything to everyone to be exciting.

Solutions that are fueled by or sell “user engagement” are threats to our focus and attention. We only have so much mental headspace and time, so we should take great care with them. To that end, I’d like to see software actively disappear. I don’t want more subscription-based SaaS tools that I need to interact with every day or more apps that prey on my attention for clicks and ad revenue. I see this as a goal for not only end users of technology but also its creators and maintainers. What’s more magical than a piece of code that never needs to be updated or migrated? I want to see more buzz for ideas such as self-healing code that runs forever and funding for projects that are simple enough to actually complete without endless “improving.”

Our ambitions and energies could be utilized for truly magical ends if we re-imagine what technology is capable of.

[I am] Becoming more and more aware that languages in the ML tradition (Haskell, Rust, OCaml, etc) are about a certain kind of linguistic game that the developers have fun playing, and not because it makes any software arrive quicker, behave righter, perform better, or last longer.

— Chris Done, on Twitter

I am excitedly digesting this year’s Strange Loop presentations. Usually Strange Loop focuses on theoretical topics ranging from protocol correctness to well-formed type systems. However, in 2022, I am delighted to see talks on more “practical” concerns of writing and operating software. In particular, Jack Rusher in “Stop Writing Dead Programs” and Jean Yang in “Building Observability for 99% Developers” delivered funny, helpful, and insightful presentations. Though they spoke on very different topics, I was inspired by a common thread: they both rejected a deeply ingrained principle in software development today — that software can, and should be, “verified” before being shipped to users.

I think that the pursuit of perfect pre-deployment verification and “correctness by construction” design is dangerous and distracting in the context of writing and operating “long-running processes,” such as web apps and SaaS-y servers. It seems to me that experienced engineers already admit that fully verifying the correctness of today’s programs is not practically possible, yet this idea still dominates what is considered to be “best practice.” Moreover, I find that this approach has insufficient impact on software quality. If we want to improve the services we provide to our users, we need to instead reorient development ecosystems towards working with running software. Our tools for dealing with runtime complexities are sorely lacking.

Organizations that move our soul have a clear vision — a vision that elevates the mundane and repetitive into something exciting and life-giving.

— Chris Baca, on cultural fit in the workplace

As I gain more experience in the tech industry, I’ve been thinking more about what it means to be a leader. How does one lead well across the spectrum of roles — as staff engineer, tech lead, CEO, manager, or others? How does one do a good job, and what does success look like? Here are some “resume pieces” that I often encounter as characteristics of a good leader in technology:

• Intimate industry knowledge and domain expertise
• High degrees of technical proficiency
• Passion and drive
• Strong networking skills and industry connections
• Creative and unconventional thinking

These attributes are useful tools to have for any successful venture, but I think they also miss the point. I could possess all of these, yet they wouldn’t reveal whether or not I’m capable of leading work that matters. If we focus too much on the project’s technical soundness, operational efficiency, or even profitability, then we can become confused about what we’re doing and whom we are doing it for. Instead, we need leaders who possess qualities that inspire mission-driven work that is grounded ethically. A clearly defined ethical mission elevates work beyond simple TODOs and business milestones and ultimately, makes the project meaningful.

If software abstraction actually worked the way people pretend, then the “higher-level” you go, the more insulated you would be from implementation. Javascript in a browser would be the most stable, robust, unperturbable software, because it’s so fully separated from the machine.

— Jonathan Blow on Twitter

Software productivity feels to me like it has lost its way. “High-level” programming languages from the 1990s and 2000s have left a burdensome legacy that engineers are ignoring. Despite having all these grand tools and languages, the actual output of our software, in terms of features, capabilities, and robustness, is at a low point. All the while, the number of lines of code that we write is just continuing to grow. I think that, instead, we should be taking a step back and reevaluating our return on investment.

Hello world!

fn main() {
  println!("Hello world!");
}

main :: IO ()
main = putStrLn "Hello world!"

console.log("Hello world!");

IO.puts("Hello world!")