Freekshow » Learning

Programming for kids

Freek Leemhuis — Wed, 05 May 2010 16:44:32 +0000

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…

Adrenaline Junkies and Template Zombies

Freek Leemhuis — Wed, 17 Mar 2010 20:34:28 +0000

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.

On the nature of community driven events

Freek Leemhuis — Thu, 15 Oct 2009 17:45:47 +0000

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!

Speak up!

Freek Leemhuis — Tue, 26 May 2009 13:46:11 +0000

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.

More DDD

Freek Leemhuis — Fri, 10 Apr 2009 16:12:58 +0000

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

Learning

Freek Leemhuis — Sat, 31 Jan 2009 21:06:03 +0000

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