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.
Coding is fun
… and so is solving problems using software.
Consolidating documentation and writing for the sake of wasting bits is utterly boring.
I have a hard time writing for an audience that I know will not take the time to understand what I write if I make it unambiguous. But most of the time they will make weird assumptions if there is a tiny hint of ambiguity.
I can totally understand that not all people grok software development, but I’ve always thought logical thinking was the killer feature of mankind. Recent encounters makes me wonder though.
This also leads to the importance of a well defined vocabulary. I waste huge amounts of commas and parentheses when writing systems related documentation because I can not allow myself to make any assumptions at all about the readers current knowledge and taste in words.
So I guess it’s my fear of ambiguity that makes my writing unreadable. At least I’m not spreading any misinformation 
…and while I’m writing about my writing: My sentences are way to long and I don’t know if it’s OK to start one with ‘But’ just to skip a comma in the previous one.
Hidden information
I made a guest appearance at an old client recently and found that they had a handful of critical errors that were there only because no one had read what I wrote a year ago.
As I wrote here:
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 misshaps that lead here. That way we can turn these vast amounts of information into knowledge that is transferable.
There is also terabytes of well written stand alone documents out there but it is to hard to find them.
Every organization needs a document repository that is easily searched. I still think a wiki is a really good thing to have but some documents work better as stand alone entities. Those documents must be easy to find. They need to be stored at a place that the organization members find natural to go to for information otherwise the time spent writing them is a total waste.
My personal aversion to writing software documentation comes from knowing that no one will ever read it. I’ve had several colleagues who have written lots of pages of junk just to intimidate any potential reader.
Since SharePoint Services is part of the OS now it is very easy to create a central place for documents.
So this is a call out to all project managers and team leaders: Please create a place where your staff can find and create living documentation. Everyone will gain from it.
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?
