Those are the moments when the mind start to run, when there is nothing between what the thought gives birth to and the reality, those are the moments which every artist craves.

To the unexperienced eye, coding is surely a trivial and technical skill, in this century we all know that computers are just a collection of ones and ceros, we all know that machines do not think nor learn, that is just math and probability, computers are actually pretty dumb objects. Computers do not think nor reason and they loyally do as their programmer wrote, step by step, with no exceptions, with no reinterpretations, with no opinion at all.

So coding at the end of the day seems a very easy task, you study how the computer work, how to talk to it, how the problem at hand can be solved using technology and then you just write the code. But if there is something I have learnt in my professional experience, that is not much so please be kind in your judgment, is that there is always more to it. Every single time, code starts as a very simple and straight forward task that ends up being almost an artistic endeavour.

A fascinating, infinite, puzzle, a blank painting canvas, maybe thats what an empty file look to us.

How does a painter chooses to paint a mountain? I am not a painter myself so I don’t have an answer to that question, but I certainly know that to paint a mountain is an act of free will and there are infinite ways to achieve that. Sounds familiar? Thats what code is, really. A blank canvas where creativity, style, math and ingenious thinking collide, and at times fight, to solve a problem, a puzzle.

But solving the task, with this kind of creativity, is not enough. Solutions in code need to be simple, they need to perform well in our computers run time, they need to be readable not just for the machine but for us humans too, sometimes they even need to be able to scale, to serve millions of individuals worldwide. Here is where art begins, were solving the problem is the bare minimum and solving it elegantly is the artistic goal.

Some days ago I tried to read “The Creative Act” by Rick Rubin. I did not like it, as a personal opinion I feel like there is a good number of books out there about creativity that do not try to communicate every sentence as if you were reading a ethereal and philosophical book, Creativity Inc by Ed Catmull for example.

There is one thing I can accept and embrace, however, from Rubin’s book, every one in an artist.

I do not know when did it started but at some point in my life I decided I was not good enough to draw, funny, considering my early life plans of pursuing an architecting career or the fact that in my youth I did attend to drawing classes. I was, in fact, not that bad at drawing, but somewhere along the way I found myself undeserving of making art.

Truth is, architecture was not the right path for me and I can surely say that computer science was, but these doubts of “am I not good enough to make art?” were crippling, life is just a long search for beauty and to exclude yourself of that is just plain sad.

Is coding an art?

Maybe we are just tasteless engineers, humans after all, with an innate desire of looking for beauty. Is life worth living without beauty? I do not think so. Maybe we just want to be part of this exclusive group of people capable of creating and finding beauty in the mundane.

Or maybe, coding is in fact an art, maybe there is some kind of beauty in the words we desperately write in our text editor, maybe there is magic in all of the possible combinations we can create, maybe there is something amazing in how we build complex systems just with a small dictionary of basic words.

Maybe it doesn’t matter.

Maybe art has different definitions for all of us, maybe, defining what art is, is actually not that important nor trying to figure it out if coding enters in that definition. Who cares.

This is how life works, I do not think that truth and reality are concepts that apply the same way for all of us. Like the observer effect in quantum mechanics, my reality is different from yours, not because the universe decides its presentation according to who is experiencing it, but because my perspective about it is unique and can not be replicated.

This, I guess, applies for software engineering and systems design too.

How many times, as a junior engineer, you had been tempted, by your lack of understanding, to rewrite an entire code base with the naive excuse of “How is this possible? This is a bad implementation, I can for sure do it better”. I have fallen into this trap many times in the past, but it is important to recognize that this attitude towards solving problems is not sustainable.

Understanding that material conditions determine which is the correct design choice at a given time will free us to take action into whatever solutions seems to fit the problem at the time, not caring too much about the solutions that seem correct but end up being more complex and complicated.

Have you ever found yourself as a one man army trying to implement a hole solution by yourself just by playing and making proofs of concept? That was my situation some years ago trying to start a data lake initiative, after reading and trying to arrive to a conclusive architecture a specific question arouse. Was I going to implement an Apache Kafka cluster with its respective Debezium connectors cluster to make a real time data extraction or was I going to use a managed solution like AWS Database Migration Service?

I can confidently say that as a whole, Apache Kafka seems a better solution, I have been using DMS for some time now and I do have some disagreements with the service, I do not like how it works and I think that at least with the CDC functionality, DMS has room for improvement.

But then again, which was my situation at the time? I was the only one implementing what was going to be the “data architecture” in the organization, delivering some value as soon as posible to highlight the improvements of this solution was important and last but not least, I was limited in my knowledge doing cluster administration.

Looking back, implementing Kafka would have ease my current experience, but Kafka was not the correct decision back then, this, taking the material conditions into consideration. DMS was a great service to start generating value and building what now a days I can call the data team inside the org.

Conditions, like humans, change, and decisions made in the past become obsolete. Today, replacing DMS for Kafka seems inevitable, but arriving to that necessary change was a whole journey by itself. I am no longer alone nor I have to demonstrate the value in having a strong data architecture, the conditions have changed and the correct answer for that specific question then changed too.

Note: This is a personal blog, if some fact is wrong (and someday one will be) please be kind and let me know, this is not formal advice nor writing.