I spent my last few months living at my in-laws farmhouse, somewhere in the country side Romania. The farm is a typical Romanian one; upon the first sight it looks as if time has stopped 100 years ago and people went on living in the same way they did for hundreds of years before that. The only modern artefacts you can find there are electricity, cars, old TVs and the Internet connection that I’m very grateful to use to report for my readers.
The family is very usual for these parts: three and sometimes four generations (especially during holidays) living under the same roof – or in this case, under two roofs since there are two houses. From 9 to 90 years old, we live all together, sharing excellent fresh food from the farm, wonderful walks on the hills that guard the farm and delightful stories, while also doing our jobs and helping one another in any way we can. I can tell you that for any creator, this is the perfect environment. The combination of silence, little adventures (around the farm or involving the neighbours), lack of concerns that so easily take over your life in a city and fresh air makes it the perfect location for writing the next story of Frodo, Samwise Gamgee and Gandalf the White. (Or its equivalent in programming, although it will be extremely difficult to see something of this magnitude happening in software).
I first learned about software craftsmanship from Corey Haines, when he talked about it at OpenAgile Romania 2009. I’ve noticed many times that entering a movement depends a lot on who explains it to you, and Corey was the perfect person to do that. For those of you who don’t know him from his travels, speeches, classes and tours, he’s an easy going, soft speaking guy who’s very strict about professionalism.
I found the idea of software craftsmanship to be what I was looking for when I was trying to explain to developers what they don’t do well. I’ve understood at the same time what I don’t do well, which is at least as important. So you can fairly say that craftsmanship showed me a way of bettering myself, and that’s what we tried to do for other people as well, through the AgileWorks community. You could also say that the way I see craftsmanship has been deeply influenced by Corey’s views.
I discovered that one of the things I used to do in the wrong way was a certain bitterness and arrogance when explaining to developers that they’re not doing the right thing. I understood afterwards that I have to learn a lot of things and that any developer is doing something right. This lesson was part of a larger one, the lesson that adding value is much more important than bickering. There are always things that annoy, things that create negative emotions; I’ve learned that I need to ignore them and to focus on the things I can do to add value.
It’s thus fair to say that my encounter with Software Craftsmanship changed my life for the best and therefore I’m deeply involved in this movement and strongly connected with its values.
There are two ways to have a conversation with your computer: by discussing directly with the application or computer (Command Line Interface or CLI) or by discussing with a metaphor of the computer (Graphical User Interface or GUI). Both have advantages and disadvantages.
CLIs are very powerful and provide a real environment for discussion: the user writes their command or question and the computer answers to it. For example:
Computer programming is a mean of communication. You communicate using a language with two very different types of interlocutors: computers (obviously) and people (not so obvious).
When talking to the computer, you have to be very careful at clarifying each nuance of your story. Computers don’t know how to interpret multiple means of the same word and phrase; you have to give them the exact words, arranged in the expected way, ordered exactly according to the rules. Whenever you don’t, bad things happen.
The people you communicate with are: whomever reads the code and the users of the application you are building.
The people reading your code are much like people who read literature: they like it or not and comment about it. The difference is that many times, they need to change your program, so a bad execution hits them much harder than a bad book that they read. On the other hand, when the reader becomes also the writer he has the chance to improve the story. The good writers will always leave the novel better than they found it, even if only slightly so.