The website vs webapp debate is at least as old as my career. And it keeps coming up. One camp says "React is too complex you don't need any of that", the other camp goes "I don't understand how you live like this". Both are right.

A reader asks how do you find time for technical cleanup work. If OKRs and bugs take priority, when will you make improvements?

The trick, then, is to keep related code close together to reduce context boundaries and to limit the amount of relevant detail so it fits in your working memory.

I guess if AI is what it takes to finally get people to care about architecture and team structure then mission accomplished?

Younger engineers keep asking how I prioritize in a chaotic environment. Here's my approach.

A hard-won lesson for ya: Always deploy when you've got lots of traffic.

Tests may look like slop, but make them clear, not clever. Best practices are key: Test outcomes, not code. Name with intent. Keep tests independent. More straightforward tests beat fewer abstract ones.

A few engineering principles I aim to instill in every team I join. Lead or not.

It takes about 3 years to experience the consequences of your own decisions.

The best part about writing is that you get to learn new and exciting ways you were wrong. Databases are smarter than I thought!

You've heard that array or list columns in a database are bad. But why? Yesterday it clicked for me

Going from Big Vision to Series of Executable Steps is a key skill for senior+ engineers. PMs can help but they don't know everything.

Hardcoding logic when you're tight on time doesn't need to make a mess. You can build the abstraction first!

Accelerate is the empirical research behind books such as The Phoenix/Unicorn Project and (parts of) Software Engineering at Google. I loved it.

Task queues have been on my mind lately so here's a little primer on what they are, how they work, and why you need them when your project starts to grow.

Here it is: 20+ years of programming experience distilled into 378 words. From the book I'm writing.

Here's an approach to writing code that I've been using for years and couldn't quite put into words until now. One of those _"This feels wrong but I can't explain why"_. Now I can!

Few of your engineering decisions matter long-term. Software is soft. You can change your mind. But how you structure your components is here to stay.

As long as it works, right?

A coworker asked how React Islands work and I realized it's a technique I've been using to modernize monolithic web codebases for years, but never wrote down how it works.

Pulling modules out of a big ball of mud is like grabbing a slice of cheesy pizza. It's kinda separate but also not really.

Here's a short and sweet story about a Friday deploy. I love Friday deploys.

Forget Gang of Four, here are the 7 architectural patterns real programmers use:

At scale there are no rollbacks and no cut-overs. Your software only moves forward.

You can't prevent bugs. You'll burn out. Instead focus on making them quick to fix.

Manny Lehman was one of the first to notice that software is never done. It just continues to evolve forever.

A small improvement that lands is better than a large improvement stuck in review

A long design phase without shipping kills many software projects. Here's a story from production I haven't shared before.

You can't fix everything. Focus on the next big thing and let the small fires burn.

Making small changes in large unfamiliar codebases is the job. That's what engineers do all day.

Yes SQL is super flexible. That is its strenght and its weakness

Never underestimate the power of good marketing for bad products. NoSQL was fun but SQL is here to stay.

Removing a single line of code slashed database CPU usage by 66% 🤘

The actor model is now part of everyday tooling and ensures concurrency safety. Understanding the principles behind it helps you write less buggy code.

You can classify software projects into 4 quadrants from trivial to complex

You're doing too much. Sit back, relax, see how people *want* to use the code. THEN build the abstraction.

I asked engineers how they keep a high quality culture. These are the takeaways

TypeScript may streamline code navigation and catch semantic errors, but it doesn't guarantee fewer bugs or faster fixes.

Regular software updates may seem tedious, but they save you from the nightmare of a massive overhaul down the line.

Shared state in programming isn't the enemy, it's unclear dependencies that tangle your code. Keep it clean with explicit state dependencies and strict access guidelines

Detangling a Big Ball of Mud is hard. You have to find domain boundaries where none exist. Looks like AI can help 🤩

Why are utility files bad? How do you recognize architectural complexity? What the hell is a transitive dependency?

Clean code matters, but it's the architectural complexity that truly impacts your productivity and bug count. Focus on simplifying the system, not just the code.

Different lenses, different worlds. Your perspective is shaped by your experiences. Even in debates, all sides can be right in their own context.

Rewriting code isn't a magic fix-all. Consider the opportunity cost, complexity of the old system, and estimation challenges. Instead of stopping all to rewrite or building new while maintaining the old, try incremental improvements and new code adoption.

Delete code when it stops providing value 💡 All code is a liability; context matters. Keep what solves problems, toss the rest.

Focus on solving problems, not just doing work or writing code. Think creatively, question existing processes, and prioritize effective outcomes

Unravel the hidden costs of architectural complexity in software engineering and learn practical strategies to tackle it. Boost productivity, reduce defects, and improve staff retention with insights from an MIT PhD thesis.

Complicated code slows down junior devs, while complex systems impact senior devs more. Focus on managing system complexity & dependencies, not just simplifying code.

Unlock the secrets to combating architectural complexity in software development and learn to identify and fix the wrong abstraction. Boost productivity, reduce bugs, and retain more staff.

What is the essential difference between DRY and SoC principles in software engineering and how do you balance the two

Wherein I use LEGO to talk about organizing your code for ease of use

Some people like to organize code in files and folders and neat categories. Others love search. When they work together, that's the challenge.

The quickest way to simplify a complex function with lots of logic is to turn it into data. A lesson from production

My favorite mistake to make when I'm in a hurry is to think that I _have to_ build new features the sloppiest way possible. Find the quick fix and move on. But that's not true.

In 2015 a group of researchers asked 59 experienced engineers at Microsoft "What makes a great software engineer?". Here's what they found.

Writing software is a playful process of exploration and discovery. Like a game of kick the can on a Sunday walk.

Spaghetti code – unstructured Ravioli code – too structured Lasagna code – layered wrong Minestrone software – unclear domains

Do you review refactoring pull requests differently than you do others? An empirical study of OpenStack, an open source cloud platform, says that you do and finds 6 common criteria.

Would you rather work with a complex system or a complicated system? 🤔

When I first picked up Software Engineering at Google I thought it was another one of those FAANG books full of lessons that make no sense at human scale. I was surprised, lessons apply to teams as small as 5.

Ok so I've been doing lots of research into the Software Engineer job market – Some highlights 👇