Recent Posts (page 1 / 71)

The Genie and the Damped System

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 despite dealing with human pilots who insisted on overcontrolling things and getting into Pilot Induced Oscillations (PIO), I’m very familiar with different kinds of damping modes. Depending on how you like to name things, there are 3 or 4 basic classes of damping. The different classes describe how a system responds to a single disturbance.

Overdamped

In an overdamped system, the system eventually returns to (approximately) its initial condition. Slowly getting closer and closer. But it takes a long time. The more overdamped, the longer it takes.

Underdamped

In an underdamped system the system will probably return to its initial condition, but again, it takes a long time. Unlike the overdamped system though, the underdamped system goes back and forth, like a pendulum. It starts with an offset, goes back to where it was, then keeps going. Eventually it slows and swings back, continually crossing where it started and again, eventually returning.

Critically damped

The critically damped system is somewhere between the over and under damped. Done right, it quickly approaches the initial state and then settles back into place. It might overshoot once, but not twice. Either way, it gets back to where it started and stays there much more quickly than either the overdamped or underdamped system.

Unstable

Finally, there’s the unstable system. That’s what happens when you take an underdamped system and add in some more inputs. At the wrong time or in the wrong direction. That’s what PIO is. The system is somewhat underdamped, and the pilot makes it worse. Instead of settling out, the oscillations get bigger. In the aviation world, the best thing you can do at that point is take your hands off the controls. All general aviation aircraft are generally stable, so when the get unstable letting go will sort things out. Note, this does not mean they fly themselves or can correct for problems, just that, within their performance envelope, without excessive inputs, they tend to fly straight and level.

Now that’s all interesting, but what has that got to do with LLMs and Genies? Consider this.

Software development is a feedback system

You put in some code. The compiler and your tests give you some feedback. You make changes and do it again. You deploy your code or otherwise put it into use. You get some more feedback and make more changes. Over time we have, individually, and collectively, figured out the right amount of friction and delay to to keep the system well damped, but not overdamped.

Sure, sometimes we take too long to react and things are overdamped, or we don’t react fast enough and things are underdamped. Sometimes we even over-react, like during an outage and make things worse (unstable). But generally, we’ve figured out, for ourselves and our teams, what works for us.

Enter the Genie

Now add the Genie (LLM) to the system. You’ve just removed a lot of the friction, the damping from the system. Instead of it taking some amount of time to write the code, the Genie does it for you and does it quickly. The genie makes it possible for people without experience in the system to change things. Even less friction. Think about what happens when you remove friction from a mechanical system. It very quickly becomes underdamped. And at that point tiny inputs can make it unstable. But the genie doesn’t do slow, small changes. What was critically damped (or even overdamped) is now underdamped.

Which means, at a systems level, the results are unsurprising. Rapid change at the beginning. Large oscillations pretty soon after. A much higher tendency towards unstable responses.

So what do you do? You do what any control systems engineer does. You start by observing. You find out what the behavior drivers are, and what their frequency is. You see how that frequency matches (or doesn’t) to the response curve of the overall system. And then you work to bring the two into harmony. You add a bit of delay here. A bit of friction there. Maybe some artificial damping in certain conditions.

You control the system instead of letting the system control you. Because that’s what engineers do. You understand the system, and you work with it.

Your PRs Are Someone Else's Problem

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 other side — the reviewer who meant to get to it tomorrow and then tomorrow turned into Thursday.

Here’s the thing. We already have code review requirements. You know what they are. If you don’t, check Code Review. And most agree. This is a good thing.

Why This Matters More Now

In the age of AI and LLMs writing code, reviews matter more than they ever have. LLMs are literally engines designed to produce plausible-looking output. Plausible-looking. Not correct. Not safe. Plausible. The errors hide in plain sight because the code reads well even when it reasons poorly. Your review might be the only thing standing between a subtle bug and production.

Yes, reviews have an inherent delay. You need another human to look at your code and stamp it before it lands. That delay is a feature, not a bug. It’s load-bearing.

But when that delay stretches from hours to days? Now we have a different problem.

What Happens When Reviews Stall

PRs that sit open for a week aren’t just an inconvenience. They’re compounding debt. Every day that PR is open, the author is rebasing, re-resolving, re-requesting. They’re context-switching back to a change they finished thinking about days ago. Their stack is blocked. Their momentum is gone.

