The other day, I witnessed a professional instructor leading a group workshop refuse to let a person observe the class without fully participating (read: paying). The workshop was focused on active student-teacher interaction, with hands-on work and individual attention being the key elements. A person quietly listening in was not getting anything remotely close to the full benefit of the class, and there was no additional burden on the teachers. There was plenty of space in the room. Yet, that instructor felt that his work was somehow compromised by someone hearing what he had to offer for free.
It used to be the norm that people would guard their respective tools of the trade from colleagues, to prevent others from “stealing” their jobs. A database specialist would smile mysteriously when asked to please use SCM for his scripts, and a sales person would take her Rolodex home every night. Coders would get upset if others wanted to review their code, or ask permission to watch over their shoulder.
It seems that a lot of people in software industry have moved on to become more open about their work. We write blogs and produce podcasts to share hard-acquired knowledge, participate in question–answer forums to help others, and deliver talks at various user groups to all who cares to listen. Code reviews, while are not exactly industry standard just yet, are widely deployed in more progressive environments and are rarely considered disrespectful in and of themselves.
The perception of what is a skill has recently shifted from what a person owns – bits of knowledge and ideas – to what a person can do with these knowledge and ideas. The skill is what enables a person to provide value, either by applying his knowledge and ideas to creating or improving a product directly, or by sharing with others.
As for the teacher who refused to let the person observe the workshop, he is well behind the times. And he lost a potential student that day.