Recent content in Posts on For my friendgineers
While we’re all thinking about LLMs and Coding Genies, here’s something to think about. Taken as a whole, the process of software development is a system. Not just a system, but a system with feedback loops. Make a change, see what happens, react to the change. The OODA loop.
As an aerospace engineer who got started dealing with computer-controlled flight dynamics and keeping them stable…
I was staring at a PR the other day. It had been open for six days. The author had rebased it twice, resolved a merge conflict, and was about to need a re-approval because the conflict touched reviewed code. Six days. For a change that would take maybe twenty minutes to review.
We’ve all been there. And if you haven’t been on the waiting side, I promise you’ve been on the…
I’ve heard it said that there’s no problem in computer science that can’t be solved by another level of indirection. I’ve also heard that there’s no problem in computer science that can’t be solve by another level of abstraction. That’s the same thing, right? Wrong1.
Let’s start with some definitions.
Abstraction: In software engineering and computer science, abstraction is the process of…
Here’s something I ran across on the interwebs the other day. It’s about the reason for testing. I don’t fully agree with the first point, but I definitely agree with the rest.
If your tests only tell you when something breaks, you’re missing the point.
Great tests accelerate learning. They guide design, expose bad assumptions, and make change safe.
Testing isn’t cleanup. It’s…
There are two hard things in computer science: cache invalidation, naming things, and off-by-1 errors. Today’s post is about the middle one of the two.
Naming is hard. Noun clumps1 for data. Verbs2 for functions. Hungarian Notation3 for clarity? Everyone’s got an opinion on what’s right. Even languages have opinions on what’s allowed. Almost all languages allow almost…
I’m traveling on business this week. I’m staying in a hotel, as you do when traveling for work. As I spend time in the hotel, I’ve noticed some very interesting things and learned from them. Just like I’ve learned things from my dryer. One of the I’ve learned is about different kinds of optimization. Take a look at this photo.
Look at that bar of soap. It’s…
One of the people I regularly ready is Tim Ottinger. His writing has either put into words things that I’ve felt but hadn’t figured out how to say, or said things that I’ve said, but in a much clearer/more powerful way than I have. His recent post is one of the former.
One of the dominant, less-disciplined, processes that programmers follow is:
Write a bunch of code (being very careful, of…
On the topic of leading with the why, emotions are important. Two of the strongest emotions are love, and it’s not opposite, hate1. Three of the biggest drivers of innovation are necessity, laziness, and love. If you want to a strong driver of innovation, love is a pretty good choice.
Like George Thorogood asked, the question is, Who Do You Love?. Answer that question and you’re on your way.…
As I heard in marching band, don’t practice until you get it right, practice until you can’t get it wrong. It was certainly true there. It’s mostly true in Software Development too. Not that we’re doing the same thing, day in and day out, like a marching band, but there are a lot of process we practice every day, and getting better at those processes, learning them so well that we can’t get them…
Positional power is an interesting thing. The HIPPO effect is real. When you’re in a position of power, by definition, you have that power. Whether you’re aware of it or not. Whether you use it intentionally or not.
Of course, with great power comes great responsibility. One of the hardest things to remember is that because of that power, people don’t always hear things the way they are…
With all due respect to Mike Meyers as Wayne Campbell, I saw something on the internet and the only possible response was Exsqueeze Me?. The quote started out OK, not great, but OK, then, right there at the end, it took a sharp left into crazy town.
Good teams can and will delete tests that have high false positive rates – or that never fail.
Here’s the thing. If you’ve got a test with a…
I’ve talked about a messy middle before, but that’s not the only messy middle. That one was about the land of It Depends. Where you can’t know the answer until you have all of the context. But there are other messy middles.
Consider the space between products and platforms. The split between what customers bought, and what the company built internally so that they could then build the things…
As I’ve noted before, while I’ve worked all over the computing stack, from simulation for games and requirements analysis to 3D rendering to fleet management to tools, I’ve spent the last 15 years or so working down in the engine room. Working on internal platforms, tools, and infrastructure. And time and time again I’ve seen teams and entire organizations micro-optimize for immediate velocity…
Culture isn’t just for yogurt and sourdough. It’s also for teams. Or really, any organization, formal or informal. There’s a lot that goes into culture. What your goals are. How you incentivize. How you teach. How you do things, in good times, and in bad. And perhaps most importantly, how you handle uncertainty.
Overhead on the internet:
Your “Company Culture” is more about what happens…
I’ve talked about doc culture before. About the importance of writing things down. About how you can use a narrative doc, that everyone reads before talking to make meetings more efficient. Most folks think of this as the Amazon approach.
Amazon does run on docs. Many meetings start with a document, not a slide deck, that people read in the meeting. They comment on it live. The authors provide…
As CEO and Co-Founder of Honeycomb, Charity Majors has a lot to say about observability. She also has a lot to say about software development in general. And software leadership. Over the years I’ve learned a lot from her stuff.
Recently she was on the How AI Is Built channel. It’s a pretty good overview of how to do observability and why it’s important. On top of that, the title of the…
A long time ago I talked about distributed systems superpowers. Those are great things to have. When you’re building a distributed system, you really want your core functionality to have those superpowers. They make building the features your users want much easier. That’s your superpower
A quick recap. Here’s the 5 superpowers I listed.
Idempotency: The system should do the right…
Speaking of writing for the maintainer, what about coding assistants? They write code too.
First, an axiom. Just like auto-complete in your IDE is your code, code that you ask an AI assistant to write and then share as your own is your code. There’s nothing wrong with that per-se, but it’s not an excuse to not care about the implementation details.
Second, a position. Kent Beck has taken…
I’ve written about this before. When you’re writing code, who are you talking to? The simplest answer is that you’re writing to the computer. To the assembler, compiler, or interpreter, depending on the language you’re using. And at some level, that that’s true.
However, there’s a lot more to it than that. As the great philosopher and programmer, Anonymous, once said
A programmer does not…
If AI isn’t the answer, what is? Before you can say what the answer is, you need to be clear what the question is. If the question is “How can I get more code written faster?”, then AI might be the right answer. On the other hand, if the question is “How can I provide more value to the user faster?”, then AI probably isn’t the answer. At least not in any meaningful way.
Or at least someone told you they did. But did they really change? Or do you just understand them better?
Here’s the thing. If you go to your user, not the stakeholder, not the purchasing agent, not the product owner, but the user, and get them to describe the problem they need to have solved, it won’t change much. They may come up with more problems as you talk, but problems rarely change or…
I’ve said before that as developers we read more than we write. And that’s still true. Here’s something else we do more often than we probably think. We modify (extend) existing code way more often than we write brand new code.
Writing green-field code is fun. It’s easy. There are far fewer constraints. But how often are you really writing green-field code? If you want to be pedantic about it…
I’ve touched on the importance of listening to your data before, but I decided that the topic is worth revisiting. That time it was about the difference between 0, 1, and many. As a side note, I mentioned the relationship between data and Object Oriented Programming, and how your data can tell you what your objects are.
That’s still true. When people ask me to take a look at their design and…
Performance is important. It’s also very context dependent. High performance can mean different things at different times to different people. And what your target audience is going to consider important is never fully known unit that audience actually gets your software in their hands.
That said, there are some areas that almost always go into what people consider high performing software.…
Hot Take. Unit tests should pass, regardless of what day you run them. Time is hard. It has a way of passing when you’re not even thinking about it. When you’re writing simulations (or unit tests, which can be thought of as simulations of some small aspect of your code) one of the most important things to do is control time. As a general rule, unless you’re measuring performance or…
Closing out this series1, the third most common reason I’ve seen thrown around for why software engineering isn’t real engineering is:
Real engineers have a license. Software engineers don’t
In the United States you can get become a Professional Engineer. Canada has licenses and the Iron Ring2, which acknowledges the responsibilities an Engineer takes on towards society. Other countries…
The other day I talked about the #1 excuse people use when they say software engineering isn’t engineering, that software has no constraints. If you think software engineers don’t have to deal with constraints, here’s the post. Or just go talk to a software engineer.
The second most common excuse I’ve seen is
Real engineers can and do estimate their work. Software engineers can’t (or…
Over the years I’ve seen many people say that software engineering isn’t real engineering. They tend to come up with the same reasons, even if they have different examples. In my mind I’ve grouped them into a few major reasons.
Real engineers work with things in the physical world. Things made of atoms, and they’re constrained by physics. Software engineers, on the other hand, work on “bits”,…
Move fast and break things. That’s the tech mantra, right? Do something. Might be right, might be wrong. Just do something and see what happens. Things will break. That’s OK. Just fix it later. As the Dothraki say, It is known.
There’s another saying. Slow is Smooth, Smooth is Fast. This one is courtesy of the Navy Seals. It’s saying the opposite. Slow down. Think about what you’re doing. Make…
A long time ago, in a country far away from, the government released guidelines. Nothing unusual about this, It happens all the time. Usually, when I hear about that I think of things that are well known, well understood, generally accepted, and now written down in obtuse language with lots of buzz words and details. Enough fluff to make it largely incomprehensible. You know, standard bureaucratic…
When you’re writing code you have lots of choices. Even when working with 20-year-old legacy code, you have options. Not all of those options are equal though. Some are cheap and fast now, but may have a large cost later. Others are expensive and slow now, but might make things easier in the future. Your job as a software engineer is to choose the right one.
Which one is right? You can…
The other day I ran across a really interesting quote.
The bottom line here is that you have to respect the problem. … There’s no silver bullet solution to just linearise them and wish them away.
– Dan Davies
Now that was in the context government regulation and the environment, but the quote can be applied just as well to many different environments.
Such as software…
Unsurprisingly, there are hundreds of quotes about computers and programming by Edsger Dijkstra, and almost all of them are worthy of a post (or two). His work is foundational to much of what we do as software engineers. He was also a prolific, excellent, and memorable communicator. After all, he was the one who came up with Goto Considered Harmful and that one is certainly well known, almost…
Back when I worked on boxed products at Microsoft, we had 2-year release cycles. And towards the end of each one was a milestone called Feature Complete. That was the point in the project where all features we expected when we did planning 18 months earlier were done. Or at least the ones that we hadn’t decided to cut because we ran out of time. You would think that after feature complete, we’d be…
The other day I ran into a quote on the internet about the problem with emergency procedures. I generally agree with it. The quote went like this:
If you wouldn’t use your emergency process to deliver normal changes because it’s too risky, why the hell would you use it in an emergency?
But, as always, It Depends. It’s about the risk/reward ratio. You want the ratio to be low.…
Hiring has been on my mind lately. I’ve been looking for an entry level developer. Someone just starting out in their career. I’ve described the arc of my career before. In fact, I came up with what I think is a pretty novel (and useful) way to describe the arc of a career. It’s also good for helping you visualize where you are at any given point compared to your company’s (or more specifically…
As seen on the internet
People over process.
Why?
Because systems can’t fix problems with people, but people can fix problems with systems.
People Over Process is from the Agile Manifesto. There’s a lot to unpack there. It starts by acknowledging that the software development is a socio-technical endeavor. There are people (that’s the socio part). But there are also tools and…
I’ve subscribed to Kent Beck’s Tidy First substack, and there’s lots of useful info there. He just posted a piece on Why TDD doesn’t Lead to Dumb Code. As usual, it’s a really good entry.
But what really stood out to me in that post was not what he was saying, but how he was saying it. In particular, his use of an example. Beck is trying to answer why TDD doesn’t lead to overly specific code.
I’ve mentioned the Tyranny of Or many times, I talked directly about it four years ago, and I stand by what I said. However, because OR is such a loaded word there’s more to say. And, I get to use the Agile Manifesto and how it’s often mistakenly applied as an example.
To recap, the Tyranny of Or is any time you are forced into, or have convinced yourself, that you are in a situation where you…
Here’s a question for you. What’s the difference between simple and easy? Are they different, are they the same, or is one a superset of the other? If you had to choose one, which would you choose? And why?
First, let’s see what Sir Merriam-Webster’s reliable book has to say.
SIMPLE
readily understood or performed
simple directions
the adjustment was simple to…
Adding to my book reviews, consider Governing the Commons by Elinor Ostrom. You might wonder what a book about Turkish fisheries, Swiss grazing pastures, Japanese forests, and Spanish and Philippine water systems has to do with software development. It does seem to be a bit of a stretch.
Some background first. The common part is all about what the Commons actually are. In this case, it’s the…
I’ve talked about Type I (False Positive) and Type II (False Negative) errors before. While it would have been so much better if they just called them False Positive and False Negative cases, they only cover part of the problem. A more complete list would include the Type III (the right answer to the wrong problem) and Type IV (the right answer for the wrong reason) errors.
The Type III error…
A while ago I talked about Strong Opinions, Loosely Held. I talked about the problem with people with structural power (the HiPPO) having strong opinions and how those opinions often get too much weight.
The HiPPO Timo Elliott
As Jim Barksdale of Netscape once said,
“If we have data, let’s look at data. If all we have are opinions, let’s go with mine.”
Doing that can…
I’ve talked about the different kinds of tests. I’ve talked about when to run the different kinds of tests. I’ve said that your tests need to be good tests. All of that is true. What I haven’t done is talk about what makes a good test.
Of course, the answer to the question of what makes a test good is, It Depends. Mostly it depends on what kind of test you’re writing and when you’re running…
I’ve talked about code smells before. Just the other day I talked about comments as a smell. What about the opposite? Are there code virtues?
Of course there are. Things that we want our code to have. In fact, the Pragmatic Programmers published a list back in 2011
Pragmatic Programmers
Because English is a slippery language and, as Humpty Dumpty said, words can mean what we choose…
Motivation is a funny thing. If there’s a lot of motivation, it can make us do certain things. It can make us not do certain things. It can make us try to do everything. It can make us do nothing. It can make us focus solely on one thing, It can blind us.
On the other hand, if there’s no motivation, nothing happens.
Motivation is funny in another way. There are two kinds of motivation.
I’ve talked about comments in the past. Comments are a code smell, right? Maybe, or maybe not. It depends. Like so many things in the software world, a recommendation phrased as a comparison has been turned into a binary flag.
Why that happens is understandable. Binary is easy. True/False. 1/0. So easy even a computer can understand it. It reduces cognitive load. On the other hand, comparisons…
I’ve talked about ownership before. I’ve even mentioned diffusion of responsibility a couple of times. But I haven’t really talked about it. It’s time to talk about it.
I’m a grandfather now. Have been for almost a year. It’s amazing watching my granddaughter grow and learn. It’s also mazing watching my daughter learn about being a parent, just like I did many years ago. Unsurprisingly, we…
Tales from the real word today. Code coverage is important. It can give you confidence. It can help you move faster. It can alert you to problems before they get exposed to your users. But it’s no guarantee of correctness.
Bad Tests The first problem is that 100% code coverage does not in any way guarantee that the tests you’re using to measure your coverage are valid tests. Writing good unit…
Speaking of remodeling updating your code, If you’re releasing a new version of your code, that means you’ve already released a version of your code. That means that at some time in the past, you finished your code. Or at least thought you did. But now, here you are releasing a new version. So I guess you weren’t done. Or to put it another way,
The finish line is just another milestone.