And here’s the part nobody says out loud: when your teammate’s PR sits in your queue for three days, you’re telling them something about how much you value their work. You might not mean to. But that’s the message that lands.

Reading Code Is Your Job

As a software engineer, your job involves reading code just as much as it involves writing code. Maybe more. And as part of a team, your job includes collaborating with your coworkers on shared projects — like, say, shipping software.

If you’re a blocking reviewer, that review isn’t a favor. It’s an obligation. One you owe your team.

This Is a Culture Problem

This is not a new policy. Policies are what you deploy when culture fails. What I actually want is for folks to internalize this message.

Code reviews are among the most important things we do as Software Engineers. They’re part of our job. They aren’t optional to our success. ¹

And that means we need to shift how we think about them. Not “I’ll get to it when I have time.” More like “this is the time.”

Finish your reviews. Your teammates are waiting.

Indirection Vs. Abstraction

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? Wrong¹.

Let’s start with some definitions.

Abstraction: In software engineering and computer science, abstraction is the process of generalizing concrete details, such as attributes … to focus attention on details of greater importance.

    – Wikipedia

Indirection: In computer programming, an indirection (also called a reference) is a way of referring to something using a name, reference, or container instead of the value itself

    – Wikipedia

Here’s the thing. Abstractions provide simplicity by hiding details. Indirections provide flexibility by introducing a decision point. Both are important. You can’t write effective, resilient, maintainable software without both. It also means that every abstraction is also an indirection.

Consider dependency injection. It’s an indirection. The goal is to let the developer not care which thing got injected. The operations, the verbs if you will, are defined by the thing on the other side of the indirection. Instead of calling some resource directly, you get told what resource to use. That makes it more flexible. Regardless of what you get though, they need to act exactly the same. Whether you’re writing your data to the production database, a shared staging version, or your own private one, you know you’re writing to a database and the API you use reflects that. You’ve also made the overall system a bit more complex. And you’ve made it harder for the person looking at the code to know where the data was written because they have to figure out what was injected.

An abstraction, on the other hand, changes what you can do with the underlying thing. The goal is to change the mental model of the thing. Instead of the verbs coming directly from the underlying thing(s), the abstraction defines its own operations. Some things that could have been done are not exposed. Some things that can’t be done directly are composed and presented as operations. Instead of the CRUD operations on a database, you might have Load, Save, and Filter on an entire dataset. And as a user of the abstraction, you don’t know (or care) if it’s a database, a bunch of files on disk, or a mechanical turk setup. Outside the abstraction all you need to know is what the operations do. Inside the abstraction, you don’t care how it is used. You’ve reduced the cognitive load of the user, but also reduced the system’s flexibility.

Those two usages are clearly not the same. Yet I hear people using them interchangeably all the time. Not only does that cause communication problems, when people aren’t talking about the same thing, it causes problems in code as well. Particularly when a problem calls for an abstraction, but someone provides a solution that is really an indirection.

Therein lies the problem. If you confuse the two you make things worse. The most common mistake I’ve seen is using an indirection and thinking you’ve created an abstraction. For example, there’s the Enterprise FizzBuzz. That’s about as indirect as you can get, all in the name of abstraction.

On a personal level, I once spent over a year working on a Java project that really embraced Lombok. The theory was that there was an object model that did what we needed and everything was late-bound in. In practice, everything was decorators and builders. Indirection everywhere. Tracing the code was almost impossible. Extending a model required changing multiple files that had no visible connection. You didn’t have to connect anything to anything else. But you also didn’t know what you needed to create or modify until things didn’t work. It was a nightmare to work with because it tried to be an abstraction, but all it really was, was unneeded indirection.

I love abstractions. They lower cognitive load, help people do the right things easily, and make it hard to do the wrong thing. I like indirections as well. They provide flexibility and monitoring points. Just like a short link URL lets you move the actual link and not have anyone care, indirection lets you move things without users caring.

However, they are not the same thing, and if you confuse them you’ll eventually realize it. And pay the price.

Testing Is More Than Preventing Breakage

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 engineering. Still shipping without fast feedback? That’s not speed. That’s risk.

– Dave Farley

