October 20, 2011

That’s just perfect!

Filed under: Learning,Process,Programming — Freek Leemhuis @ 7:22 pm

I’ve been thinking about the concept of ‘Perfect’ recently.

In our business there’s a lot of talk about self-improvement, excellence and similar concepts.
Often the discussion is lead by ‘agile coach’ types who can not program their way out of a paper bag, but that is another story for another day.
The ‘Perfect’ meme is used to promote Deliberate Practice, as perfection is elusive by design and so by aspiring to perfection we can continue to learn.
Personally I find it a lot clearer to strive for improvement rather then perfection. Improvements are easier to define and measure than an abstract concept like perfection.
Suppose that you would strive to reach old age, would you focus on immortality? You’d probably be off looking for that magic potion. If instead you aim to get older you would maybe decide to obtain a healthier lifestyle, thereby actually increasing the chance to get older.

There’s this quote from George F. Will:

“The pursuit of perfection often impedes improvement”.

By looking for that perfect solution one often finds a gaping void between it and the current situation, making it hard to figure out where to start. If instead you try to think of one thing that would improve the situation, and do this as often as possible, then you are well on your way towards excellence.

The other problem with aiming for perfection is the potential for poor return on investment that more practical minds would point to. We as programmers care a lot about the form and shape of our code, where our customers usually really only care about it’s function. Too much focus on the internal quality can thus be perceived as being wastefull. Nobody will deny you the right to improve yourself and to spend time and energy for that purpose, so overall it would make more sense to use terms like Continuous Improvement (or ‘Kaizen’ if you want to be pretentious about it) then to strive for perfection.

I try to create code that is less sucky everyday, so as to stay in what I call the Zone of Usefulness.

Let me know if you find this a usefull concept 🙂


May 5, 2010

Programming for kids

Filed under: Devnology,Learning,Programming — Freek Leemhuis @ 4:44 pm

Some time ago I was running out of time for the Devnology codefest assignment to create my own Tetris clone. At the same time I was trying to spend some more time with my daughter, who is 8 years old now. She is sometimes very bored from school, which I sympathise with – I was the same at that age I guess. So I thought this would be a good time to try and see if she would be interested in programming. After some research on visual programming languages for kids I to give Scratch a go to see if we could build something together.
It took us very little time to get going, and in no time we had some of the build-in characters moving across the screen. Visual programming makes it relatively easy to grock some of the core concepts of programming. Loops, conditions, variables – you just drag them on a pane and they snap together.

We started out by discovering animation, and this is when something amazing happened. We added some animation logic while the app was running, and it changed its behavior while it was running.
I had a flashback to Alan Kay’s demo on TED – a powerful idea about ideas. If you’ve not seen it, go ahead and watch – it will be 20 minutes well spent.

Reading up on Scratch I found it is actually build on Squeak, an implementation of the Smalltalk language and environment.
After some goofing around we set off to create a simple tetris clone. Except tetris isn’t that simple, and with no means of testing or debugging, one quickly realises this is really an educational tool but not so good in producing something more complicated.
We did get sort of half-way, but it’s fair to say that by then neither of us was enjoying the experience very much.
I’m very impressed with Scratch as a tool for education young children, and it’s a real joy to see the thoughts and discoveries of your child click into place going through some of the basics. Some advice for other fathers: take it slow, one step at a time. After an hour or so trying to explain everyting, it turned out to be a lot to ask for from Hannah. ‘Can I play with my playmobile now daddy?’ Ofcourse you can, just wait while your daddy finishes this real simple tetris game…

March 17, 2010

Adrenaline Junkies and Template Zombies

Filed under: Learning,Reading — Freek Leemhuis @ 8:34 pm

I’ve followed Tom DeMarco and Tim Lister ever since I read Peopleware, a great book about building great software teams. When a new book by these authors (and a few others) came out last year, I ordered it straight away. It’s called Adrenaline Junkies and Template Zombies, and it’s a great list of patterns of project behaviour.
It’s a fun read, although I’m sure for some of my colleagues and former colleagues some of the stories are too close for comfort.
I’ll describe why a few of the patterns really resonated with me:

