Training that counts

We had today a java training with Dr. Heinz Kabutz.

There would be many thing to say about this, but let's just summarize a few.First of all, Heinz is a really, really fine person that made mediscover more about South Africa that I ever knew of. On top of that, my first impression that I was asking for one of the top javaprofessionals around the world was really confirmed.

Then the training in itself went largelly beyond my hopes:

• Heinz spotted a potential problem in our GUI code that, in fact just had been observed, and had bewildered us. We now think we now why and how thiskind of bug happens.
• I told about Heinz about how I wanted to set-up a cache for some objectsof our business model. He came, in ten minutes (all developers were totally amazed around the table!) with a really elegant and generic solution ( He would now say "general" solution, since Java5 has messed up his previous vocabulary)
• We had very nice tips and explanations about garbage collecting, exception handling, etc, etc,...
• No training is ever enough without hard work afterwards to experience it practically; however much hard work will be avoided and re-thought with this top-class training.

At last concrete objectives!

Today, I had the opportunity to do it the way I thought it should be done,...

Dealing with software is something, dealing with people creating the software is another. At our company, we set up an incentive policy aimed at motivating our troops. Thus, the classical "objectives" assigned to each one. I feel (and also read) that incentives must be used with care and that setting up motivating objectives is not an easy task.

So, regarding the individual objectives (there is also a reward program for company achievement) I took the following hypotheses:

• never set objectives that would make people compare to each other. Objectives are personal, you are only fighting against yourself to achieve your goals.
• a developer wants (needs) to improve itself
• if it is good for the developer professional practise, it will be good for the product
• the team member should select objectives that he likes
• no more than 4 to 5 objectives should be selected
• they should be concrete enough for me to make the evaluation at the end of the year
• the evaluation will always be a "give good marks to a nice face"exercise so the team members will need to show their best profile toget good marks

All in all, we had 3 individual sessions today, and the result were very interesting:

• people had the freedom to select from the 20 or so objectives that I proposed (+2 objectives that I imposed, see below)
• so I could learn more about their real interest (for instance I alwaysthought, and feared, that the main interest of one of them was network management. It is not at all!)
• the selected objectives will clearly benefit the developer
• the selected objectives will clearly benefit the product
• the 2 objectives I imposed were well accepted (better planning abilities and self-teaching through reading)
• I am confident that at the end of the year, we will be able to assess the achievement as objectively as possible
• because there are few objectives, it is possible to make huge progress in those
• my objective to give them 100% bonus because they performed ok will be achieved!

As a result, I also started creating a "good points" document where Iwill register every single achievement along the way. And I evenstarted collecting for one of them that had not been through an"objective setting" session yet.

And I feel good when I can give "good points"!