Using tests to tell you when something breaks is absolutely part of why we have tests. Whether the tests are written first or after, once you have them¹ they’ll let you know when a change you made breaks something. That’s real value right there. It might not be the whole point, but it’s part of it.

Dave is right though that do tests more than just detect breakage. They help you clarify things. They help make things more concrete. They help you make your interfaces clearer. They validate what you think you know. And they point out the things you know that just ain’t so.

Especially if you write your tests first. You write the tests that expect the code to work correctly. To behave the way you want it to behave. Tests that use an abstraction and mental model that is consistent. Tests that show how the thing is going to be used.

That’s where the learning comes from. Each test builds upon the earlier ones. They let YOU test your mental model of the system before you write any of the code. If the mental model you’re using doesn’t allow you to write a test that has the behavior you want, it’s the wrong mental model. If the behavior you want is hard to get then your model needs more thought. Remember that you are not only allowed, but required to think about the whole system before you write that first test.

Once you have the tests written, all you need to do is write the code. When the tests pass, you’re done.

Yes, it’s not that simple in practice. You probably won’t write all the tests before you write any code. In fact, you shouldn’t. You should write your list of tests first. Then you should write one test². Once you have a test, write the code needed to make that test pass³. Once the test passes, look at the code and fix it⁴. Then you’ll move on to the next test and its code. Repeat until you run out of tests to write.

As you add more tests and more code you’ll be learning about the code. You’ll find things that need to be refactored and combined. You’ll realize that some of what you thought you wanted was wrong and you’ll adapt. You’ll optimize for multiple things at once. You’ll make compromises. You’ll do the thinking needed to solve the business problem you need to solve. You know what else you’ve done? You’ve done Test Driven Development.

To reiterate, as Dave says, writing tests isn’t the cleanup you do at the end. It’s not just coding to a spec and checking a box marked ‘Write Tests’. Done right, writing the tests is engineering the system. And when you’re done you’ve not only solved the current problem, you’ve built a system that will reduce the risk of making changes when you learn something new.

Stuttering

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 clumps¹ for data. Verbs² for functions. Hungarian Notation³ for clarity? Everyone’s got an opinion on what’s right. Even languages have opinions on what’s allowed. Almost all languages allow almost all of the ASCII characters in identifier names. Some they have rules around what can be first in the identifier and how long it can be. Others assume certain types for different identifiers (I’m looking at you FORTRAN).

And some languages are more opinionated than others. APL has its own character set (and keyboard). Python doesn’t care much. Go, the language is not very opinionated. Go, the ecosystem and the community, on the other hand, are very opinionated.

gofmt, the Go formatter is so opinionated that, unlike every other formatting tool I’ve ever come across, it has ZERO options. You can add rules, but you can’t turn any off. You can’t pick the brace pattern. You can’t pick tabs, spaces, how much to indent each block, or anything else.

It’s simple, it’s fast, and all Go code looks the same. I consider that a win.

Go’s linters are similar. Both vet and golint let you choose which checks to run, but there is no ability to ignore a false positive. You’ve got to fix it or re-write the code to remove the false positive. I consider that mostly a win, but I have seen bad rewrites to make it happy.

Another thing golint will do for you is help prevent what it calls stuttering. According to golint, stuttering is when you have a public method in a struct with the same name as the struct itself. Something like run.Run(). I get that. Stuttering like that is both annoying and forcing ambiguity. When you’re talking about the code and you mention run, are you talking about the struct or the method? You need to be careful when you talk about it and the person you’re talking to needs to pay close attention to what you’re saying. That adds cognitive load, and part of Go’s design principles was the idea that it would be easy to ready. Both for a person and for the compiler. The Go Proverbs really lean into this. Make it easy to understand. A few extra lines or methods is fine.

But it’s not perfect. Sometimes code still stutters. And sometimes it’s hard to read and understand. Especially when there’s lots of text in the output to look at.

All of which is a very long way to say that naming is hard, and when a name stutters it adds to your cognitive load. They higher the cognitive load, the more likely you are to miss something. Missing something simple can cause you a lot of grief.

I was thinking of this because of an issue I tripped over the other day. I misread the name of a test in a test report because of stuttering issue. Starting from that simple mistake, I spent 4 hours questioning how computers worked, the correctness of a very simple, core feature of our build system, bazel, and my sanity.

