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.

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.

5 common themes

Been thinking about what needs to be in place for engineers to ship with confidence

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% 🤘

Swizec reveals the hidden pitfalls of overusing the DRY principle in coding, leading to bad abstractions. Discover how to write adaptable, efficient code that avoids these common traps.

This talk from C3Fest summarizes the key lessons I've learned in the past ~15 years of working in tech startups. It's a high level overview of a new book I'm writing (60% done).

Here's a trap that talented engineers fall into all the time. It creates frustration, burnout, and the genre of tweets that read like "Why don't people care about the amazing work I'm doing".

Here are 6 books I'd buy every engineer who joins my team, if I ran a team. You might like 'em too.

Not everything needs to work forever. Start by solving the problem

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.

Solve the problem at hand, not the one you imagine might come next. A simple fix now often beats a complex one later.

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.

When you're in a company desperately trying to meet demand, *ship*. You'll have money, time, and professionals to fix code later. Even if you start with jQuery.

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 👇