I have been training at the Dojo for several weeks now. Time for feedback, commencing with why I really enjoy our Dojo sessions: because it's just like the opposite of what most of us have at work.
At work,
- Discussions are mainly about content, not form.
- As long as it just "works" everybody is OK.
- As much as possible we try to deal with issues alone.
- It's not well seen to voluntarily uncover whole zones of our own ignorance.
- Every one has a his/her very personnal idea about what's the best.
- Very few people see and are interested in the code I write.
- A lot of war stories you ear are about a code you'll never see.
- The code I write is useful, if not beautiful.
- Those who must evaluate my work don't know much about coding.
At the Dojo you can have just the contrary.
My purpose here is to try and formulate some rules or principles that seem to emerge from our activity. Or maybe it's just the way I see them, other people interested or involved in the Dojo will tell if it's the case, or just what they think of it.
The First Rule
One important rule about the Dojo is : At the Dojo one can't discuss a form without code, and one can't show code without tests. It is a design training place, where it is acknowledged that "the code is the design" and that code without tests simply doesn't exist.
Finding a Master
The master can't be a master of every forms. I feel quite at ease with recursive functions and list processing e.g. but I think I don't know how to create even a simple web app. Fortunately, while it's the first time they really deal with "tail-recursion" some practionners here have done professional web apps for years !
Come Without Your Relics
Of course, you know how to do it. You know how and why this code is better than that one. You've done it already. The point is to do it right now, explain it to us, and share what you learned.
Leaning Again
In order to learn again something, we just have to forget it. But it's not easy to forget something when you're alone. It's easier when we give our full attention to someone who just tries to learn it for the first time. We can learn from others mistakes as well as from ours if we listen carefully.
Slow Down
Learning something should force you to slow down. You can go faster because you learned some tricks, but you cannot go faster and learn at the same time. It's OK, we're not in a hurry. We could do that for years. Some of us certainly will. What kind of deadline will we miss if we spend four more weeks on this subject rather than on four different subjects ? More precisely, when we reach the next plateau, is it because we went through the previous one, or is it just because we were flying over it ?
Throwing Yourself In
At some time someone begins to master a subject and wants to approach another one. Those threatened by boredom should throw themselves first into a presentation. The goal is to get back to a good motivation level, ie. an acceptable level of difficulty.
Subjecting To A Master
If it seems difficult to you, look for other practitionners who can judge your code and could easily show something new about it to you. Ask again until the matter contains absolutely no more difficulty to you.
Mastering A Subject
If it seems easy to you, offer to explain it to other who find it difficult. Explain it again as long as they find it difficult.
This way, what seemed difficult will turn easy and vice-versa. In both cases, you'll learn.
Posted by Christophe at February 2, 2005 12:26 AM