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.
Continue reading “Software Craftsmanship”
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:
bash: clcs: command not found
[aka I don’t know this word]
Continue reading “Human Computer Interfaces”
June 30, 2009, Bucharest
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.
Continue reading “Computer Programming”
I had the unique opportunity to spend about a week with J.B. Rainsberger (website and second website) and Corey Haines (website), in what proved my best learning experience of the last few years.
Continue reading “What I’ve learned from J.B. Rainsberger and Corey Haines”