You see, bazel has the ability to filter out tests based on the keywords you tag them with. Want to run only tests tagged with needs_network? Just add --test_tag_filters=needs_network to you bazel test command. Want to skip any tests with that tag, just add --test_tag_filters=-needs_network. Simple and straightforward.

And it seemed to work. I’d been happily marking bad tests with a tag and then fitering them out. Then, all of a sudden one of them showed up in my list of failures. Why was it running? It was supposed to be filtered out. And when I tried to run just that test and filtered it out it didn’t run.

However, when I ran all of the tests in that directory with the same filter, it did run. This apparent dichotomy led me to 4 hours of questioning myself and computers. I did all sorts of debugging. Printf, tracing, log grepping. And it just didn’t make any sense.

I started asking others if they had seen anything like that. No one had. Until finally, someone (thanx Alex) pointed out the simple thing that I was missing. Our test names stuttered. We had one test called //a/really/long/path//that/leads/to/the/thing:go_default_test⁴, and one test called //a/really/long/path//that/leads/to/the/thing/thing:go_default_test. I marked //a/really/long/path//that/leads/to/the/thing:go_default_test as a test that should be skipped, and when I tried to run it by itself, it got skipped. Then, when I ran all the tests under //a/really/long/path//that/leads/to/the/…⁵ and looked at the results, it was still skipped. But I didn’t notice it.

What I did notice was //a/really/long/path//that/leads/to/the/thing/thing:go_default_test. And because the prefix was the same for all the tests, my eye was drawn to the suffix. And I saw /thing:go_default_test, which I wasn’t expecting. It wasn’t supposed to be there. And because I was task focused I completely ignored the prefix. Instead of recognizing that these were two different tests, I thought the tools were broken. And down the rabbit hole I went.

To wrap this up, the real problem was that, because of the stutter, I had marked the wrong test. I was excluding a test that was fine, but running a test that sometimes failed. Then, when debugging it, I never noticed that there were two tests with almost identical names.

The moral of the story? First, beware of target fixation. Instead of looking at the bigger picture, I got stuck looking for how the tools were broken. Second, make it easier on yourself and don’t stutter in the first place. There didn’t need to be two tests that started with the same long prefix and ended with the same medium sized suffix, with just a tiny difference in the middle. That was a choice we made. We should have chosen better. If the tests names weren’t so similar I wouldn’t have missed the obvious.

Optimization

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 got three holes all the way through it. It’s maybe half soap. That’s just the hotel being cheap, right?

Look at the silverware. They’ve all got big holes in the middle of the shaft . Only the ends of the silverware are covered. That’s just the hotel being cheap, right?

Wrong. That’s optimization. The question is, what are they optimizing for? Sure, cost is one of the things being optimized for. But it’s not the only thing. There are multiple other things. Like lifespan. Usefulness. Material used. Waste. And of course, customer satisfaction.

It’s not just any one of those things. Instead, it’s maximizing the collective impact of all those things. It’s got to be low cost, because the hotel goes through hundreds of thousands of them. If they’re too expensive, the price of the room goes up. If there’s too much material used then there’s more waste, which takes up more space and costs more to handle, which also drives up the cost of a room. On the other hand, if the silverware is made with too little material, it bends or breaks too easily and can’t be used.

The bar of soap needs to last for a few days, maybe a week. But that’s not a lot of soap. If it were solid, it would be too small to be used comfortably. The machine to make a bar of soap with holes in it is more complicated than one that makes a smaller solid bar. It’s more expensive to operate. But customer satisfaction is important.

The design of the silverware and the soap takes all that into account. They’re not the cheapest they could be. They’re not the best experience they could be. But they’re good enough. And they’re cheap enough. They’re not optimized for long term home use, and they’re not optimized for camping or restaurant use. They’re optimized to for short stays in a hotel.

Software is similar. It’s optimized for use in a specific context. Kubernetes is great if you need to orchestrate the deployment of hundreds of different workloads with multiple instances of each across thousands of computers. But if you’re hosting this static website then Kubernetes is a bad idea. Need to store a dozen rows for a database? A simple text file can work. If it’s a complicated schema then maybe JSON. You don’t need, or want, a Postgres or Cassandra database. On the other hand, of you need to store data related to millions of images with thousands being added every day, Postgres might be what you’re looking for.

