Solving Problems & Saving Time through Software and Crushing Entropy
I've written about “writing the software isn’t the hard part operating it is” before. Today, I think we can say the popularity and success of LLMs generating code is proving the first part of the statement. When we see everyone's hackles raise because of the consequences of this fact, I think it validates the second part of the statement. But I want to draw another through-line that has been…
I am referencing a well known piece by Fred Hebert with my title about writing software. It is well worth reading for the first time, or again. But, to get straight to the heart of it: Complexity has to live somewhere. If you are lucky, it lives in well-defined places… With nowhere to go, it has to roam everywhere in your system, both in your code and in people's heads. And as people shift around…
There are four categories to examine the work we do, or our co-workers, or even the work our users are attempting to do with the products we make; work-as-imagined, work-as-prescribed, work-as-disclosed, and work-as-done. Let me quickly lay out the concepts: Work-as-imagined : how you imagine doing your job in the future, or how you imagine other people do their jobs. Work-as-prescribed : the…
We build software to solve problems. The solution to the problems must be valuable enough for a customer to pay for them. There is a fundamental assertion here that we have to make—we, as a collective group of people, are extremely bad at solving valuable problems. I feel very comfortable making that statement because 90% of all start ups fail. And incumbent companies that already sell valuable…
Every year when the calendar starts getting to the end, and life starts to slow down a bit, I get an opportunity to step back a bit and think a bit more broadly. My mind wandered towards how many articles I've read and how much content is getting churned out. Our industry is constantly asking good questions. Yet, over the last couple of years many of the questions are the same, and the articles…
A good friend and I were chatting about his job. He was talking about how they were putting in place a number of rules for all the people doing jobs like his. My natural instinct was that this must make it harder to do his job. That people are creating bureaucracy. He went into greater detail, but I really didn't know his industry to know heads from tails. He said that this was a good thing. He…
I have been putting together some interesting correlations that I have observed throughout my career. It is giving me a realization about why I care about what I care about. I'm still figuring it all out, and this post is one attempt to vocalize a part of it. I have noticed a gap in outcomes between software engineers who have had to be operators, and those that have never been operators. When I…
When we talking about "who owns what" most commonly I hear people discuss it in terms like these: "Who owns this module in the codebase?" "Who owns this page in the application?" "We don't own that!" The way people talk about ownership betray some of my most important values. This is how I translate that kind of talk; "We don't want to touch it", "It is their responsibility", "I am not allowed".…
I think the idea of "Strong Opinions, Weakly Held", as it is commonly received, is a terrible concept. Another word for "strong opinion" is "a belief". Beliefs should be required to have costs associated with them. "Weakly held" implies to me that you create beliefs absent any costs. In my view, beliefs are strongly held. They are created based on impactful lived experiences. These beliefs that I…
T he aphorism "A person is smart, but people are stupid" has always stood out to me. It never sat right. If an element of a set contains a property, then the set ought to exhibit the same property. Right?! Well, what are we really trying to communicate when we say this? I think one aspect of what we're trying to say is that when we take a given person in a situation, we're probably imagining that…