Posts categorized as: software-engineering

Want to Master Enterprise Software Engineering Use These Three Power Moves to Achieve Great Success

Published by Matt Stine

I have been in the “enterprise software engineering” industry for 22 years. During that time, I have briefly but technically become a cloud startup millionaire. I published the first book with “cloud-native” in the title (and yes, the goddamn hyphen is correct, I said what I said). In fact, I have invested so many hours into mastering my craft that I literally have to turn down invitations to speak at conferences on the regular, even in this post-COVID era.

Something Weird Most People Don't Know About Software Engineering

Published by Matt Stine

There are many things most people don’t know about working in Software Engineering. For example, did you know… We reinvent the foundational dogma of our entire industry every 7-10 years. I’ve seen three cycles! The equivalent of a graduate-level education with multiple software engineering specializations is freely accessible on the Internet, and most engineers don’t look at it. We have overwhelming volumes of data that tell us specific software engineering models work, and we do the opposite most of the time.

Think You Don't Need a Dev Log? Laboratory Scientists Would Disagree

Published by Matt Stine

Laboratory science has much in common with software engineering: We take a new language or technology and experiment with it to see what it can do and how it performs. When we practice Test-Driven Development, every failing test that we write encodes a hypothesis: that the test actually will fail! We gather and study data obtained from our system and its surrounding environment as we troubleshoot incidents. We hypothesize causes, and we try to reproduce results.

Egoless Programming #3: No Matter How Much Karate You Know, Someone Else Will Always Know More

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 its third commandment: No matter how much “karate” you know, someone else will always know more. First of all, this is a good thing. My friend Neal Ford has said that as soon as you are the smartest person in the room, it’s time to look for another room.

Egoless Programming #2: You Are Not Your Code

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 its second commandment: You are not your code. This is without a doubt one of the hardest lessons for any early-career engineer to learn. As humans, we take pride in our creations. Unfortunately, software is soft because it’s meant to be changed, rewritten, and very often discarded completely.

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.

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.

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.