And it’s not just in choice of technology. It applies to languages, architecture, and how you deploy things as well. These are all decisions we make on purpose.

Or at least we should be doing that. That’s what software engineering is really all about. Understanding not just the problem, but the context, the situation, and the environment, that you are solving the problem in. Then finding the combination of parameters that optimizes the value produced compared to the cost of production. I can’t tell you the right answer to all of those questions without a lot more context.

But I can tell you that the answer isn’t as simple as you think. And that the answer will change as the conditions change. So be prepared.

Writing Legacy Code

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:

1. Write a bunch of code (being very careful, of course)
2. Edit it until it will compile.
3. Debug it until it gets the right answers.
4. Look it over for other errors and correct them.
5. Send it off to code review

If they write tests, they usually do so between (4) and (5).

Notice that by performing steps 1-4 first, they have placed themselves in the legacy code situation.

You can read the long form version on his website. That article has a lot to say about TDD, and, as usual, I agree with all of it.

But what I realy want to talk about here is New Legacy Code

Or more specifically, the fact that so often, we do it do ourselves. I see it all the time. Code that gets more and more complex as time goes on. Where the lines between domains blurs and functions start to do very different things depending on what parameters they’re called with. Where abstractions start leaking details up and down the call stack. Making changes (and testing) harder and harder as time goes on.

It starts with little things. Someone adds a special case based on one or two parameters, or if we’re in some particular state then skip a step. After a while the code starts looking like an arrow with all the nested conditionals. Instead of refactoring isolating things we make new connections to a database or call time.Now() directly. We take a function that did the one thing that was it’s name but add things to is until a better name would be doTheOldThingThenDoTheNewThingUnlessConditionXorYorZ().

I’m guilty of it. I get impatient. I have a problem. I have an idea for a solution. I start working on the solution. And of course, it’s not quite right, and I find myself in the legacy code situation. It doesn’t really feel like legacy code because at that moment I’ve got it all in my head, so making changes with context is easy. But months later, or even the next day, when I come back to it, all that context is gone. And I need to back my way into it.

It is undisiplined. I know better. Sometimes I forget. Usually I remember and do something about itm but sometimes I forget. Sometimes I get lazy and choose not to. Either way, I always regret when I don’t.

So go read Tim’s thoughts in his own words.

And remember that much of the pain you’re feeling when working without a net is self-inflicted.

Who Do You Love?

On the topic of leading with the why, emotions are important. Two of the strongest emotions are love, and it’s not opposite, hate¹. 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. Get the whole team loving the same thing and you’ll be amazed at what you create. So, who should you love? In Inspired: How to create Products Customers Love Marty Cagan gives us the answer.

Fall in love with the customer’s problem, not your solution.

That’s it. It’s that simple. Love (and hate) your customer’s problem. Be passionate about it. If that problem is the most important thing in your universe, and you hate it so much you want to eliminate it, your customer is going to be surprised and delighted.

It means understanding the domain and the problem so well that you understand not just what happens, but why. You understand the fundamentals and the theory behind them. You know not just what the problem is, but why it exists.

What you don’t want to do is fall in love with your solution. Yes, you should deeply understand your solution. What it is, how it works, and why it works.

But you also need to remember that your solution is not the important thing. It’s just a means to an end. A way to eliminate the customer’s problem.

The problem with loving your solution is that it becomes the important thing. You start seeing it as the solution to not only the customer’s specific problem, but the reason you’re doing the work in the first place. And that’s just wrong.

When the solution is the most important thing, you start rephrasing the problem to match the solution. You stop delighting your customer. Instead, you start teaching your customer why they’re misunderstanding their problem, and they should listen to you about what the problem really is². And that’s the tail wagging the dog.

When you and your team share a why of love (and hate) for the customer’s problem, you’ve tapped into some of the most powerful emotions and drivers of innovation.

Which will result in delivering maximum value for the customer.

Practice Makes Perfect?

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 wrong, is a good thing, right?

Well, It Depends. Generally, it’s better to improve your understanding of, and ability to use, those processes. But not always. Consider this quote:

Do you want to get better at what you’re doing, or find a better way to get the results you want?

