Art evolves

Merriam-Webster dictionary defines “art” as “the conscious use of skill and creative imagination especially in the production of aesthetic objects.” A few famous examples are Da Vinci’s Mona Lisa, and Michelangelo’s David—artworks well appreciated for their aesthetic appeal. Paintings and sculptures changed over the years. Styles evolved from the Da Vinci’s renaissance style to more surrealistic style, to cubism and minimalism; Mediums changed from canvas, to digital illustrations.

Some art forms are not appreciated for their aesthetic value, like music, or literature and poetry. Yet, some ways of sharing such artworks are with a written document, e.g. music sheets and lyrics pages for songs. These art forms evolved as well and new genres of the written word came to be.

One of those genres is code.

Code is art

Code? Art? How so? Well, to begin with, coding does require skill, like in the definition, and most products that are software based were inspired by imagination, like in the definition. However, going by definition to convince people that code is art is a pretty weak argument. Let me cover some more aspects of art that are common between the forms I mentioned before and coding.

• Requires attention for details. Just like missing half a tone when singing, using incompatible colors when painting, or repeating the same word within a poem unnecessarily, code needs to be written with special care. Naming your functions and variables should make the code clearer to the next person reading it, the flow should be easy enough to follow and the general structure of your project and files should make sense. That’s beyond aesthetics, it actually may cause mistakes later on and make the piece worthless if it can’t be run.
• It can be refined. A band may have several rehearsals, a few sessions in a recording studio, and spend weeks on after-production for a single song to become the best version of itself. Same goes for code. Team members spend a lot of time code reviewing to make sure the written code is up to the team’s standards.
• Practice makes perfect. Becoming an artist takes effort. You practice your craft for years until someone acknowledges your work. Just like no one is a born pianist, painter, or sculptor, no one knows how to write the best code organically. Developers take courses, make projects and work for many years to improve their code writing skills.
• Bringing something into existence. A painter visualizes an image, takes a brush, canvas, paints and starts manifesting it until the image is on canvas. A developer has a problem they wish to solve or a product they wish to create, takes the keyboard, opens an IDE and starts writing code until there is a solution or a product that runs and solves the problem.
• There are standards. Classical art works can be critiqued, discussed, and compared to one another because there are standards we can judge them by. Same applies for code–there are many standards and practices that developers use to evaluate their peers’ work (such as SOLID, DRY, LIFT, etc.).

IaC is beyond engineering!

Developers often have a specific field they feel more comfortable in when coding – frontend applications, data engineering, cyber security, etc. Each field has its unique set of best practices, coding standards and tools that help executing it better, and make the final result look more artful. A field that at first glance may look a bit less artful, as it mostly consists of declarative languages, and deals with configurations and settings is infrastructure as code (IaC in short). However, that is a fallacy. IaC is not just writing a configuration that should describe your resources. As the name suggests, it is CODE, and like any other, it’s beyond engineering, it’s ART.

Let’s look at an example of a simple static website that demonstrates what I mean by “IaC is beyond engineering”. I will use this git repo’s tags as reference points. The example is for a Terraform project, but the same principles apply for many other languages and tools.

Let’s have a look at version 1.0.0. At first, it may seem like an elegant solution, a single file, no need to look where anything is configured. But when looking at the file’s content, we can see it contradicts the principle of “single responsibility.” It deals with configuring the Terraform provider we use, the entire set of needed S3 resources, and the output of the entire project. That, by most of developers’ standards, is not a very pleasing or elegant solution.

This concern is resolved in version 1.0.1. Here we now have three Terraform files, one for providers and Terraform setup, one for the bucket related resources, and one for the outputs. However, we mainly migrated numerous resources and configurations into a new file, [.code]s3.tf[.code]. This file still does a lot, and most of its content is pretty much boilerplate. We can, and should, find a more refined solution.

‍

Our solution in version 2.0.0 helps demonstrate one of the more important techniques in programming: encapsulation. When we want to reuse the same complex functionality over and over again, we extract the core functionality into a new class, function, module, or package (depending on the language and platform. For Terraform, it’s Modules) that can be used easily when and where we wish. Here, the S3 bucket was split into separate files and we made the module create it by only requiring two inputs: bucket name prefix, and the index path. A good encapsulation will make the code base more aesthetic, and it also shows a great amount of creativity and imagination, some kind of an art form on its own.

Basically, the three versions above do the same job: host a static website on AWS using an S3 bucket. Yet, we saw that as we proceeded with the versions, the solution became more elegant, and required a bit more creative work to manifest. Just writing an IaC without creativity might get the work done at first, but will be problematic to introduce to a team and maintain in the long run.

Developers are creative people

After establishing that code is art, both for the general case and for the private case of IaC, there is a derived conclusion: developers are artists.

Developers invest much of their time perfecting their craft, learning new disciplines, studying from each other, and no one can deny that developers are skilled people.

Furthermore, they use a lot of imagination. Most if not all the tools out there for developers are made and maintained by other developers. More often than not, the same problem has many solutions to choose from, thanks to the initiative and creativity of the developers’ community.

Lastly, like many other kinds of artists, many developers practice more than one field, i.e. they have artistic outlets other than code just like many singers play the guitar, actors participate both in theater, movies and cinema and may also learn how to sing and dance for parts. Some may have more “traditional” creative hobbies: singing, photography, playing musical instruments, but others often tend to write professional blogs (like on medium.com), have YouTube channels where they make tutorials and some even enjoy public speaking in conferences - all express a variety of skills, creativity and imagination different than those for coding.

env0 helps you bring out the artist in you

Once the artist finishes writing his work, the work is not yet complete. Having a written play doesn’t suffice—there should be actors that perform it, and perform it well. Same for music sheets, without the right player to follow them, the piece doesn’t fully come to life. Moreover, using the right instrument is just as crucial, that’s why guitarists change their guitars mid concert for certain songs. When it comes to IaC, env0 is a great tool to help the code come to life and even open a door for a new world of possibilities.

Let’s view an example for a creative use of env0’s capabilities that will add a more personal touch to our static website. In version 3.0.0 I added an [.code]env0.yml[.code] file that describes how the [.code]index.template.html[.code] should be altered in order to display an environment variable named [.code]NAME[.code]. By using Terraform alone we couldn’t accomplish it, but with env0’s custom flows, and a bit of imagination and creativity we created a new way of deploying our not-so-static-anymore website.

Another helpful feature that helps maintain high standards of writing IaC is the use of plugins, such as TFLint. Version 3.1.0 extends [.code]env0.yml[.code] to include a step for running TFLint before the Terraform plan. The code also changed according to the output of TFLint to make sure our deploy will pass.

Finally, to make our code even more compact, elegant, and focused on its single responsibility while using the full potential of Terraform modules, in version 4.0.0 I used env0’s private module registry and published the previously private module to it.

As we can see, the right tool enables us to create better art works, more easily. env0’s set of features enables the inner artist inside every DevOps engineer to discover new ways to express itself.