Ah, now, here’s our second loop. People paying for a service.

This loop is where a lot of senior developers find themselves in. The main goal in this loop is the continuation and guarantee of service.

Keep things working, keep things understandable, keep things debuggable, keep things fixable, keep things teachable, keep things stable.

Senior developers worry about stability because they take responsibility for the business to continue serving customers.

And what risks all of that?

Complexity.

It makes a system less understandable, less debuggable, less fixable, less teachable, and ultimately, less stable.

Rising complexity = lowering stability = senior developer failing responsibility = bad bad not nice, payments interrupted, everybody sad.

So, if the first loop’s goal was uncertainty reduction, the second loop’s goal is complexity management.

But why does this lead to communication failure?

Because once you have customers, both loops are running simultaneously. A business needs to both explore possibilities and serve customers at the same time.

Ok, now you might be able to spot my answer to the question in the title of this post.

Depending on which loop you spend your time on, your problem is framed differently (which is why I think developers get split in their opinions on AI; some work more on one loop than the other)

This was the story of the people in the first loop:

But this was the story of the senior developer in the second loop:

The stories don’t match.

The more requests to build and add to the system the senior developer gets, the more the senior developer wants to respond with “uhhh, no complexity … maintenance costs … understandability … speed of continuing development … productivity over time …”.

But that does nothing to address the rest of the business’s need for reducing uncertainty.

The copywriter’s diagnosis: You can’t explain away someone else’s problem using your own problems.

And the copywriter’s prescription: You need to describe your solution as a solution to their problem as well.

Senior developer’s fail to communicate because they express their problems in terms of complexity management when they should be expressing their solutions in terms of uncertainty reduction.

By acknowledging that what the rest of the company is seeking for is uncertainty reduction, the senior developer can use their expertise to help.

And what’s the most useful skill a senior developer has? The reluctance to build what’s not necessary; the ability to spot an opportunity to re-use something already built.

Need to collect survey data? Google forms, baby.

Need to build a whole new feature to test it? Have you tried putting a button in the existing UI and seeing if people click it?

Need new analytics service? What’s the most important decision we need analytics for? Can we start with one decision, one chart, one metric?

You want to bake me a whole birthday cake? Just put a candle on my sandwich.

This is what senior developers learn to do: they learn how to give people what they want by being resourceful with existing software.

But how do you communicate this without sending people whole essays?

Copywriters love boiling down multiple signals into singular phrases. And so, here’s the magical phrase every senior developer must learn: ‘Can we try something quicker?’

The use of ‘quicker’ acknowledges what they’re really looking for; ‘something’ implies another way of achieving it; ‘try’ implies imperfection, but also the possibility of it being good enough.

It perfectly cuts down to the requirement of the rest of the company, speed to reduce uncertainty, while allowing the senior developer to exercise their expertise: reduce, re-use, and if life is truly a blessing, avoid.

That’s it. That’s my answer to the title of the post: senior developers talk in terms of complexity when everyone else is worried about uncertainty.

But! Big but!

AI now seems to make all of this pointless, doesn’t it? Why reduce? Why re-use? Why avoid? The AI can build so much in so little time.

Ah, well, it can’t yet do the one thing senior developers still do.

Take responsibility.