Make it easier to do the right thing

Last year, I got a chance to work in India for 6 months. It was an awesome experience. I never had so much fun working. Something simple and thought provoking happened when I was there that I want to share.

I went to watch a movie with my friend. The theater was awesome. It was a multi-screen theater in a mall. We got our drinks and all set to watch a mindless hollywood movie. After the movie, my friend left his drink cup in his seat. I told him that it is not the right thing to do and we should not liter like that. He was like "oh don't worry about it". I carried my drink cup, I did not want to leave it in my seat. I was expecting there will be trash can outside the theater door. To my surprise, I did not find a trash can. I spend like 5 minutes looking for a trash can.

This is a very simple incident, but it teaches us an important thing. It is not that people want to do the wrong thing. They are just doing what is easy. In this incident , leaving the cup in the theater is an easier choice than spending 5 minutes looking for a trash can.

Lets take a software project. If it is very difficult to write automated tests, developers will eventually will stop writing tests. I can think of so many things like this. If it is taking a long time to run a build, developers will eventually start checking in code without running the build.

So in a software project, We should make sure that doing the right thing is easier than doing the wrong thing.

What is Rack?

Rack is a specification or a standardized way in Ruby to interact with a web server. It specifies how to accept a request from a web server and how to respond to a web server. Even though it sounds very simple, it opens up lot of options.

Check out these links for more information,

http://rack.rubyforge.org/

http://chneukirchen.org/talks/euruko-2007/chneukirchen-euruko2007-introducing-rack.pdf

http://vision-media.ca/resources/ruby/ruby-rack-middleware-tutorial

http://github.com/rack/rack-contrib/tree/master

Like movies, your presentations need Editors

Cleaning up your presentation is not that different from editing a feature film. As a director wants her films crisp and clear, you want your presentations to be crisp and clear. In movie industry, they say that director and editor roles should be done by different people. The reason is, for director when she looks at a scene she thinks the hardship that is gone in shooting that scene more than whether that scene is moving the story or not. No wonder Director's Cut is so boring. When an editor looks at the same scene she does not care how much effort has gone to shoot that scene. Editor cares only whether that scene is moving the story along or not. So next time when you are done with your presentation share it with an another person and ask her to edit it. Don't mind if she deletes a slide that took you 30 minutes to put it. Believe me your presentation will be more crisp and clear at the end.

Skills needed for a trainer to be good

There is a wrong assumption that good trainers are the ones who have expertise in the area they are training. I think having expertise in area you are training is important , but it is not the only skill that will make you a good trainer. A good trainer should also have these following skills,

- Facilitation skills :

The trainer should help learning to take place by creating a safe environment for trainees that encourages the learning process.

- Presentation skills :

The trainer should be organizing and presenting information and activities that will reinforce the learning process.

- Motivation skills:

The trainer should encourage and motivate trainees to learn and participate in training.

- Evaluation skills:

The trainer should be able to check to see if learning has taken place.

Yes expertise in area a trainer is training is important, but that will not alone will make he/she a good trainer. A trainer to be good will also need the skills I have mentioned above.

Random Thoughts about Retrospectives

• Retrospectives are there to surface problems not to analyze root cause of a problem.
• Retrospectives should end with action items.
• Each Action Item should have an Owner.