Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We have recently polled our company wide wiki users and found out that there are two large groups of users:

  • people with lots of knowledge but (who claim they have) no time to document
  • people with time but (who claim they have) not enough knowledge worth documenting

Each group covered almost 50% of the users!

How do your companies handle this? That is, how do you encourage your busiest / most knowledgeable people to share their knowledge?

share|improve this question
    
Its a neat concept to think that those that don't have time to inform others of their knowledge are likely spending that time gaining the knowledge that others would like them to distribute. On the flip side those who have all this free time to distribute their knowledge have little to give, likely to not spending as much time learning. This whole concept is likely very false, but just an interesting thought. –  Tim Mar 8 '11 at 12:57
1  
Is this really specific to software development? Seems like it would be general to all knowledge-based fields (doctors, engineers, etc) - and might be better on the Productivity site. –  Cyclops Oct 18 '11 at 15:13
    
@Cyclops: thanks for the great idea, I have posted the question on the productivity site. You are right, though I had my developer community in mind when I posted the question, it is not developer specific. However, I don't think the Productivity site was available when I first posted this question. –  Wikis Oct 18 '11 at 17:46
1  
Ah, you're right, Wikis, I didn't realize it's an older question, which apparently someone edited and it came up on the front page. –  Cyclops Oct 18 '11 at 17:56
add comment

closed as off topic by Mark Trapp Oct 18 '11 at 17:55

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

11 Answers

up vote 11 down vote accepted

One thing I'd try would be to try this:

  1. Pair up people in the first group with people in the second,
  2. Information is exchanged within the pairs from the first group people to the second group people.
  3. The people in the second group document their new found knowledge,
  4. The documents are then verified by the people in the first group.
  5. If there are errors, then go back to step 2.
share|improve this answer
    
I really like the pairing up idea. That will help the busy people to share the load and increase the speed of learning. BTW there is a typo on line 3 (there -> their) which I can't change because it is not a big enough edit! –  Wikis Mar 8 '11 at 11:45
    
@Wikis, Thanks, fixed. –  dan_waterworth Mar 8 '11 at 11:56
1  
This sounds pretty close to an apprenticeship model, which might make a lot of sense for some software shops to create. –  joshin4colours Oct 18 '11 at 14:30
add comment

How do you know the "people with lots of knowledge" have any knowledge at all, if they haven't demonstrated the knowledge by recording or presenting it? Get them to 'walk the walk' by showing that they know what they're talking about. This could be in the form of a presentation to the group, attended (and documented) by the people who claim to have the time to do so but not the knowledge.

Results:

  • The people who say they know stuff can show off how much they know stuff.
  • The people who say they have time to document things have something to document.
  • The knowledge retained by the 'knowers' has been recorded.
  • The people who didn't know enough now know something more.
share|improve this answer
    
certainly your idea to get them to present is good because people often seem to have the time to present info! Everyone seems to know PowerPoint. To answer your question, I think they have knowledge because they are the ones called upon to solve problems and they are often doing just that. –  Wikis Mar 8 '11 at 10:50
add comment

For those without time, make the people responsible for their time allocate them time to document.

For those with time, just interview them repeatedly until you are certain 1) you have all they know or 2) they really didn't know anything. In the latter case, it might be time for management to consider what they are doing on the team.

share|improve this answer
1  
ørn - the common thread in your answer is management. Maybe management need to decide what they really think is important. –  Wikis Mar 8 '11 at 11:43
    
@Wikis, well, somebody needs to change these peoples mind. This normally involves their boss if they don't want to on their own. –  user1249 Mar 8 '11 at 19:18
add comment

In the small group I work with we have started to keep a local wiki (using tiddly wiki) to store all of our learning's from our R&D into an area of a project.

So far this has proven to be a good way to disseminate knowledge.

share|improve this answer
    
yes, we are using a wiki as well. But how do you get people to contribute to the wiki? Maybe it works for you because with a small group the peer pressure is higher? –  Wikis Mar 8 '11 at 13:29
    
We actually use a wiki as well. All you have to do is tell them that anything asked that's written in the wiki can be used as an excuse not to explain something to someone. People like that because it means they don't have to busy themselves with being the guru all the time. –  Neil Mar 8 '11 at 15:43
add comment

A good technical writer on your team can be real boost for these types of things. I've had one before on a team and he was very valuable. I think he made maintenance of our project for teams afterward much easier with all the documentation he wrote. He wasn't a programmer, but he knew enough technically to put our ideas, architecture, etc. to paper.

