Technical Mentoring, What works and not
4 likes300 views
The document discusses effective technical mentoring in software development, emphasizing a structured approach that allows mentees to manage their own learning. It details experiences from various mentoring sessions, workshops, and exercises aimed at improving code refactoring skills while highlighting successful outcomes and areas for improvement. Key takeaways include the importance of personalized guidance, practical exercises, and the engagement of internal mentors for sustainable learning.
Technical Mentoring, What works and not
- 1. Technical Mentoring What works and not stanly@odd-e.com @stanlylau
- 2. Lives in Singapore Software development coach / mentor Agile Singapore 2013, 2014, 2016
- 5. Original program: Making changes: More changes: Without refactoring With refactoring Small change Refactor Etc
- 6. Mentoring “A structured self-development method that provides support to help individuals manage their own learning and realize their full potential. It is out of the reporting line, where the experience gap (not the status gap) and the mentee drive the relationship.” Parsloe, 2000; Clutterbuck, 2004
- 8. TDD workshop followed by pairing with team members for two weeks Tried • 70% lectures, 30% exercises • Code exercises from public • Pairing happens random Learned • Pairing related to code were slim • Assess the current state of automated build • Some people were defensive
- 9. Tried • StringCalculator exercise • 20 people, most are new to TDD Learned • Most have trouble writing test first • Questions of applying on their existing systems • What if we focus only on refactoring first? Community Mini-Coderetreat
- 10. Refactoring Kata
- 12. Refactoring Kata Outcome • They felt confident changing code • Inspired them to add tests at work • They added and was unmaintainable
- 13. One-on-one Mentoring Tried • Prepare a few topics • Share with me their reflection/learnings Learned • Don’t know where to start in long method • Draw/Model the classes • Skills often mentioned
- 14. One-on-one Mentoring Common mentioned skills • Hotkeys • Understanding Single Responsibility Principle • Return null vs empty list • Refactor multiple returns to single return • Distance of behavior and data (domain object) • Working with 3rd party webservice API • Name closer to the business language
- 15. Tried • Remove mines on larger minefield • More guidance at the beginning & more questions later on • Ruby on Rails + Travis CI + Heroku + Github • Topics widen to continuous delivery Learned / Outcome • More than half picked up fast • A few were inspired by the special project • Prod. release takes < 30 minutes instead of a day 2-week Mentoring with Senior Developers
- 16. Four Stages of Competence https://en.m.wikipedia.org/wiki/Four_stages_of_competence
- 17. • Start with Code Smells & Refactoring Workshop • Code exercises from product’s codebase • Series of progressive one-day workshops • One-on-one sessions between workshops • Hands-on exercises then debrief • Maximum of 8 participants • Two co-leaders, me & another from the company • Platform for growing mentors Technical Training Program
- 18. Anonymised
- 19. • One week of preparation • More than 10 exercises • Remove code smells always • Context limited to within the method • Repetition + little different • Respectfully intrude and challenge Refactoring Workshop #1
- 22. What aspects of the course were most successful in helping you to learn? “Use Resharper hotkeys” “Use real production code to practise” “Approach towards a problem, especially all those shared examples are very commonly seen code smells.”
- 23. What improvements to the course do you suggest? “More examples on how to identify code smells such as primitive obsession” “Sometimes I am lost after the trainer expect me to do the refactoring on the code” “More sessions"
- 24. • More than one week of preparation • 7 exercises • Context includes callers and call-ees • Lesser repetition • New code smells • Characterisation tests • Simplify code using library e.g. JSONConvert • Model/Draw the classes and interactions Refactoring Workshop #2
- 26. What aspects of the course were most successful in helping you to learn? “Hands on, new library feature introduction” “Explanation on speculative generality with diagrams” “Trying out by ourself how to identify and refactor”
- 27. What improvements to the course do you suggest? “No comment. But look forward for more workshops like this in future.” “More practice examples to be more familiar in recognizing and tackle the similar code smell.” “Give some starters before getting our hands dirty. Some of us might not be that creative and might not be able to make full use of the allotted time.”
- 28. Assignments as a Pre-requisite Tried • Part 1: Review a recent code that was refactored • Part 2: Remove the smells in a refactoring kata • I’ll respond with my thoughts about their code Learned / Outcome • Excellent way to find out where they are • Opportunity to hear their thoughts
- 29. Assignments as a Pre-requisite “Actually I knew this code smell in my code but I don’t know any good way to remove this smell, so I hope I can attend workshop #2 to learn more about refactoring.”
- 30. How many workshops does it take to reduce the smells in commits? ?
- 31. Summary
- 32. What works • Facilitative mentoring for effective learning • Skill to assess where individuals are • Appropriate challenge for progressive learning • A structure to facilitate follow up • Derive exercises from existing codebases • Engage and grow internal mentors What’s not • Workshop/Training alone is insufficient • Weak self-awareness of communication style