Mentoring and Giving Feedback
13 views
Skip to first unread message
Doug Bradbury
Jan 14, 2013, 10:48:35 AM1/14/13
to sc-me...@googlegroups.com
I thought I would pass along this excellent post from Mike Jansen.
Has anyone made in progress in getting your apprenticeship program up and going?
Doug
Patrick Wilson-Welsh
Jan 14, 2013, 12:11:12 PM1/14/13
to Doug Bradbury, sc-me...@googlegroups.com
Hi All:
Retrofitting an apprenticeship program to an organization as large as Cengage Learning may not be possible.
But I have, with collaborators and hard pushing, managed to get permission to allow a handful of new hires to spend up to 50% of their time learning. Meanwhile, I am spending nearly 100% of my time working on curriculum, learning goals, and an ecosystem of part-time local mentors. We have lots of passion around mentoring, teaching, and learning, and the whole thing will be messy and slow, and that's OK.
We are experimenting with about 16 learning codebases/exercises, so far all in Java. The first 8 or so are all refactoring exercises (no instruction on TDD yet) that teach only these things:
-- keep existing jUnit tests (usually very eager, coursely-grained tests) running green. These provide 100% coverage, but, again, very coursely.
-- keep modules small (including test case classes and test methods)
-- keep modules even smaller
-- use extract method and extract class, and a smidgeon of poly morphism to do this, eliminating egregious duplication opportunistically as we go
-- change variable scope to align with discovered module responsibility
-- use expressive names. Rename things at each structural-refactoring inflection-point (a class extraction, for example)
The first couple of these exercises are also available to the mentees in narrated screencast kata form. We ask them to perform the kata until rote.
Each of the codebases, being an eclipse project, is accompanied by a custom checkstyle config, for the eclipse checkstyle plugin. Mentees are required to get their code to full checkstyle compliance, where the only static analysis metrics are Npath complexity per method (no more than 3), no more than 3 parameters per method, no more than ten lines per method (including blank lines -- which we cannot apparently configure in checkstyle), and no more than 6 methods per class. The first few exercises thrive with these specific constraints. Other exercises might require selective loosening or tightening of some of them.
There is a "whack-a-mole" feel to this learning: as mentees extract more and smaller methods, getting a feel for true SRP-compliance as they go, they discover that their class contains "too many" methods (and certainly too much state), and they are asked to identify potential class responsibility seams for class extraction.
These are, of course, very artificial-seeming constraints to mentees. But they have so far succeeded in forcing them into awesome conversations with us about SRP, complexity, extraction, promotion, demotion, dead code, inexpressive tests, test granularity, etc. Awesome sauce.
Only AFTER mentees have made their way through all of the refactoring and lightweight-legacy-rescue exercises are they ALLOWED to take their first few TDD steps, in an entirely different set of exercises.
We are meanwhile cranking up new exercise versions in Javascript/Coffeescript/Jasmine. We want mentees to be polyglot pretty much off the bat.
Feedback welcome. More details later.
Cheers,
--Patrick
Retrofitting an apprenticeship program to an organization as large as Cengage Learning may not be possible.
But I have, with collaborators and hard pushing, managed to get permission to allow a handful of new hires to spend up to 50% of their time learning. Meanwhile, I am spending nearly 100% of my time working on curriculum, learning goals, and an ecosystem of part-time local mentors. We have lots of passion around mentoring, teaching, and learning, and the whole thing will be messy and slow, and that's OK.
We are experimenting with about 16 learning codebases/exercises, so far all in Java. The first 8 or so are all refactoring exercises (no instruction on TDD yet) that teach only these things:
-- keep existing jUnit tests (usually very eager, coursely-grained tests) running green. These provide 100% coverage, but, again, very coursely.
-- keep modules small (including test case classes and test methods)
-- keep modules even smaller
-- use extract method and extract class, and a smidgeon of poly morphism to do this, eliminating egregious duplication opportunistically as we go
-- change variable scope to align with discovered module responsibility
-- use expressive names. Rename things at each structural-refactoring inflection-point (a class extraction, for example)
The first couple of these exercises are also available to the mentees in narrated screencast kata form. We ask them to perform the kata until rote.
Each of the codebases, being an eclipse project, is accompanied by a custom checkstyle config, for the eclipse checkstyle plugin. Mentees are required to get their code to full checkstyle compliance, where the only static analysis metrics are Npath complexity per method (no more than 3), no more than 3 parameters per method, no more than ten lines per method (including blank lines -- which we cannot apparently configure in checkstyle), and no more than 6 methods per class. The first few exercises thrive with these specific constraints. Other exercises might require selective loosening or tightening of some of them.
There is a "whack-a-mole" feel to this learning: as mentees extract more and smaller methods, getting a feel for true SRP-compliance as they go, they discover that their class contains "too many" methods (and certainly too much state), and they are asked to identify potential class responsibility seams for class extraction.
These are, of course, very artificial-seeming constraints to mentees. But they have so far succeeded in forcing them into awesome conversations with us about SRP, complexity, extraction, promotion, demotion, dead code, inexpressive tests, test granularity, etc. Awesome sauce.
Only AFTER mentees have made their way through all of the refactoring and lightweight-legacy-rescue exercises are they ALLOWED to take their first few TDD steps, in an entirely different set of exercises.
We are meanwhile cranking up new exercise versions in Javascript/Coffeescript/Jasmine. We want mentees to be polyglot pretty much off the bat.
Feedback welcome. More details later.
Cheers,
--Patrick
--
Reply all
Reply to author
Forward
0 new messages