Concentrating on the Errors

Yesterday I again attended the monthly Agile Dinner here in Helsinki. I almost skipped the event due to other engagements but finally decided to go. I'm happy that I did, and want to thank everyone else who was there.

We again discussed a wide variety of topics, ranging from how tidy our rooms are to the familiar Mac-Linux-Windows battle. I found the discussion about the psychological side of decision making etc. to be particularly interesting.

Choosing to do things the way one has seen them done before successfully can definitely became a subliminal decision. This kind of "muscle memory" can be a great advantage and save one from stopping to think for choices when there is actually only one way to do things correctly (or at least efficiently). Then again, I believe this fights the "thinking outside of the box" attitude in a sense. Of course learning such a way should only happen when that way of doing this has proven to be good. Still, I think never questioning "the one and only way to do things" prevents improvement of methods (or processes, if you will) from ever happening.

Another - yet somewhat related issue - is having a strong opinion on or getting used to the way things should be or look like. Take code formatting, for example. Using opening braces based on the C convention (brace on its own line) in Java code can sometimes disturb me so much that I simply have to fix it before I can start really reading the code and finding out what it does. This applies to whitespace also, even more so. Not to mention importing classes one never uses etc. (I could go on for quite a bit here...) Luckily I can fix these "anomalies" in code using reformatting commands in my IDE in half a second. Still, it raises the question whether one should be such a fundamentalist when it comes to code formatting if it actually prevents one from seeing "beneath the surface" and concentrating on the what the code does.

These are of course not programming related issues only. Like I said yesterday, I know people (and might be one) who can be absolutely unable to concentrate on the semantics of some text if there are many punctuation or grammar errors. So, the errors can be the only thing one sees. I think it's clear that numerous errors will make the text unreadable for almost everyone except the person who wrote it, but the number or severity of (e.g. spelling) errors people can tolerate varies tremendously.

I wonder whether it's after all a good thing to be a purist in these issues.

Iterative Art

After watching a movie or listening to a song, I have sometimes heard people say how they could improve the existing work of art we have just enjoyed. And I believe they could be right, when the definition of quality is theirs to decide. This is the case especially if they could have the talent of the original artist at their disposal.

However, if they faced an empty canvas or had a reel of empty frames, I think very few of them would be able to create (or ask for) the same result. So, the best way to achieve the most pleasing result (at least from the viewpoint of the customer - artistic visions aside) would probably be to let the parties take turns to do their part: the customer would first describe what she wants, then the artist would make a first sketch, after which the customer could ask for modifications or just let the artist continue in the current direction, etc. And I have no doubt that this was the way that even well-recognized artists worked when they were paid for making portraits of wealthy people.

I have often compared programming to painting or other (visual) art skills. Even though some artists might find the comparison quite offending, I believe we face the same challenge in filling an empty canvas, although the result of programmers' work may be a little more functional in nature. Thinking about the process described above, I guess we can have something else in common, too...

A New Beginning

The first couple of weeks in my new job have been really nice. The atmosphere is really relaxed, yet ambitious and supportive. Also the people have been nice, so I've settled in very well.

Agile methodologies have also found some fertile ground there, before and after my arrival. To my (pleasant) surprise, my second working day included a presentation about JUnit to everyone who was interested. There was also interest in going to the recent Agile Seminar. It was made clear that attending the 3-hour seminar would count as working hours. This was a really good sign, helping me to feel that the company wants to support its workers' learning. There were four or five of us who eventually attended the seminar.

I also had a talk with the colleague that gave the JUnit presentation and asked him to join the next Coding Dojo. Only one or two days later the next dojo invitation was announced, so the timing was perfect. We went there together and talked a little about giving an internal dojo session at our workplace later. I believe the TDD knowledge level is not sufficient yet for a full-blown randori, so we might start with a lecture-like approach.

I'm actually feeling really busy nowadays at work. Not because of the workload (which is actually really decent) but because I'm eager to participate in everything that helps us get our processes better.