Knowledge Transfer.

[Pierre Rosado]

Replying in other topic Enrique wrote:

On Tue, Dec 29, 2009 at 9:12 AM, Enrique Comba Riepenhausen <eco...@gmail.com> wrote:

Lately (through discussions with different people and little aha moments) I realised that a lot of work has to be done in the area of knowledge transfer. I want to find out a way where I can pass on the path I walked and not just the result of my learning. How can we do this? I am still looking for the answers.

IMHO, this question sounds important for the group's common interests. Enrique, could you develop a little your ideas about the topic and the question.

Cheers,

------------------
Pierre Rosado.

[Mark Nijhof]

This is what I want to achieve with my book, a road map for young developers showing them the things I did and still do. Not by telling them the results but by pointing them into the right direction (with explanation/introduction of course) so they can learn it by them selfs.

-Mark 

Sent from my iPhone

--

You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To post to this group, send email to software_cr...@googlegroups.com.
To unsubscribe from this group, send email to software_craftsma...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.

[Dave Hoover]

Mark,

I'm interested in hearing how that differs from what was done in
Apprenticeship Patterns. Or is it similar, but with more/different
content?

Best,
--Dave

[Mark Nijhof]

Hi Dave,

Sorry for the late reply.

I have to admit but I have only skimmed your book, mostly because I
did not want to be to affected by it while putting together the bigger
picture for myself. But I will read it soon and from what I have read
so far it is a great book which I'll recommend people to read it.

About the differences: Where you are very focused on the personal side
of apprenticeship (which is great btw), I want to be more concrete (if
that is the correct word for it). I do want to focus on the different
principles, patterns and practices that are important to the software
craftsmanship. I want to provide a good introduction and explain
reasoning for using it, but then I want to point the reader to other
much better resources about the topic. I will focus primarily on the
.Net developer as this is where my main expertise lies, but I will
also touch on other solutions (Dynamic and Functional languages). I do
also touch on software craftsmanship but this is more to explain my
motivations and to explain why the reader would want to follow my
recommendations (read and learn), I for one recommend your book here
as well to learn more about what craftsmanship really means.

I truly hope that my book would be seen as being complementary instead
of overlapping to your book.

Are you coming to the UK for QCon or the Software Craftsmanship
meeting? I would love to talk to you about this and other topics.

-Mark

[Dave Hoover]

On Thu, Dec 31, 2009 at 12:18 PM, Mark Nijhof <mark....@gmail.com> wrote:
> Are you coming to the UK for QCon or the Software Craftsmanship
> meeting? I would love to talk to you about this and other topics.

I'm planning on coming to Software Craftsmanship 2010. And am eagerly
anticipating hearing what the dates are so I can book my travel. :)

[Enrique Comba Riepenhausen]

Hi Pierre,

Lately (through discussions with different people and little aha moments) I realised that a lot of work has to be done in the area of knowledge transfer. I want to find out a way where I can pass on the path I walked and not just the result of my learning. How can we do this? I am still looking for the answers.

IMHO, this question sounds important for the group's common interests. Enrique, could you develop a little your ideas about the topic and the question.

I personally think this is a very important topic to explore as well. Dave and Ade have made a tremendous work compiling patterns for apprenticing and setting you up for the long road and I think it is a brilliant work.

What I am missing is the "aha" moments when we learn something, or how to be able to transmit to, say your apprentices, why you got where you got with a given technique or way of working.

Usually we present people with things like:

"To do TDD you have to write your test code first, then you write the production code to pass the test and if it works refactor  (the test and production code)" -- This is oversimplifying, but it helps to explain. 

Now, why do we do this this way? What made me realise this to be the best way of working? What things did I read, code, explore to get there? Is there a way to pass on all those little factors that made me code the way I do today to someone else?

If we take refactoring as a sample, how many have read Opdyke's work on refactoring? What lead him to write his nearly 200 page thesis on this particular theme?

What I might be after, after all, is a way to pass on knowledge including the history that led to that knowledge.

I hope this explains a bit what I meant by this...

Enrique

P.S.: Happy New Year to all!

[Pierre Rosado]

Hi Enrique, thanks for answering.

To start a brainstorming I have the following question for every master/journeyman interested: What is your teaching methodology?

I am proudly an apprentice [ ;) ]. So, allow me to make some specualtions:

I've noticed that TDD seems to be very suitable to learn/teach programming. Each TDD iteration itself defines a kind of "meme". When the programmer finish an iteration, comment the code properly and commit to the repository, he/she is packing a lot of information in the commit object that can be used for learning purpose. So, a natural place to register information about the hows and whys of an implementation, should be the commit message.

Furthermore, if the language is dynamic, adding a history of the "experimentation" commands could be useful too. But, to be useful  commit objects and command sets have to be associated. This is not a problem if every command has associated a time-stamp.

In the other hand, if master/apprentice or peers follow a collaborative learning methodology to learn something. Despite differences in knowledge and experience, everyone involved in the process learn new things; or, in the case of masters and journeyman, from questions and answers gain insights and expand the understating about the topic.

Finally, IMHO,teaching hows and whys, in general, is not a easy task. It needs discipline and commitment.

Cheers,

--------------
Pierre

P.S.: Happy New Year to you, too! :)
 

[Mark Nijhof]

I really like Pair Programming and TDD to teach and learn. Also concrete problems to solve usually makes the process faster vs demo code because the problem domain is known and much bigger than a demo would be. So there is more information to base certain descisions on.

Re commit comments: they are valuable in a sence to rethink what you have just done, they basically make you explain your code to a third person, but after this excersize they become much less valuable in my eyes. It is much more important that your actual code communicates it's intend correctly. Grouping certain commits together by feature would be usefull as well, but personally looking at the commit comments is the last thing I do. And when I see a comment in the code I think this is something very special , something that could not be explained in the code itself. I get dissapointed quiet often on that last part ;)

I noticed that asking someone to read something or watch a video recording works very poorly unless the person is realy motivated to learn these things.

-Mark 

Sent from my iPhone

--