Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

How I help others to level up technical practices

Technical/Engineering practices like refactoring and TDD (Test-Driven Development) have become mainstream in software development to deal with maintainability. However, these aren't commonly practised in companies. One of the reasons is the steep learning curve and requires years of experience learning from others to be competent. The other reason is most technical mentoring happens haphazardly, being ineffective or nothing. This talk is about the series of experiments to grow technical practices competency and exploring the subject of mentoring that can help to sustain the growth of technical practices in companies.

  • Sé el primero en comentar

How I help others to level up technical practices

  1. 1. How I help others to level up technical practices @stanlylau
  2. 2. Lives in Singapore Software development coach / mentor Agile Singapore 2013, 2014, 2016
  3. 3.’t-know-you-were-in
  4. 4. Early days First attempts…
  5. 5. Photo: Brown Bag sharing TDD Coding Dojo
  6. 6. How I became better Scrum Developer course
  7. 7. Experiments (informal)
  8. 8. Alright, back to topic
  9. 9. Community Coding Dojo
  10. 10. Tried • StringCalculator TDD 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
  11. 11. Community Refactoring Kata
  12. 12. Community Refactoring Kata `
  13. 13. Learned • They felt confident changing code • Inspired them to add tests at work • They added and was unmaintainable Community Refactoring Kata
  14. 14. TDD workshop followed by pairing with team members for two weeks Tried • 70% lectures, 30% exercises • Code exercises from public repositories • Pairing happens random Learned • Pairing related to code were slim • Assess the current state of automated build • Some people were defensive
  15. 15. Pairing Tried • From an hour to 10 days • 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
  16. 16. Pairing 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
  17. 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. 18. Tried • Took one week to create • More than 10 exercises • Remove code smells always • Context limited to within the method • Repetition + a little different • Respectfully intrude and challenge Refactoring Workshop #1
  19. 19. Anonymised
  20. 20. Tried • Took more than a week to create • Lesser exercises and repetition • Context includes callers and call-ees • New code smells • Characterisation tests • Simplify code using library e.g. JSONConvert • Agile modeling • Assignments as a pre-requisite Refactoring Workshop #2
  21. 21. Agile modeling
  22. 22. 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 provide feedback about their code Learned • Excellent way to find out where they are • Opportunity to hear their thoughts
  23. 23. 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.”
  24. 24. What aspects of the course were most successful in helping you to learn? “Explanation on speculative generality with diagrams” “Trying out by ourself how to identify and refactor” “Use Resharper hotkeys” “Use real production code to practise” “Approach towards a problem, especially all those shared examples are very commonly seen code smells.”
  25. 25. What improvements to the course do you suggest? “More practice examples to be more familiar in recognizing and tackle the similar code smell.” “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"
  26. 26. Supportive Environment Effective Feedback Being Competent Key factors of helping others to grow
  27. 27. One more experiment…
  28. 28. Developmental Mentoring Everyone Needs A Mentor by David Clutterbuck
  29. 29. “Mentoring is a partnership between two people built upon trust. It is a process in which the mentor offers ongoing support and development opportunities to the mentee. Addressing issues and blockages identified by the mentee, the mentor offers guidance, counselling and support in the form of pragmatic and objective assistance. Both share a common purpose of developing a strong two-way learning relationship.” - Jenny Sweeney
  30. 30. Goals not limited to… Able to apply clean code, refactoring, modeling, design principles and design patterns [1]. Able to work effectively with legacy code and automated tests. Able to come up and demonstrate with examples/exercises appropriate for mentee's level. Able to apply coaching skills of Accountability, Acknowledgment, Articulate What is Going On, Challenging, Inquiry, Metaphor, Powerful Questions, Intuition, Championing and Listening (Internal, Focused). [1]
 Design patterns: Strategy, Template method, Factory, Builder, Adapter, Command, Mediator, Null Object
 Design principles: S.O.L.I.D, Law of Demeter, Tell Don't Ask
 Refactoring: The skill of driving refactoring by code smells and design principles.
  31. 31. Thank you