This week I've been deep in an epic coding session, worthy of the rousing soundtrack you get in Hollywood hacker movies.

It's fun.

And something interesting:

In working on this application (doesn't matter what it is), I was stuck on an important subsystem. It had to do with how my application integrates with a complex vendor API - but again, that detail doesn't matter.

What matters is that, when I started, I could see four possible ways to implement it. And it wasn't clear which was best.

So I invested a good chunk of time spec'ing them all out. Reasoning how each would fit in the app's architecture...

Read More: https://complextime.com/

And after, I still couldn't tell if ANY of them would work. Or all of them. Or only one. (Which one)?

As you get better at coding, you encounter dilemmas like this less often. Like a master chess player, you get better at "pattern matching" increasingly complex coding situations, and able to reckon which choice has the best chance of working out well.

But it still happens.

So. What which of the four did I choose?

I did all of them.

That's right. I re-coded the same subsystem FOUR DIFFERENT TIMES, in completely different ways.

And it's not the first time I did something like this. In fact, it's COMMON that I'll see two possible ways to code up a solution; realize I don't have the clarity and information to choose between them; and code up both to see what works best.

So when I next encounter a similar situation, I will not have to guess which will work better. I'll KNOW.