Passing on knowledge
This week I had the opportunity to introduce a recently employed colleague. He came out of school when there were almost no programming work available. Being a smart guy he has nurtured his programing skills while doing other things to pay the bills.
I really like spreading the little knowledge I still have. It feels like I have forgotten a lot more than I remember. This week I worked on a couple of Visual Basic 6 applications. At the beginning of the week I didn’t remember anything. I had some small fragments of ghosts of memories in the back of my head. Thanks to Google I could find a lot of information about the topics involved. Information that filtered through my remaining knowledge lead to an understanding of the problems at hand.
This got me thinking about what I should try to pass on to the new guy. Experience is not easy to teach and we are working in an industry that is still very immature. Technical details can be found withing seconds on the net so that’s unnecessary to teach. I ended up recommending him to read Code Complete, Second Edition
I really hope he enjoyed it as much as I did. It’ll take more than three days to pass on more than fifteen years of work life knowledge.
One more podcast
Today I added Rubiverse, a podcast about Ruby, to my jsiPodFetch feed list.
I’ve recently learned some Ruby and I like it a lot. I will definitively install IronRuby when it is properly released. Currently I’m using ‘real’ Ruby for my jsiPodFetch build scripts and for aggregating data from my weblogs. It feels a bit awkward to install something like Ruby just to do some scripting in Windows though, maybe I should look at Powershell instead. That is a bit more classic shell scripting. I think the things I’m using it for is more like programming. I’m not sure when something is to be called a program and when it should be called a script.
The best thing to do is probably to learn lots of languages and frameworks so that one can make educated decisions when it comes to solving new problems.
Information vs knowledge
I was at an architect event at Microsoft today called ‘The Social Life of Information’ where Beat Schwegler built the foundation for a day of Share Point demoing by talking about information vs knowledge.
The rest of the day was ok, but I got stuck thinking about knowledge.
I think that our industry would benefit a lot if we could refine (or maybe even redefine) the ways in which we transfer knowledge. If we had the tools and culture to transfer knowledge the success rate of IT projects would go through the roof.
We need to stop transfer vast amounts of non understandable information.
I think that a great tool for moving massive amounts of information into the knowledge realm is a wiki. Every development team should have access to an unrestricted wiki. If management can’t handle the thought of having it’s staff writing without moderation something is wrong in the organization. Something is also wrong in the team if the unmoderated writing turns into flame wars and bullying. It is totally ok to restrict outsiders, even deny them, but let the team be free. Every new developer should get time to be familiar with the wiki, maybe even before looking at any code.
It is not enough to use the wiki to cross reference all the information about the current state, we also need to write down the discussions and mishaps that lead here. That way we can turn these vast amounts of information into knowledge that is transferable.
I really hope that knowledge sharing gets the same status as object oriented design, unit testing and so on.
…but maybe that is what has been happening lately with the rising of architects in this industry.
It should be the role of the architect to spread knowledge inside his organization and to absorb knowledge from the community of other architects. He should also create an environment where all team members and stakeholders can share their thoughts (especially the unfinished and unpolished ones) without feeling stupid or elitistic. If we can get people to collaborate around unfinished ideas we will make wonders.
It is well known that the earlier you find a bug the less time it takes fix it.
What if we could find problem areas even before they have turned in to a concrete idea?