That’s a pretty powerful question. It cuts right to the heart of the matter. As I often ask, “What are you really trying to do?” Your goal is to add value. As much value as you can over time. Sometimes you can do that by getting better at doing what you’re doing. But sometimes, you can add even more value by rethinking the situation and approaching it differently¹.

Here’s an example for you. Over the years I’ve build about half a dozen batch/parallel processing systems. The first few were very bespoke. They were ad-hoc, distributed build systems for game assets. Turning complex 3D models built with expensive modeling tools into runtime versions that could be rendered in-game quickly. No options on where sources would be found or where to put results. Run one command and hope it worked. Retry it if it didn’t. That was about it.

Over the years they got more generic. Multi-step pipelines. Then map-reduce like things. We added some error handling. We figured out how to do steps that involved people. We started to track the data so we could re-run things based on changed data, automatically. We got better and better at handling different team’s specific needs and workflows. But through all that, changes to the pipeline required changes to the system. That only the framework team really understood. And that bottle-necked the overall system.

Then we had an epiphany. We were getting better and understanding our customers and their needs, but we would never understand them as well as they did. No matter how much better we got, we were rapidly approaching a capability limit.

So instead of getting more detailed, we got more abstract. Instead of doing things for our users, we gave them more power and let them do things themselves.

We gave our users the ability to write their own control logic. They could look at their data, do some thinking and planning, then tell the processing system what their data and processing flow looked like. All we had to do was do what they wanted. And do that well.

Instead of expanding our responsibility to include someone else’s domain and doing an OK job, we restricted our domain to what we knew best. Turning a graph of data processing tasks into an optimal (ish) usage of hardware and network resources. So that our customers could do what they needed to do, in their domain.

That’s just one example of how re-imagining the situation and really solving the user’s problem is what we want to do. There was no way we could be good enough at everyone’s domain and be the best at our domain at the same time. Getting better at undertanding other team’s domains helped, but there’s a limit to how well we could understand it. There were multiple teams that we needed to support at the same time. We just couldn’t do all of it will.

So, instead of trying to get better at the wrong thing, we made sure we understood the other teams to know what they needed, then we focused on our strength². That’s what let us add even more value.

Even more problematic, there’s often no path that keeps adding value that will lets you keep getting better at what you’re doing as you switch to getting good at doing something more valuable³.

Power Dynamics

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 intended. And as the person who’s trying to communicate something, it’s on you to make sure the message gets across. The misinterpretation is your fault, not theirs.

One of the most famous examples of this is from the movie Beckett, where King Henry II exclaims “Will no one rid me of this meddlesome priest”, and the next day, the priest is dead. While this almost certainly didn’t happen exactly as depicted in the film, it’s not hard to image that something similar did. Did the King order his firend’s death? Not directly. However, if the King of England, arguably the most powerful man in Europe at the time, complained about something, it’s not at all surprising that his faithful followers did something about it.

England in the Middle Ages is not the only time that happened. It happens all the time. The less contact a person has with someone with significantly more positional power¹, or the bigger the power differential, the more likely the subordinate is to listen very closely to the words spoken and do something about it. Whether the person speaking is a King, a General, or just someone with strong influence over your paycheck.

So as the person with that kind of power, it’s critical to think about how your words are heard. That doesn’t mean you shouldn’t say anything. That doesn’t mean you shouldn’t be relaxed and make comments or say what you think. It does, however, mean that you need to think about how your words are perceived. And you need to be explicit about the difference between orders, suggestions, questions, and personal opinions.

I learned this the hard way myself, back when I was a new manager. I asked one of the developers on my team why they had chosen to implement things in a new way when we already an implementation that was very close. I commented that I would have probably just tweaked the existing functionality. At the time, to me, it was just a comment.

The next Monday I got to the office to find that the developer had done a major refactor of the old code to support the existing functionality and be able to handle the new situation. The new code was good. Clean boundaries, no repetition, and very flexible. And over the next 4 years we never used that flexibility. We did occasionally have to go back in and separate the functionality even further. The developer gave up a weekend of their personal time to make a change that wasn’t needed, and in fact, cost us time later. All from a casual comment I made.

Because without enough context, it’s hard to distinguish between a personal opinion, a suggestion, and explicit direction. And in the absences of clarity, people often defer to power.