Re: code-sharing at work.

[martinvi]

We are "in the middle" of that process.

I wont go into details, since they are a matter of your team / workgroup / bunch of people and the environment, they work. So said: the details might change a lot, and what does fine for me and my co-workers, could utterly fail for you. The bright side of this: You and your co-workers have a lot of freedom to choose the details.

I'll limit my rant to two important things, we had have / have / will have to learn:

1. the process is a process.

You start it, and it'll never terminate (or you've failed). There is no end, but after reaching a certain, defined goal ("We have a meeting each morning at 09:30, which will last 15 minutes."), the process will start over on the next iteration.
Think about a loop, where you'll change a little $Something at each step.

Be prepared for a really long-ranging engagement. Be carefull -- don't throw your heart in it! You can get badly hurt. You and your brethren need to be involved in a more than one manner, even an emotional one. But think of having a emergency cutout. (1)

2. Sharing code is as much about code as computer are about telescops (2)

Clarify the expectation what to share. We are dedicated to share knowledge in a 3-fold manner: practical, theoretical and ... well, let's say: phisolophical knowledge.

The first is obvious: "use strict;", "When getting error A, turn wheel, drop switch and head at north", "Sacrify a virgin over the router" ... that kind of advice. There is one person in charge of collecting, classifing, evaluating, augmenting, publishing etc. said information. Obviously, that person has a need for some appropriate tools.

The second layer of sharing are "brown bag lessons", i.e. we got some company time and time of ourself (that ranges from 1 hour company time for 1 hour personal time to none company time at all, depending on the topic) and some company ressources (computer, rooms, light, coffee ...) for teaching and taking lessons. I "teach" -- I prefer the word "tutor" -- perl at a very low level at 3 co-workers and take a lesson in some Windows topics. A SQL-workshop is planned, but not yet scheduled.

The third layer of sharing is somewhat strange. Every now and then, during a coffee break, a smoke or whatever time is applicable, you talk with some co-worker about the meaning of things. What's the benefit of object orientation? Why should one learn yet another language? How looks a Unix / Windows / whatever system from the viewpoint of an administrator? Those talks are helpfull in learning the ways the other one (and oneself) tends to think.

Enough! I hope, there one pinch of grain in this abundance of sugar.

---

(1) I was there and I've got that t-shirt. So, I'm just whininge about my own shortcomings.

(2) "Computer science is as much about computers as astronomy is about telescopes." -- Edsger Dijkstra, 1930-2002