Recently, I have taken an interest in Greek mythology. Whilst I love the fantasy element in these stories, I am often drawn more to the lessons we can take from each myth. One of my favourite stories takes place in the months and years before the Battle of Troy. Paris — a humble man abandoned at birth and raised in the wild — befriends the God Hermes. One day, on a mission tasked by none other than Zeus, Hermes introduces Paris to three goddesses and gives him an unenviable task: presenting a golden apple to the fairest goddess. In their attempt to sway Paris, the Goddesses Hera and Athena promise him riches, wisdom, power, and status. The third goddess, Aphrodite, offers Paris love — the beguiling Helen will be his wife. After much deliberation, Paris accepts Aphrodite’s offer. He puts the apple in her hand and moves on with his life. Paris’s decision, unbeknownst to him, would ultimately lead to the bloodiest, most devastating wars in Greek mythos.
Given the tragedy that would ensue following Paris’s decision, it would be easy to pass judgement on the poor lad. But how can we be so sure that all things would have been sweet and rosey had he decided differently? If Hera had won Paris’s heart, would the power endowed upon him have corrupted his mind, creating a tyrant? Or would Athena’s promise of unlimited wisdom send Paris raving mad? Are we sure the Trojan War, for all its atrocities and bloodshed, is the absolute worst outcome? Perhaps it is, but we don’t know until we decide and pursue the path.
Thankfully, as a software engineer, I’ve rarely had to make decisions with such potentially catastrophic consequences. But, like our friend Paris, we engineers face hard choices. Sometimes these decisions are small, such as what name we should assign to a variable. Other decisions carry far more weight.
I often struggled to make decisions in my earlier engineering years, typically overthinking the situation even after all the necessary ruminations had concluded. I recall a case where I was selecting a styling library for the front-end architecture of a web application. As the only front-end developer at the company, this was a decision that fell to me. Prior, the company I was working for didn’t have any such library — they were using good ol’ vanilla CSS.
I conducted copious research in my attempt to identify the most suitable technology. With the knowledge gathered, I now had to do the critical part: make a damn decision. This is where the process stalled. No matter which option I considered, amongst the many angels on the surface, there lurked numerous dragons beneath. But the point on which I became most stuck was attempting to predict if the solution I chose today would be appropriate in six months. And would it be too late to correct course?
At this point, I had my Judgement of Paris moment: whichever library I selected, there was a potential for future disaster. I had conducted the research; the data was in. I had all the information required. I just needed to commit to a path and stick with it. The perfect solution did not exist. Once I realised this, the decision became trivial. I put the apple into Aphrodite’s hands and continued my life.
I’ve taken this approach to heart in recent years when making decisions. This method is more succinctly described as “shoot first; recalibrate later.” This is not to say that you should be careless in your decision-making. You should still give yourself all the information required to make an informed decision. But when you find yourself in that state of prevarication — reading the conclusions repeatedly — that’s when it’s time to shoot first; recalibrate later. It’s tempting to kick the proverbial can down the road or pencil in another meeting to rehash the conversation. But remember: indecision is itself a decision. Doing nothing can doom you just as much as doing something. Was it in Paris’s best interest to defy the wishes of Zeus and refuse to give the apple to any of the goddesses? Give Aphrodite the apple and move on with your life.