TL;DR - Good engineers deal with reality. We bring concrete, practical, and real implementation to precisely architected solutions that solve for value. We need to remember that this doesn’t change no matter what gets thrown our way. We are a sect of crafters of the reality in our business - and reality is where dragons go to die.

Imagine a dragon (can’t be that hard, they’re imaginary) blowing through a fantasy town. Often times, being a part of an engineering team can feel like you’re one of those houses on fire. The dragon, of course, is not a singular thing - alas, nothing is ever that straightforward - but rather multiple problems stacked on top of each other in such a perfect way that it feels like some sort of dark alchemical conspiracy.

Really tight deadlines meet misaligned business stakeholders married to a straightforward product. On top of that, the product is only straightforward in the product owners’ heads because in actual fact, the whole state of the union is built on shaky and oftentimes neglected legacy that creates its own magic circle and Bermuda Triangle-like experience where time, focus, and effort disappear into and die. No rhyme or reason necessary or even involved.

In the world of “enterprise” - more often than not - things just happen and no one is around to explain how and why anymore. Those people have been immortalised in stories about bringing down prod or running an entire enterprise application with stored procs on SQL - and if you’re lucky - their glorious names would be forever sung in the git history.

“Here be dragons”.

We’re right as well. This feels like a magical beast that keeps on getting up every time you put it down, and you eventually come to realise that - what you thought of as “slaying the dragon” was actually just “ticking its foot slightly”.

Although….

Slay? I suppose not…

We hear stories about “slaying the dragon” - but is “slaying” really a good strategy?

Let’s look at this logically: your entire journey, you would have to have all of these magical things line up in the perfect way for you to accomplish this. You need - for example - a magical blade or weapon, a party of adventurer companions that are each uniquely and coincidentally perfectly gifted for the task at hand, and a good storyline where the protagonist learns a good lesson or moral.

All of this is bullshit.

Ironically, the only thing that isn’t fantasy are the lessons you learn at the end of the story. While this may be an epic pursuit, we are not the heroes in this story of business value and the reality is - we don’t live in a Tolkien novel (despite one of my deepest desires being so). The harsh truth in the corporate world is that the lessons we learn are only valuable if we can use them to increase efficiency, efficacy and importantly to enhance the value of the product that the software is servicing. Unless you build OS’s or comparable things where the software itself is the product - the software is not the primary artefact. It is the realisation of business value.

Alas, you also can’t talk of “slaying” when there is no beast to slay….

Is it real?

Sorry to bust this fairytale but there’s no such thing as dragons. These mythical beasts in our field, dear reader, are just optical illusions that only appear so at a distance.

Don’t get it twisted. I’m not saying that your problems aren’t real - I’m just saying that the reason they seem so insurmountable is possibly because you’re looking at it from too far a distance. Dijkstra once said that “abstraction allows us to converse about things with precision”. I’m a huge believer and fan of this personally - but it does not lend well to situations where you as an engineer or engineering team have to deal with other engineers or engineering teams that may be further behind or ahead on the maturity scale than you and yours for example. What is the use of precision if you can’t even “converse”?

A scary solution

A way to take the dark and sinister magic away from these seemingly large and pervasive issues is to simply get closer to it.

This is hard. It’s counterintuitive and feels scary. I’m basically telling you to move closer to something that really looks like a horrible beast of mythology - instead of telling you to stay safe and keep your distance. I can appreciate if that feels like bullshit, but - ye bit of faith. You won’t be able to understand what’s really going on until you lean in and until you really understand what’s going on - and I mean really, truly understand the nuances of the issues and strategies of where the business and tech form that chaotic vortex - things will look like indecipherable magic. Understanding brings with it a clarity and comfort, and these seemingly unsolvable problems start to become opportunities to apply your training and craft as an engineer. Isn’t that all we want as creatives and builders of cool things?

Good engineers deal with reality. We bring concrete, practical, and real implementation to precisely architected solutions that solve for value. We need to remember that this doesn’t change no matter what gets thrown our way.

We are a sect of crafters of the reality in our business - and reality is where dragons go to die