Art of programming
I’ve been doing programming since I was 15 and my process of learning hasn’t changed that much. I get into work and discover. Run the code and figure out why it is failing and try to solve it and thus learning something new. Sometimes I do start with a YouTube video or an article, but it usually begins with a simple “Hello World” on screen. The process of work has not changed either. I get the task, analyze it, and write the code. Pretty standard.
But recently, I started to look at my work differently. I started studying MBA in fashion and luxury in Paris and being around the people in this business, artists and designers changed the way I looked at the work in hand. It was not only the “task” that needed to be done, but details were important. Especially the details. I spent 6 months in school and started to appreciate this approach.
Now that I am back to programming, I started to see things differently. I want to view what you do not as a “task” that needs to be “done,” but a “piece of craft” that needs to be “just right” as E. H. Gombrich says in “The story of art.”
“What an artist worries about as he plans his pictures, makes his sketches, or wonders whether he has completed his canvas, is something much more difficult to put into words. Perhaps he would say he worries about whether he has got it right” E.H Gombrich, The story of Art
Coding like you are creating something new and unique is essential. Being sensitive towards your code’s quality like an artist that wants to leave a legacy. This is a very individualistic approach to coding. As if it is only you and you who will see the code and you have a high standard. As you grow and learn new things your sense of the “just right” improves and you cannot say the task is done unless you make it right. For example, you read about SOLID principles, and when you are writing or reading code, you won’t say I have to check if it follows these principles, you immediately sense it. It makes you uncomfortable if it doesn’t follow them. It is not the right code.
What I am trying to say is that, it is two different things to try to write good code or that you cannot write bad code. The result might be the same, but the approach is totally different.
I think programmers already have this approach at some level. They have a sense of right and wrong in general, and they apply it. At worst, a “right” code needs to work. That is obvious, and it might be unusual even to mention it. But we can say that the feeling that you get when a code is not working is as same as the one when you get when the code is not “just right” if you follow this approach.
I love to solve a problem and make it work. And although I think it is an essential aspect of it, there is something special in the slow made process, the manner and the way at looking things that made me think that maybe I should change the behavior that I have toward my process just a little bit. Indeed being observant to your habits and approaches would be the first step. Being somehow intentional on what you think and do. The way you design a solution and implementing it.
Now I do see my work as a craft. I see what I do as a piece of art. That needs to be “just right.” And the “just right” would develop as you grow as a programmer (artisan).
What would change
Why do I think it is a better approach to working? I have several reasons for that.
First, learning and improving yourself becomes a habit. It is not that you have to know the smart solutions or principles, it is part of your process as a creator. You are doing it, not only to do the task but to improve your sense of right and wrong. You become a better programmer.
Second, in every task, you have an idea of why you are doing that task. It is not you only do this just to do your job, but since you are putting your heart and time and creativity (skills) in it, you want it to be as beneficial as possible. We do tend to do this way of thinking when we are choosing a job or project, but we often forget it and get lost in the pile of tasks that we have in our job. With this approach, your individuality and purpose always have a place of attention.
Third, the task would become fulfilling, much more. It is fun to think that what you do is actually a passion project. Similar to an artist, you see it as a piece that needs to be developed and improved. The process becomes much emotional.
Challenges
With this approach comes many challenges. There is no denying that. We are talking about putting all your standards and task management on your “will,” which is not as strong as it sounds. Also, let’s not forget about the fact that we could become too perfectionist, and with a high demanding environment, being picky will cause problems. Also, there is a fundamental contradiction between “slow made craftsmanship” and the tech world.
I don’t think because of these challenges, the whole idea is not valid. I believe artists also face these challenges. Even without this approach, a programmer might face these problems. Being an unproductive perfectionism, time management and etc, all happen even if you don’t follow this approach. All of these challenges need to be addressed and analyzed. We should at least be mindful of them and try to understand it.
In the following articles, I will continue studying this approach. I want to explore some questions that I have in mind. Like is it possible to teach how to be a good programmer (engineer) even before showing how to write one line of code? My goal is to compare how an artist works with how a good engineer and mainly a programmer works. I believe there are many similarities, and studying them could help us become a better programmer or even a person.