share|improve this answer
    
I've heard mixed experiences about using technical writers. Do you have any tips to make it work well? –  Wikis Mar 8 '11 at 15:43
1  
First, the technical writer needs to be somewhat technical. Understands your domain somewhat (.Net, Java, etc.) so you're not continually re-explaining fundamental concepts. Second, almost as important, make sure they WANT and ENJOY writing; ie they aren't trying to weasel into a developer job. Ask to see some previous writing pieces when hiring one also. –  LWoodyiii Mar 9 '11 at 21:43
add comment

The people from first group have two important things: knowledge and expertise. These should not be confused.

It is possible to transfer knowledge through wikis, specifications, source code comments etc.

It is not possible however, to transfer expertise that easily. That comes with hands-on experience. Of course that can be greatly improved by nominating people from first group as mentors for newbies (and oblige them to reserve time for that). Also you can have mixed pairs or mixed agile teams working closely together.

share|improve this answer
add comment

It's both a technical / psychological subject.

Many developers aren't use it to do any documentation, and sometimes doesn't know the apps. or techniques (U.M.L.), and some people are just introvert or non-social.

Note: It doesn't apply just to "geeks", I have met a lot of administrative people who has the "You should not be taught, You have to learn it for yourself, attitude".

Not enough time ? Make the time. Either left one or two hours in the morning for doing technical for those who know. Have schedule to organize time, and leave some free time.

Remember technical people, that teaching / sharing information with "junior" / new employees IS NOT WASTING TIME. It's investing, and eventually, those students will remove job from those who know.

share|improve this answer
add comment

But I thought in this age of Agile that there was no need to document. Isn't the source code self documenting enough that everyone can master the application by glancing through a few source code files?

Seriously, you have what we call kingdom builders in your group. If they claim to not have time to document it's because they are protecting their turf. Plain and simple. The problem with documenting, in the eyes of kingdom builders, is that it makes them expendable. That is their fear, that's why they refuse to document. If they were truly your best and brightest then they would be relishing the opportunity to pass off the maintenance grunt work so they can work on bigger and brighter things.

Anyways, documenting your work is an expected part of any developers job and if they claim they don't have time then they aren't doing their job.

Also, if other developers can't figure out what your smart developers have done, then I would really question the quality of the work that your smart developers are doing.

share|improve this answer
add comment

If you are simply looking to transfer knowledge about coding techniques and best practices, one solution is code reviews. Have your ace problem solvers and anyone directly involved in a certain area of code review changes in chunks, making sure to give feedback to the author of the change. You'll find that your best people will give away a lot of their secrets trying to improve code they might be stuck maintaining or fixing a bug in some day. If you build code reviews into your schedule then everyone will have time for them.

It is also beneficial to have the guys who don't know code so well review the experts' code. Sure they won't provide feedback that is as valuable, but they will learn by reading.

Test code should be reviewed during the code review as well.

If you are looking to transfer domain knowledge about the use of the software you are writing, you may want to implement a design review. Somehow make sure some of your good people who know the domain are around to hear what your other programmers are doing. However you want to do that is up to you, and it can be done in short sessions for short iterations if you like. It will help catch misunderstandings, potentially.

share|improve this answer
add comment

It's certainly possible that the problem is that the people that declare themselves "too busy" are just interested in protecting their turf. But it is also be possible that these folks are under pressure to deliver code and that management hasn't prioritized the effort that it would take to put together documentation. If the sorts of things that you're hoping for people to document are going to take days of effort to pull together a document that describes a complex workflow both from a business standpoint down through the technical architecture, that's something that management is going to have to prioritize as a task for the developers (and accept that writing up documentation is going to delay other development tasks).

share|improve this answer
add comment

This is my approach:

  • you assign the task of documenting to a fresh developer,
  • he tries to figure all the stuff out on his own,
  • he asks knowledgeable people questions about the system,
  • he writes documentation as he learns.

It has three important advantages:

  • Knowledgeable people save time, as it consumes waaaay less time to explain something to another developer than to write it down in detail.
  • Fresh developer has no assumptions about the system and he is more likely do describe every aspect of the system he discovers. Knowledgeable people tend to skip minor details, because they are so obvious...
  • At the end you have one more knowledgeable person around.

And just one, but quite significant problem:

  • Documenting systems that way takes more time than usual.
share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.