A magazine about programmers, code, and society. Written by humans since 2018.

Why Not Both?

There is a question that has been around forever, and that we love tossing around now and then: is programming science or art? Some are adamant about the fact that it is related to computers, and it is very technical, so it is surely science. Are they (completely) right?

I will start with the obvious science-y part of programming. At first, we learned how computers work. We learned how programming languages translate into computer language. We learned how programming languages are composed, how they are structured, how they work.

From Science To Art

We learned that at some point there were not any! We “talked” to the computer through physical punched cards. That was still a form of programming.

Then we started writing our own software, and ever since, we struggle to squeeze as much performance out of it as possible. We learn to apply the best algorithms, and in case of the UI, to use those algorithms in such a way that UI performance is not hindered. We strive to deliver the fastest network responses, the fastest file loading, or the fastest frame rates.

We learned how hardware works, if we chose such a field, so we can correctly program whatever device we are working with. We need to know what the device can or can not do, at the very least, so we know if what we are trying to accomplish is even possible. This might be thought of as software still, to a certain extent.

Even if we did not choose such a field, we might still learn how certain hardware or parts of it work, like networking, displays or storage:

  • We struggle to keep our binary sizes small.
  • We think and care about the efficient communication between our software and the device it runs on, for example when working with local storage or aiming for a high frame rate.
  • We also think about the communication between our software and other devices, and everything in between, for example when working with cloud storage or Bluetooth devices.

We learn and try to use the newest and best features a language and/or framework has to offer. Newest sometimes means improved, optimized, faster, more efficient, so it makes sense to do so.

We learn different programming languages, as to expand our knowledge, mindset and field of view; to learn how “others do things”; to learn new paradigms. It helps us grow.

We hunt for bugs and sometimes we turn our minds inside out to solve them. We have to rewrite entire parts of our software because the initial science behind it was wrong and there is no way around it; we have to start from scratch.

We strive to follow the best practices of the language we are working with. That is why they are “best practices”, because they have stood the test of time and the majority agrees over them.

We even learn about the science of human nature and behavior. We all know quite a few examples of shady practices in emotion manipulation, but I hope all of you use it for a good cause, as in creating a good user experience with buttons that are obvious, text that is readable, controls that are easy to use and easy-to-follow flows.

Transition

Have you noticed when we started moving from science to art? It happened a few paragraphs above, when we mentioned learning new programming languages. The computer does not care what paradigm we are using; it does not care if we follow the best practices; it will relentlessly execute exactly what we tell it to. So we better write in such a way that we understand what it does, and easily, otherwise we are the ones in trouble.

Writing clean code. Building a correct architecture. Laying out a correct project structure. Clean names. Paradigms. Architecture. All of this is part of the artistic side of programming. Part of the “delivering an idea, a concept, a message to another human” side of programming.

Writing clean and well structured code is of no concern to the computer, there is no science behind it. But, just like a piece of art, it delivers a message in a clean way; it is easier to look at, more pleasurable to look at and easier to understand; it grows on you.

Laying out a correct project structure is of no interest to the computer, it serves ourselves to more easily find what we need; to better understand how pieces fit together and how the data flows. Just like a piece of art puts into perspective and emphasizes the most important parts, but also guides your eyes from one area to another.

Clean names and paradigms affect the computer in no way. It does not care if we name a method perform or performFadeAnimation. But it will help us to better understand what the instructions are. Just like a work of art that has its elements properly defined, balanced and obvious.

Our Audience

Ultimately, we do not write code for the computer, we write code for humans. The computer will not care how we lay out our code, structure, or name things; you could have one line of code that contains your whole program, the computer would not care, as long as the science part would be correct.

But may the Universe have mercy on you when you will want to read what you wrote there. Just like an ugly painting, you would rather throw it away than look at it, not to mention enjoy or make use of it. You have seen it. You have been handed it. You have written it. We all did. And we all cried because of it; we all wished it was not so.

On the other side, think of the times you stumbled upon good code. Properly written. Properly structured. Easy to understand. It felt inspiring. It felt like looking at a work of art. And it was!

Be An Artist

Do not just write code for the sake of telling the computer what to do. Do not just care about the science-y part. Strive to write understandable code. Beautiful code. Correct code. Because at the very least, you will be the one looking at it in the future, if not others as well.

Just like a painter learns how colors blend, how shapes emphasize or affect emotions, how different brushes work, what kind of paints to use for what purpose, or what kind of canvas, so we have to learn the science behind computers, programming and devices we will work with. To know what tool to use for what purpose, what language for what project and what architecture for it, to understand how different devices work so that we can interconnect them, or what particularities the device we are building for has.

But just like a painter strives to deliver a clear message, to properly structure a painting, to emphasize certain aspects of their creation and to guide your eyes easily throughout the story, we have to do the same. We need to send a clear message, to build an easy-to-follow story and to emphasize the important bits. We need to know what canvas to use, what paints work properly on it, what colors and shapes to use, what brushes to use and for what purpose.

Use science to understand how programming works, to build with it. Use art to decorate it, to easily send the proper message to the next person after you, even if that person is you.

Cover photo by Clem Onojeghuo on Unsplash.

Continue reading The Art Of "The Art Of Computer Programming" or go back to Issue 004: Programming, Art Or Science?. Did you like this article? Consider subscribing to our newsletter or contributing to the sustainability of this magazine. Thanks!
Back to top