Code Outside the Box

A couple years ago, Something inspired me to change my approach to learning the trade of software development, and I think it’s worth sharing.

Designing and implementing software is just one of many trades which responds well to having a good balance between creative and technical lines of thinking. The challenges you face when making stable, available, performant, and well-supported software systems require technical proficiency, but technical proficiency is not enough. The old adage “Think outside the box” applies too.

Sometimes using the right tool for the job isn’t enough–you have to get creative.

Sometimes inspecting and debugging bits of data and tracing logs is not enough to solve a problem–you have to get creative.

Sometimes the tools you have available are enough–but you can still get creative! And that’s where creativity inches you away from being an operator, and closer to being an innovator.

What do I mean by that? I’ll give you a personal example.

In high school I was introduced to the joy of web development. I did what any inspired young web developer would do: I used Google and StackOverflow, found blog posts and tutorials, downloaded libraries and frameworks (PHP and Ruby on Rails, if you’re curious), and just ran with it. I coded. I wrote bad code. I built useless apps. I had no idea what I was doing, except that the more I learned, the more I developed an appreciation for the chance to experiment and try to improve.

This informal way of learning feels natural to me, and has served me well…to a point. When I managed to make it my profession, something started to change. Over the years I started to pay more and more attention to the technical aspects of programming, and the creative aspect became more of an afterthought.

One day, a conversation with a stranger changed my outlook completely. It was something so simple, but it made a huge impact in how I decide to approach problem solving and reaching for innovation.

Without the irrelevant datails–I shared a problem I had been having with the design of a REST-like HTTP API, in on online chat room. I expected answers that would be familiar - how do to REST the “right way”, pitfalls of API design, etc. Instead, the stranger explained to me that REST might not be a good fit for what I was doing, and that I should consider other paradigms, such as CQRS and Event Sourcing.

“What the heck is Event Sourcing?” I thought.

“What the heck is Event Sourcing?” I asked.

I had never heard of it. I pressed for details. I asked for resources. I signed up for mailing lists and forums and watched conference talk presentations on YouTube with CQRS and Event Sourcing as keywords.

There was nothing “magical” about event sourcing, it’s not a magic bullet that suddenly solved my problem, and it’s definitely not something that was easy to grasp at first.

Why was I so blown away to find out that there was a completely different way to architect a web application that turns the blog posts, tutorials, and books that thought me all on their heads? When I go to write some code, why do I think “How do I do REST right” and why don’t I instead think “How do I solve this?” at a much more abstract level? Now I do. The biggest takeway from that encounter, and the jounrey it promotted, is to be mindful of the balance between techincal and creative, and to keep creativity in the toolbox when solving hard problems, and most importantly, to challenge my own assumptions and from time to time ask myself “Is this the only way to do things? Are there new ways, or ways new to me?”

Event Sourcing in particular is just an example here–this life lesson could have stemmed from any particular thing. But I’m grateful for the lesson, and remind myself of it regularly.

Solve technical problems creatively.

Challenge your assumptions.

Be open to alternative solutions, and seek innovative ones sometimes instead of just reaching for the old toolbox.

Code outside the box.