Posts

Egoless Programming #1: Understand and Accept That You Will Make Mistakes

Published by Matt Stine

In 2001, Lamont Adams of TechRepublic chiseled what would become ten commandments of Gerald M. Weinberg’s timeless wisdom: Egoless Programming. Today we’re going to learn it’s first commandment: Understand and accept that you will make mistakes. This one should be obvious. But we engineers often behave as if our fallible human nature does not extend to our chosen craft. And as much as I’d love for that to be true, it simply isn’t.

The Ten Timeless Commandments of Egoless Programming

Published by Matt Stine

In 1971, Gerald M. Weinberg wrote1 these Ten Commandments upon the stone tablets of The Psychology of Computer Programming. Well, they weren’t really written in stone. But they have stood the test of time. Wise is the software engineer who learns them and puts them into practice. 1. Understand and accept that you will make mistakes. Assume that you will write bad code. Find it and fix it before it affects users.

What Is a Paved Path?

Published by Matt Stine

I’m going to explain to you the concept of a paved path to software delivery. A paved path will make your engineering job as easy as possible. It will complete every task that wastes your time and effort. It will keep you focused on delivering business value through technology solutions. Sound good? Excellent. Let’s dive in. It enables getting started with a clean architecture: It’s a lot easier to get started well than to get started poorly and fix it later.

5 Reasons Constraints Will Make You Better at Software Engineering

Published by Matt Stine

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. You might call them: limitations restrictions standards contracts controls Regardless of what you call them, constraints will make your team better. Here are five reasons why: #1: Constraints limit the number of decisions you have to make.

The Highest Leverage Work You Can Do to Improve Your Enterprise Software Architecture

Published by Matt Stine

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? Nearly every organization that’s been around longer than FAANG companies is engaged in some form of software architecture modernization initiative. Over the course of my 21-year career, I’ve been privileged to work with dozens of them.

How Software Engineers Succeed by Selecting Tech That Sucks the Least

Published by Matt Stine

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. How does this work in practice? Well, let’s start spending tokens: Let’s choose Elixr for our backend services.

As a Software Engineer I Want to Use the No Free Lunch Principle So That I Can Save Myself Some Pain

Published by Matt Stine

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.

How to Use Slider Bars to Make Software Architecture Decisions

Published by Matt Stine

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. Understanding this principle is critical, but it’s only the first step. Using it to guide your decision-making process is the only way it can positively impact your team’s outcomes.

The Three Principles That Guide Every Great Software Engineering Team

Published by Matt Stine

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? Because Toyota knew that its competitors would do everything they could to duplicate its practices and tools, rather than understanding the principles of continuous learning and improvement. Toyota knew that by the time its competitors successfully duplicated its practices and tools, it would have learned and improved.

Two Things All Great Software Engineering Teams Share

Published by Matt Stine

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. Teams like this have many common characteristics, but let’s focus on two: They recognize the primacy of principles. Stephen Covey once said, “there are three constants in life…change, choice, and principles.