At one of my previous assignment there were a lot of procedures to follow. Using project management procedures like Prince2 really revolved around having the specified documents in place at certain to pass certain milestones. Usually, the templates for these documents have little descriptions here and there where information is required.At the start of a project, one had to fill in an document listing predefined architectural concerns and design decisions for the system to be delivered. In itself not a bad practice, but ofcourse only valuable if you put the right amount of detail and consideration into it. As a test, I filled in the template with completely inane comments to see who would pick up on it. Where it asked: what are the logging and tracing requirements for this application I wrote This application has no specific needs for logging and tracing other than standard.
Under the heading: what security concerns need to be adressed for the information contained in the database I wrote : the information needs to be authorized by the guidelines specified in the technical design (note: there was at that time no technical design document – this was to be delivered only in the next project phase). You get the picture. I filed the document and it passed with flying colours: all boxes where checked. In reality, it amounted to nothing.
This kind of behaviour is what DeMarco et al refer to as Template Zombies. If procedures are more about form than content, be very careful. The Template Zombies are out to get you.
The other pattern that lends it’s name to the book is one I deal with quite a bit: Adrenaline Junkies. You will find these people in organizations where priorities are constantly shifting to the project that is particular urgent at that time. A new project was about to start, and after calculating the manpower required to finish on time we concluded that a 4man team should start right away to have any chance of actually meeting the deadline. However, after confronting the project manager with this information, he looked at us stunned, and responded: `are you kidding me? There are 10 more projects that we need to work on before we start that one!’
And so we did not start until it was too late, and ofcourse the project was late like any other project they were doing.
This is the thing when you are dealing with Adraneline Junkies: they react rather than consider, and there is no long-time planning, and generally they confuse being very busy with being very productive. There is generally a lot of burnout and turnover at companies that follow this pattern. Junkie behaviour does not scale, and companies that fail to recognize it will struggle to make a long term impact.
Mind you, the book does not really go into detail on how to handle the situations it describes. It merely gives a name to patterns that are, unfortunately, rife in our industrie. When dealing with Adraneline Junkies I have made my mind up to avoid in particular one other pattern mentioned by DeMarco: I will not be a Film Critic. Go ahead and look that one up, and many other similarly apt named patterns.

October 15, 2009

On the nature of community driven events

Filed under: Community,Devnology,Events,Learning,Speaking — Freek Leemhuis @ 5:45 pm


lowscore Last week I was involved in organizing a Scala workshop, and from the feedback we received it was notable that some of the issues that were mentioned were more to do with the expectation of participants than with the actual content.The average rating from the evaluation for this event was 7.3 (on a scale from 1 to 10), and while that might seem decent it is dramatically lower then scores for our previous events.Some of the feedback that was provided was very fair. For example, it was mentioned that the tempo could have been higher, and it could have. The typical participants of Devnology meetings have way more smarts and passion about them than any other group I have participated in, so we need to become better at tailoring our meetings accordingly.

Another point of criticism we received was that the facilitators did not seem to know all the ins and outs of the subject matter. This in my opinion is a result of the position we take in organizing these types of events: there should not be one expert explaining to the rest everything there is to know, but rather a situation where there’s enough preparation done to go through the material, and in the process learn from each other.

Under these conditions, chances are a lot bigger that it will be an interactive event, with active participation.

This way, you get to know the attendees, learn what knowledge and experience they can contribute, possibly even beyond the event itself. The meetings will become more lively and interesting, and more in line with the ideas behind the Unconference.

Having an expert capable of explaining everything on a particular subject may not improve the experience, expecially if you lose a level of interaction. We will therefore continue to encourage members of the community to take on a subject and create a learning events that is geared toward learning together.

Obviously, this will only be a success if the more knowledgeable participants are aware of this and willing to share their skills and ideas. If you are aware of points being missed or if you have information or skills that can contribute, one way to react it to sit back and be bored. It might however be better to ask yourself this question: what have I done to improve the experience of this event for some (or all) of the other participants?

Let me paraphrase what this guy said:

Ask not what your community can do for you, ask what you can do for your community!

I don’t mean to sound obnoxious here and I certainly don’t want to put people off from attending. What I hope to achieve with this post is to make our viewpoints regarding these issues clear and hopefully prevent misunderstanding in the future.



Please feel free to respond!

May 26, 2009

Speak up!

Filed under: Learning,Personal — Freek Leemhuis @ 1:46 pm

Lately I’ve been involved in a lot of workshops and meetings and one thing I noticed is that when a question is asked in a group of developers, it’s very often the younger attendants that reply first. Sometimes there’s a crop of bright young developers who really know their stuff, but other participants with years of experience just seem to be less vocal. In discussing this observation with a colleague last week it started to dawn on me: it’s not that the younger guys are brighter, they are less inhibited because they can still get away with an answering incorrectly.

If you have been a developer for 8 years or more, and someone asks an innocuous question (what is a function?), you probably know the answer. However, suppose you give the wrong answer, in front of a crowd of fellow programmers. Your reputation is on the line. Better keep quiet, and let the young guys go at it, right?

The best way to learn is to be wrong occasionally, even if it means being painfully wrong sometimes. As a programmer, there’s so many things that you ‘should know’ that it’s near impossible to have all this knowledge readily available. There’s never a better learning moment then these. Being painfully wrong means being wrong once. Being silent can mean being wrong many times. So, mainly as a reminder to myself: it’s ok to be wrong. It’s not okay to stop learning. As the lady says, sometimes you just have to feel the fear and do it anyway.

April 10, 2009

More DDD

Filed under: Community,Domain Driven Design,Learning,Speaking — Freek Leemhuis @ 4:12 pm

The second part of the DDD workshop contained a modelling session (modelling out loud!), which I think helped a lot explaining some of the concepts.


I’ve attached the slides for the second day below.

ddd-day2 slide deck

January 31, 2009


Filed under: Learning — Freek Leemhuis @ 9:06 pm

As a consultant, it’s sometimes difficult to find a new job that is a good match with your skills. We preferably want to learn on the job, but the person doing the hiring wants to find someone who already knows all the stuff that is required to do a good job.I think it was Noel Tichy who developed the model of concentric learning zones that can be used to illustrate the point.
If you want to learn, you need to get out of your comfort zone, but just enough to stay in the learning zone. If you cross over to the panic zone you’ll be thrashing rather than learning. So if I’m looking for a new assignment, I want to use skills that I do not yet fully master. Most people that are looking to hire a consultant however seem hell bent on finding someone that has demonstrated a mastery of the required skills, preferably for a number of years. They want to make sure the person they hire can do the job, and previous experience is what they perceive as the ultimate proof that the person is a good match. If the person can perform the skills required within their comfort zone, there’s no risk of them straying into the panic zone.

Requiring X number of years of experience for a language, platform of framework is not effective. Experience does not equate level of skill, and as David says, as long as applicants have 6 months to a year of experience, consider it a moot point for comparison.

There’s some strange job postings that I’ve browsed through the last month or so.

4 years of experience with c# 3.0? Who are they hoping to attract, Anders bloody Hejlsberg?

And how about this one: looking for unit testers. Wat are they? People who only write unit tests all day, and they are not allowed to actually write code?

Some of these job postings contain clues on how ignorant the company is on the matter. Someone really needs to tell them what they are looking for is a good software engineer, and rather then matching precise experience they would be better of looking at different attributes that point to good candidates. 

I like Jeff Atwood’s approach on finding the right candidate:

Have the candidate give a 20 minute presentation to your team on their area of expertise. I think this is a far better indicator of success than a traditional interview, because you’ll quickly ascertain..

  • Is this person passionate about what they are doing?
  • Can they communicate effectively to a small group?
  • Do they have a good handle on their area of expertise?
  • Would your team enjoy working with this person?

Please note that acquisition in response to this blog post might not be appreciated

Blog at