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.

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.
–
TimMar 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.
–
CyclopsOct 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.
–
WikisOct 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.
–
CyclopsOct 18 '11 at 17:56

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!
–
WikisMar 8 '11 at 11:45

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.

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.
–
WikisMar 8 '11 at 10:50

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.

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.

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.

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.

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).

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?
–
WikisMar 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.
–
NeilMar 8 '11 at 15:43

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.

I've heard mixed experiences about using technical writers. Do you have any tips to make it work well?
–
WikisMar 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.
–
LWoodyiiiMar 9 '11 at 21:43

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...