I don’t want to go back to floppy disks. I like fast updates. I like security patches. I like sync. I like crash reports when they help fix real issues.

What I want is for “phone home” to be treated like a privileged capability, not an assumed right. In other domains, we treat privileged capabilities with care. We put them behind intentional choices. We build guardrails. And we treat abuse as a bug, not a growth opportunity.

What we don’t yet know is how architectural coherence evolves over years in a fully agent-generated system. We’re still learning where human judgment adds the most leverage and how to encode that judgment so it compounds. We also don’t know how this system will evolve as models continue to become more capable over time.

What’s become clear: building software still demands discipline, but the discipline shows up more in the scaffolding rather than the code. The tooling, abstractions, and feedback loops that keep the codebase coherent are increasingly important.

Our most difficult challenges now center on designing environments, feedback loops, and control systems that help agents accomplish our goal: build and maintain complex, reliable software at scale.

There's this very vocal camp of engineers on the internet who like to say things like "it was never about how fast I can type code" and share visceral takedowns of how sloppy and terrible vibecoding and agentic engineering codebases become over time.

I agree with their observations: over time, every vibecoded piece of software I've built becomes shelfware, artifacts of code which served a purpose but is no longer needed.

But I've been programming computers long enough to know that concerns about architecture and sane codebases end up bugging people so much that they invent new techniques to address them.

I am approaching agentic engineering just like I approached using a chainsaw for the second time in my life a couple weeks ago: by consuming a lot of videos and blog posts on how other people are doing it, and then running controlled experiments to see what works for me.

Early on, I picked up the habit of checking with him when some technical thing or other wasn’t working the way I expected:

• “I can’t connect to the thingamabob :(”
• “The whatchamacallit isn’t working :(”
• “How do I fix the doohickey?”
• etc.

Without fail, James’s response would be not an answer but a question, one that has shaped my thinking ever since:

What have you tried?

I just stuck that on post it note and stuck it to my monitor for tomorrow morning.

During the peak of mobile app madness, iOS and Android developers would often find themselves cornered by friends, relatives, and random people at parties.

“I’ve got a great idea for an app…”

More often than not, this dreaded sentence would be followed by a hard sell when the developer didn’t display adequate enthusiasm. If the developer didn’t act fast and feign the exact right level of approval — enough to communicate they ‘got’ the idea but not so much that they’d be asked to build it — the idea guy would advance onto hashing out NDAs, equity allocations, and asking when coding can start.

Recently, I’ve noticed the AI era is a bit different. The balance of power has shifted. Builders need domain experts as much as domain experts need builders.

You can no longer simply copy an app model with a few improvements or obsess over user feedback as you sharpen your prototype towards product-market fit.

To build a differentiated AI product you need training data and examples curated by a domain expert.

I don't think the role of a software engineer is going to go away, but I do think personally, I'm not gonna cut it anymore as "just a software engineer."

The real value is in pairing someone who knows how these AI systems work with someone who knows how to get deep with a real world problem.

This article explains how database indexing works in a way that feels hyper-targeted toward me: using a database filled with Pokémon.

A lot of technical people got really attached to our identities as smart kids. The software industry tends to reflect and reinforce this preoccupation at every turn, as seen in Netflix’s claim that “we look for the top 10 percent of global talent” or Coinbase’s desire to “hire the top 0.1 percent.” I would like to challenge us to set that baggage to the side and think about ourselves as normal people.

It can be humbling to think of yourself as a normal person. But most of us are, and there is nothing wrong with that. Even those of us who are certified geniuses on certain criteria are likely quite normal in other ways—kinesthetic, emotional, spatial, musical, linguistic, and so on.

Software engineering both selects for and develops certain types of intelligence, particularly around abstract reasoning, but nobody is born a great software engineer. Great engineers are made, not born.

I read this article twice last night. I haven't come across any article that spoke to my massive professional anxieties/impostor syndrome as well as this one.

One of my biggest pet peeves with being around smart people is when people explain things using big words. It feels like it takes so much more effort to understand tough concepts when they are saddled with jargon and ACT words.

I also enjoyed this point about building teams:

We place too much emphasis on individual agency and characteristics, and not enough on the systems that shape us and inform our behaviors.

I believe a whole slew of issues (candidates self-selecting out of the interview process, diversity of applicants, and more) would be improved simply by shifting the focus of hiring away from this inordinate emphasis on hiring the best people and realigning around the more reasonable and accurate right people.

It’s a competitive advantage to build an environment where people can be hired for their unique strengths, not their lack of weaknesses; where the emphasis is on composing teams; where inclusivity is a given both for ethical reasons and because it raises the bar for performance for everyone. Inclusive culture is what meritocracy depends on.

Originally adapted from Ron Miller's Advanced Improv Practice Guide, and discovered at the bottom of jyn's incredible blog post titled "i'm just having fun", which is a must-read.

Before starting your daily practice routine, read and seriously consider the following:

A. DAILY AFFIRMATIONS

1. How fortunate I am that in this life I am one who has been allowed to create beauty with computer.
2. It is my responsibility to create peace, beauty, and love with computer.

B. I WILL BE KIND TO MYSELF

1. IT IS ONLY COMPUTER
2. No matter my level of development in computer, how good or bad I think I am, it is only computer and I am a beautiful person.
3. I will not compare myself with my colleagues. If they do computer beautifully, I will enjoy it and be thankful and proud that I live in fellowship with them.
4. There will always be someone with more abilities in computer than my own as there will be those with less.

C. REASONS TO DO COMPUTER

1. To contribute to the world's spiritual growth.
2. To contribute to my own self-discovery and spiritual growth.
3. To pay homage to all the great practitioners of computer, past and present, who have added beauty to the world.

D. RID YOUR SELF OF THE FOLLOWING REASONS FOR BEING A PRACTITIONER OF COMPUTER

1. To create self-esteem
2. To be "hip"
3. To manipulate
4. To get rich or famous

Here’s the paradox that makes this pattern particularly poignant. We’ve made extraordinary progress in software capabilities. The Apollo guidance computer had 4KB of RAM. Your smartphone has millions of times more computing power. We’ve built tools and frameworks that genuinely make many aspects of development easier.

Yet demand for software far exceeds our ability to create it. Every organization needs more software than it can build. The backlog of desired features and new initiatives grows faster than development teams can address it.

This tension—powerful tools yet insufficient capacity—keeps the dream alive. Business leaders look at the backlog and think, “There must be a way to go faster, to enable more people to contribute.” That’s a reasonable thought. It leads naturally to enthusiasm for any tool or approach that promises to democratize software creation.

The challenge is that software development isn’t primarily constrained by typing speed or syntax knowledge. It’s constrained by the thinking required to handle complexity well. Faster typing doesn’t help when you’re thinking through how to handle concurrent database updates. Simpler syntax doesn’t help when you’re reasoning about security implications.

Big O notation is a way of describing the performance of a function without using time. Rather than timing a function from start to finish, big O describes how the time grows as the input size increases. It is used to help understand how programs will perform across a range of inputs.

In this post I'm going to cover 4 frequently-used categories of big O notation: constant, logarithmic, linear, and quadratic. Don't worry if these words mean nothing to you right now. I'm going to talk about them in detail, as well as visualise them, throughout this post.

I have a minor in computer science, and I remember sitting through many explanations of the importance of Big O notation, yet it hasn’t really mattered much in my career until recently.

If you have heard of Big O but aren’t clear on how it works, give this post a shot. It contains a lot of great visualizations to help drive the point home.

Too many bangers to pull out of this one. Well worth a full read. But here are a couple juicy pull quotes to whet your pallette:

Programming lures us into believing we can control the outside events. That is where the suffering begins. There is something deeper happening here. This is not just about software.

I believe sometimes building things is how we self-soothe. We write a new tool or a script because we are in a desperate need for a small victory. We write a new tool because we are overwhelmed. Refactor it, not because the code is messy, but your life is. We chase the perfect system because it gives us something to hold onto when everything else is spinning.

I’m trying to let things stay a little broken. Because I’ve realized I don’t want to fix everything. I just want to feel OK in a world that often isn’t. I can fix something, but not everything.

You learn how to program. You learn how to fix things. But the hardest thing you’ll ever learn is when to leave them broken.

And maybe that’s the most human skill of all.