The other week I went on vacation with my family. We flew to Switzerland and had a really great time. I took the big camera to make gorgeous shots of my wife, my baby daughter and the Alps. The iPhone camera is great but pales in comparison to a professional camera. As I am no great photographer you can see this in every shot. But still, the pictures I made with the DSLR are just better. When using a big camera I always try to take more time for the composition of the shot. I use the lens, different focus spots and depth of field way more than when shooting with my phone.

Because my photography skills still lack, I try to read articles from professional photographers to get ideas and tips on how to improve. An article that made me think was about a photo-marathon in Munich (the article is in German). A photo-marathon is a one day event. You get multiple themes and have limited time to find a suitable picture for each. One thing I noticed was the photographer who wrote the article made sure to have a distinct visual language present in every photo he took: He cared for a hard horizontal line in the lower third of the image and wanted to only take pictures of architecture. His skills are on a very different level than mine but we both took the time and tried to think about what we want to show in our photographs and how to frame it. You could call it a style or a handwriting that your images show.

That made me wonder: When was the last time I really thought about my coding style and handwriting?

Thinking about my code handwriting means different things for me. On the one hand there are things like which programming language do I use. Do I write comments inline, do I write comments at all or do I let my code speak for itself with method and variable names that show their intent? But there are also fundamental decisions: How do I structure my applications, monolithically or modular? Do I refactor regularly? Do I use certain design patterns?

These are things that form my code handwriting and it’s no wonder that people who care about these things write them down in style guides. There are best practices that many people propagate that make your code handwriting easier to read and easier to understand – especially for people who aren’t used to your style. So please take care how you write your code and develop your beautiful and unique (code) handwriting.

This article could end here, but let’s turn back to our professional photographers. To the people who know the rules of composition inside and out. People who took many photos and know how to take them well. People how shoot photos intuitively that are a joy to look at. You know what some of these people do? They deliberately ignore all rules and create something that is truly unique and recognisable. In the eyes of the spectator that might not always be beautiful or even easy to look at, but it is art (at least that’s what they say) and it is their form to express themselves.

So let me end this article like this: Sometimes, to evolve your craft and find a new way, it is okay to ignore all or at least some rules when creating something. Software engineering is a creative, inventive and demanding art and you should take the time to question and ignore held beliefs when you create something. Don’t care about conventions or how other people might think about your work. Treat programming as the creative art form that it can be and deliberately go against some of your rules. Write a class with 300 lines of code and only one method. Name your variables a, b and c and don’t care what value they might have. Write a program that is just one big file or write something without line breaks. It will feel weird at first but I bet you’ll get a new perspective on things. And it never hurts to adjust your point of view. If you’d like some ideas have a look at these Github repositories. This is art.

rkh - almost-rackup

rkh - almost-sinatra

If you take a look at these examples you might wonder what they’re about. I did so as well. First I put it off, thinking this is nonsense and unnecessary. But I changed my mind. I would like to admit that I cannot really read that code. Looking at it makes little sense to me. It looks like code you’d expect a code uglifier to spit out. And then it hit me: I use uglifiers/minifiers on a daily basis to minify code for production use. But I never cared for how they work.

Maybe this is a thought and a style lesson. What does it take you to minify your code yourself? Do you get a deeper understanding from minifying code by hand? What does it teach you about your programming language? And what do you need to learn about your programming language to be able to minify your code by hand? Is minification deterministic?

I do not know. But I am intrigued to find out.

Yours, Holger

PS: This is an article I wrote 4 years ago on 02. Sept. 2014.