In the spirit of Marshawn Lynch, I’m showing up because the Captain said I had to do this 30 days in a row.

When I got started, I didn’t know a damn thing about software engineering.

It was 2001. I’d just earned my Computer Science degree and was starting my first job. I’d taken the one software engineering course my university offered. I thought I was ready for any coding task they could throw at me.

I couldn’t have been more wrong.

The best thing you can do for your software engineering ecosystem is to add constraints.

What do I mean by constraints?

Anything that limits the degrees of freedom you have when building a software system.

Our industry is possessed by a deadly cycle.

As we build software systems, we always run into complexity and problems. We see happier teams using a shiny new technology, and we run away to its greener pastures. Eventually, we discover the same complexity and problems that made us run away in the first place.

When you hear the word fall, you probably think of a downward motion.

Fall is almost always followed by down. Gravity, which causes objects to free fall, is intuitively understood as a downward force. Even our Fall season takes its name from the annual phenomenon of dead leaves falling down from trees.

About a month ago, I decided to give myself a firm kick in the ass to get back into writing.

I needed some skin in the game, so serendipity sent me Ship 30 for 30. I was so impressed I made two big bets: money and time.

If you’ve been a software engineer for very long, you’ve probably worked on a codebase that’s seen better days.

It’s not clear where the next feature should be added. Some components do too much, and some components do too little. Every change you make seems to break something else. Writing software has transformed from delight to drudgery. Your task list has become a toil list.

Do you really understand single points of failure?

A Single Point of Failure (SPOF) will cause an entire system to fail, even if it’s the only broken component. The Power of Multiplying By Zero is a mental model we can use to better understand SPOFs.

You’ve finally made it. You’ve been promoted to Enterprise Architect.

For many, this is the pinnacle of their career. For most, they arrive in their new role with an existential question:

What do I do?

Builders run into problems. If there’s anything a product team should be good at, it’s solving them!

But most of us rarely spend time sharpening our problem-solving saw.

Enter the concept of mental models.

I did not want to write today. I still don’t.

Today is supposed to be a perfect day. A “Perfect 10.” The tenth consecutive day that I’ve published as part of Ship 30 for 30.

As I began my deconstruction journey, I started asking a lot of questions. I had so many that I organized them with a Trello board. As I studied the board, one of the questions leaped from the screen:

Is the Bible inerrant and infallible?

In 2015, I made $18,000 from a 56-page O’Reilly book titled Migrating to Cloud-Native Application Architectures.

Time clocked from the first word typed to publication? 40 Hours.

I’m not here to sell you a magic formula. A surface-level analysis might suggest this was nothing but dumb luck. But it would be wrong.

Your technology organization cannot afford unlimited innovation.

Dan McKinley coined the term innovation token to model this concept. Every organization gets a fixed supply of approximately three innovation tokens, and it can spend them on anything. As your organization grows in maturity, you might earn a few more tokens. But for the foreseeable future, the supply is fixed.

In 2008, I believed the only way to save a critical software system was to rewrite it from scratch.

I had just been promoted to engineering manager of my team, and that system was our biggest project. And it was in trouble. I knew we had made a lot of mistakes along the way. Now that I was “in charge,” I was going to fix everything.

That rewrite almost failed, and I nearly got myself fired.

Today, I’ll teach you how to leverage The Slider Bar Principle to make better software architecture decisions.

The Slider Bar Principle teaches us that most software architecture decisions are fuzzy rather than binary. That is, the possible choices lie along a spectrum.

Great software engineering teams recognize the primacy of principles.

A few decades ago, everyone wanted to visit Toyota. It had become the canonical example of a great manufacturing company. And Toyota invited everyone to visit, even its competitors.

Why?

What is a great software engineering team?

It routinely delivers differentiated value to its customers.

It can go fast forever.

It can respond to changing market conditions and move in the right direction.

It can deliver software that runs on day one and keeps running on day two.

I remember sitting in London City Airport at 5:00 AM, watching TV through a coffee-fueled haze as the 2016 U.S. presidential election returns scrolled across the chyron.

The impossible was now something I had to accept.

It’s Day One of shipping an Atomic Essay every day for 30 consecutive days. Ship 30 for 30 gave us a recommended day one prompt, and I am here for it. So why are we going on this journey in the first place?

I really needed a firm kick in the ass to get back into writing.