I know there's an old saying: "Those who can't do, teach". In my experience, this is the exact opposite of the truth. "Those who can't teach, do" - a much more accurrate representation of the real world.
My company's development department is doing a Wednesday, "BYOL" Lunch-N-Learn on a regular basis. All the developers who want to attend will bring their own lunch and we'll gather in the largest of our conference rooms so that one of the developers in the group can give a presentation on something relating to development. For the last two weeks, I have been presenting my team's TDD / DDD process to the rest of the developer group. The process of deciding what I want to discuss and then actually doing the demo / walkthrough in front of a group of my peers has really forced me to think long and hard about what I'm doing and why. Not only do I have to understand the superficial "how", but I now need to understand the "why" in a manner that goes far beyond the simple technical terms. Anyone can present a technical perspective - it's easy to find articles and how-to's. Forcing yourself to present the same information at least 2 or 3 different non-technical ways will show how much you really understand the process and really understand the "why".
I challenge anyone - make that EVERYONE - who reads this blog, to present your development process to a group of your peers (including the use of blogs, peer groups, etc). You will be amazed at how much you learn about yourself, and how much you are forced to learn about your process. For those that do not present their process on a regular basis, I can almost guarantee a learning experience that will expose some weekness in your development style and force you to re-think what you do and why. I know this holds true for myself, and I would bet that it will hold true for the majority of developers.
As an example of what I have learned from my own teaching, I found myself demonstrating some Model-View-Presenter code last week, that looked like this:
protected void Button_Click(object sender, EventArgs e)
{
_presenter.DoSomethingSpecific();
}
What's wrong with this code? Why do I consider this code to be "bad"? [ED: for all you MVC / MonoRail guys... i know i know... my view shouldn't know about the presenter... yadda yadda. I'm not at that level, yet. :) ]After all, I am distinctly separating the actual UI implementation from the presenter. The method does one thing and only one thing... it seems like good encapsulation... and all that jazz.
The answer is: Semantic Coupling. My view knows entirely too much about what the application is supposed to be doing. I should not have the view telling the presenter to do something specific. I should have the view telling the presenter what happened in the view, and allow the presenter to decide what needs to happen. A better factoring of this code, would be the following.
View:
protected void SpecificButton_Click(object sender, EventArgs e)
{
_presenter.SpecificActionRequested();
}
Presenter:
public class MyPresenter
{
public void SpecificActionRequested()
{
DoSomethingSpecific();
}
private void DoSomethingSpecific()
{
//code goes here, to do something specific.
}
}
Back to the point of this post - I honestly don't know if I would have had this realization any time soon, had I not been presenting an overview of the MVP process to my development department. This experience, specifically, leads me to believe that the old addage of "Those who can't do, teach" is entirely backwards. The reality is,
Those who can't teach, do.