Coaching software developers
All this talk about good software development practices -- keeping an up-to-date project/task plan, sharing test exercises with QA, interviewing developers at the end of their projects -- is all well and good, but why don't these practices naturally take hold in most software development environments? The answer is simple -- good practices take hold only with proper training and coaching.
Coaching?
Consider how athletes perform. Almost without exception, even the most naturally-talented althetes don't succeed without coaching. Coaches are necessary to observe techniques, to reinforce current skills and to teach new ones.
Software developers are mental athletes. Without training and coaching, software developers rely on raw talent, and perform nowhere near their potential. Training introduces software developers to skills and techniques beyond the amateur level. Coaching reinforces these skills and techniques, and expands them further.
What's involved in coaching software developers? For starters, training. There are a lot of proven techniques -- planning/task analysis, refactoring, pair programming, agile design, design patterns -- but software developers generally won't find out about these techniques unless they attend training courses, workshops and conferences. A convenient way to expose your software developers to training is to bring it into your company, and make courses part of the regular culture.
Training is not enough, however. It needs to be reinforced with regular coaching -- observing how software developers are putting techniques and skills into practice, reinforcing fading skills, redirecting unproductive techniques. When appropriate, coaches can introduce new skills.
Coaching software developers is a tricky business. The personalities of typical developers do not lend themselves well to having some "expert" come in to "correct" them. A successful coach needs to be welcomed by the software developers as an ally. For this reason, a coach needs to be a software developer himself -- a very good one at that -- and has to be able to build trust with software developers.
The place to start building trust is in training. First, software developers must request training, and not be required to take it. Anyone who is forced to take training will have a distrustful attitude from the start.
Next, the instructor needs to build trust so the conversation about techniques and skills can be taken successfully from the classroom to software developer's office. A technique I've used to build such trust is simply to spend some of the class time talking with software developers about the software they are writing. Developers find that I'm just like they are, that I've done the things they are doing -- we end up finding we're in sort of a fellowship.
Once the conversation has moved from the classroom to the office, it is important to keep the trust momentum going. Simply looking over what the developer is doing and assigning a grade is a sure formula for failure. An approach I find works for me is to drop by a developer's office and ask about how things are going with some skill or technique we talked about in class. This allows the developer to feel that his thoughts count, a key ingredient for maintaining and building trust. This approach, in the meantime, allows me to determine how well the developer has learned the technique and whether it is taking hold.
It is often beneficial to recognize developers who have mastered certain skills and techniques, since this motivates other developers to seek training and coaching.
Thus the key to get proven software development techniques to take hold in your development culture is to train and coach. Without coaching, chances are very good that learned skills learned will fade away, and your development staff will fall back to the amateur level. With coaching in good software development practices, your development staff has the potential to become formidable to your competition.
Coaching?
Consider how athletes perform. Almost without exception, even the most naturally-talented althetes don't succeed without coaching. Coaches are necessary to observe techniques, to reinforce current skills and to teach new ones.
Software developers are mental athletes. Without training and coaching, software developers rely on raw talent, and perform nowhere near their potential. Training introduces software developers to skills and techniques beyond the amateur level. Coaching reinforces these skills and techniques, and expands them further.
What's involved in coaching software developers? For starters, training. There are a lot of proven techniques -- planning/task analysis, refactoring, pair programming, agile design, design patterns -- but software developers generally won't find out about these techniques unless they attend training courses, workshops and conferences. A convenient way to expose your software developers to training is to bring it into your company, and make courses part of the regular culture.
Training is not enough, however. It needs to be reinforced with regular coaching -- observing how software developers are putting techniques and skills into practice, reinforcing fading skills, redirecting unproductive techniques. When appropriate, coaches can introduce new skills.
Coaching software developers is a tricky business. The personalities of typical developers do not lend themselves well to having some "expert" come in to "correct" them. A successful coach needs to be welcomed by the software developers as an ally. For this reason, a coach needs to be a software developer himself -- a very good one at that -- and has to be able to build trust with software developers.
The place to start building trust is in training. First, software developers must request training, and not be required to take it. Anyone who is forced to take training will have a distrustful attitude from the start.
Next, the instructor needs to build trust so the conversation about techniques and skills can be taken successfully from the classroom to software developer's office. A technique I've used to build such trust is simply to spend some of the class time talking with software developers about the software they are writing. Developers find that I'm just like they are, that I've done the things they are doing -- we end up finding we're in sort of a fellowship.
Once the conversation has moved from the classroom to the office, it is important to keep the trust momentum going. Simply looking over what the developer is doing and assigning a grade is a sure formula for failure. An approach I find works for me is to drop by a developer's office and ask about how things are going with some skill or technique we talked about in class. This allows the developer to feel that his thoughts count, a key ingredient for maintaining and building trust. This approach, in the meantime, allows me to determine how well the developer has learned the technique and whether it is taking hold.
It is often beneficial to recognize developers who have mastered certain skills and techniques, since this motivates other developers to seek training and coaching.
Thus the key to get proven software development techniques to take hold in your development culture is to train and coach. Without coaching, chances are very good that learned skills learned will fade away, and your development staff will fall back to the amateur level. With coaching in good software development practices, your development staff has the potential to become formidable to your competition.
posted by John Keklak at
9:09 AM
0 Comments:
Post a Comment
<< Home