"sam is typing..."

It can be pretty common to come across the concept of Right in a software dev job. Right is the idea that a solution is totally correct. The Right Thing. That any other solution would be unexplainably worse. People like this idea. It seems simple, almost obvious. After a bit of experience as a problem solver, you might even come across solutions that feel Right to you.

This can be dangerous. It makes it easy to get arrogant about your solution. Nobody else could possibly touch your idea, if your solution is Right, then you are Right. This can not only create tension with your colleagues, but can lead to brittle systems too. It can also lead to deficient systems that don't take the real world or real problems into account, like those discussed in Algorithms of Oppression. If you're solution had to deal with all that stuff, it wouldn't be Right any more. Right?

I believe it's best not to pretend that anyone by themselves (even in a stroke of genius) could come up with such a perfect solution. It's highly unlikely that anybody could actually find the optimal solution to a problem "just like that", and it also puts everybody else who has ideas for solving the same problem down as 'definitely wrong'. To solve this, I like to imagine that the Right solution is real, but unobtainable. This gives me something to move towards.

There's this poem, The Lost Chord. It's about a musician that plays the perfect set of notes together, the Right chord if you will. They find that they can't find it again, it becomes lost. They know there's something to reach for, but they can never find it. This might sound like a downer, but it also gives you something to aim towards - without ever thinking that you or anybody else came up with the perfect way of doing something.

In reality, robust systems develop over time. They take many minds and many iterations to get to taking all the mess of the real world into account. They evolve, split and multiply to deal with any sufficiently complicated problem. It's important to remember this. The 'move towards improvement' approach is seen repeatedly in successful projects. From the Improvement Kata through to Eric Raymond's approach to learning an unknown system.

This is an approach that has existed in many forms, and has been discovered by people much wiser and more knowledgable than me. This is putting your faith in systems over outcomes, and ironically this feels like the Right approach to me. It's not fixed, but instead is flexible and grows and changes, but that's where good systems thrive.