Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Towards mastery: Establishing craftsmanship culture in a team

Towards mastery: Establishing craftsmanship culture in a team

“We need software developers who are professionals and view their work as a craft!”

This is often heard in development teams as a reaction to fragile systems built on messy codebases. This statement also often implies a yearning for a certain type of developer… Those (lucky ones) who go home and hack until the early hours of the morning to pursue their thirst for knowledge.

In reality many developers don’t have the time to build their skills and some others see their job as something confined to 9 to 5. This is OK, but it results in teams that don’t grow which exacerbates the problem where companies rely more and more on “ninjas” and “rockstars”. This has to stop!

We need an alternative. Let’s build our people within their constraints, and let’s figure out how to do it well! This talk explores techniques that the speaker has successfully applied to help many companies and teams improve the quality and effectiveness of their engineering efforts:

• Creating a culture of learning with techniques such as code dojos, katas and other intentional learning activities.
• Helping developers learn and apply practices such as Clean Code, refactoring, TDD, Pair- and mob programming, and continuous integration.
• Overcoming common arguments against intentional learning and improvement.

Martin Cronjé

June 30, 2016
Tweet

More Decks by Martin Cronjé

Other Decks in Programming

Transcript

  1. @martincronje
    TOWARDS MASTERY

    View Slide

  2. @martincronje
    .01
    .02
    .03
    .04
    WHY THIS TALK?
    WHAT CAN WE DO ABOUT IT?
    TIPS FOR THE ROAD
    HOW DO WE MAKE IT WORK?

    View Slide

  3. @martincronje
    .01 WHY THIS TALK?

    View Slide

  4. @martincronje
    Legacy code everywhere

    View Slide

  5. @martincronje
    “Legacy code is valuable code that we are
    afraid to change”
    J.B. Rainsberger

    View Slide

  6. @martincronje
    Legacy code kills agility

    View Slide

  7. @martincronje
    How, not the Why and When

    View Slide

  8. @martincronje
    Teams struggle to avoid messy code

    View Slide

  9. @martincronje
    Why do they struggle writing simple clean code? Is it…
    • The problems can’t be fixed
    • Not the right people
    • They don’t know it is a problem
    • Not enough time on training
    • The wrong culture
    • No budget for doing a good job
    • Don’t see the value

    View Slide

  10. @martincronje
    An education problem

    View Slide

  11. @martincronje

    View Slide

  12. @martincronje
    4,031 pages!
    Very few people have read those books. Looks like the avg. attendee read two of them

    View Slide

  13. @martincronje
    Reading non-stop, how long does it take you to read a
    300 page book?
    Poll on goodreads.com (6342 responses)
    2.40%
    17.3%
    36.8%
    21.5%
    10.0%
    12.0%
    An hour or less
    1-3 hours
    3-6 hours
    6-9 hours
    9-12 hours
    More than 12 hours

    View Slide

  14. @martincronje
    Only a handful know this stuff *
    * Anecdotal evidence from colleagues with
    teams in RSA, UK, USA, and NZ
    Pool with together with others | Frustrated and having a negative impact

    View Slide

  15. @martincronje
    Most developers don’t know it…
    This is just a day job | Other responsibilities | Don’t know the importance

    View Slide

  16. @martincronje
    Most also haven’t learnt how to apply it!

    View Slide

  17. @martincronje
    What can we do about it? Can we…
    • Hire better people
    • Training and mentoring
    • Craftsmanship culture
    • Better definition of done
    • Refactoring
    • Hands-on learning

    View Slide

  18. @martincronje
    /summary WE NEED TO GROW PEOPLE

    View Slide

  19. @martincronje
    .02 WHAT CAN WE DO ABOUT IT?

    View Slide

  20. @martincronje
    “…with the rise of industrialization there are fewer and fewer
    craftsmen. One of the biggest remaining groups is computer
    programmers.”
    Paul Graham, YCombinator

    View Slide

  21. @martincronje
    Learning about learning

    View Slide

  22. @martincronje
    CODE RETREAT KATAS
    CODER DOJOS

    View Slide

  23. @martincronje
    CODERETREAT
    Day long event with 5-6 seperate 45 min sessions.
    Attempt to implement Conway’s Game of Life in
    each session.
    Do not have to complete anything. Delete code
    every sessions
    Different pairs per session with people you don’t
    normally work with.
    Get out of your comfort zone. Experiment and
    learn. Try different paradigms.
    DELIBERATE
    PRACTICE
    KATAS
    CODER DOJOS

    View Slide

  24. @martincronje
    KATAS
    CODERETREAT
    CODER DOJOS

    View Slide

  25. @martincronje
    Direct application of the principles on deliberate
    practice.
    Started as simple coding exercise focused on
    learning specific skill from TDD to Refactoring and
    Emergent Design.
    Architecture, analysis and design katas have also
    been developed.
    DELIBERATE
    PRACTICE
    KATAS CODER DOJOS
    CODERETREAT

    View Slide

  26. @martincronje
    CODER DOJOS CODE RETREAT
    KATAS

    View Slide

  27. @martincronje
    1-3 hours session with retro every 45 minutes.
    Work on any kata that the group thinks is relevant
    for them.
    Repeat katas over numerous sessions.
    Done using Mob Programming with 4-7 min turns
    at the keyboard.
    Use strong pairing technique.
    Run a retro at the end.
    DELIBERATE
    PRACTICE
    CODER DOJOS CODERETREAT
    KATAS

    View Slide

  28. @martincronje
    “…Activities designed, typically by a
    teacher, for the sole purpose of
    effectively improving specific aspects
    of an individual’s performance…”
    K. Anders Ericsson,
    Swedish psychologist
    DELIBERATE
    PRACTICE

    View Slide

  29. @martincronje
    Target specific skill
    Repeated a lot
    DELIBERATE
    PRACTICE Continuous feedback
    Must be hard

    View Slide

  30. @martincronje
    /summary PRACTICE PRACTICE PRACTICE

    View Slide

  31. @martincronje
    .03 HOW DO WE MAKE IT WORK?

    View Slide

  32. @martincronje
    Story of a group at MYOB

    View Slide

  33. @martincronje
    CLIENTS
    COLLABORATE
    SIMPLIFY
    INNOVATE
    RESULTS
    PASSION
    MYOB’S
    VALUES
    DRIVE OUR WORLD
    WE’RE BETTER TOGETHER
    MAKE IT EASIER
    FIND NEW WAYS
    ACHIEVE OUR GOALS
    LOVE YOUR WORK

    View Slide

  34. @martincronje
    CLIENTS
    SIMPLIFY
    INNOVATE
    RESULTS
    DRIVE OUR WORLD
    MAKE IT EASIER
    FIND NEW WAYS
    ACHIEVE OUR GOALS
    COLLABORATE
    PASSION
    MYOB’S
    VALUES
    WE’RE BETTER TOGETHER
    LOVE YOUR WORK

    View Slide

  35. @martincronje

    View Slide

  36. @martincronje
    • photo

    View Slide

  37. @martincronje
    Deliberate practice principles as a baseline.
    Group sessions are focused on building
    collaboration within the team.
    Sessions should be focused on areas where team
    needs grows.
    Strongest developers should be open to support
    people around them.
    MAKING
    IT WORK
    PRINCIPLES EXECUTION
    LOGISTICS

    View Slide

  38. @martincronje
    LOGISTICS
    Everyone from the team involved
    3 hours every Friday afternoon after retrospectives
    and showcases
    No work normal production work unless there is a
    production outage
    If coding session, Everyone should already have a
    working environment with test-runner in their
    desired platform
    MAKING
    IT WORK
    PRINCIPLES
    EXECUTION

    View Slide

  39. @martincronje
    Remind everyone of the principles.
    Remind team of the outcomes from the previous
    dojo and get input for current day.
    Set constraints for the day such as exercise,
    coding session length, platform, pair vs. mobs.
    Run coding sessions and end each with a quick
    retro. (30, 45 or 60 minutes)
    MAKING
    IT WORK
    EXECUTION LOGISITICS
    PRINCIPLES

    View Slide

  40. @martincronje
    Working across teams
    Knowing what I don’t know
    Trying out different techniques
    Variety is great
    Collaborating for the first time
    FEEDBACK

    View Slide

  41. @martincronje
    /summary CREATE SPACE FOR LEARNING

    View Slide

  42. @martincronje
    .04 TIPS FOR THE ROAD

    View Slide

  43. @martincronje
    GETTING BUY-IN SUSTAINABILITY
    PRODUCTION CODE
    TIPS FOR
    THE ROAD
    INVENTORY
    Growth:
    • Software will be able to do 25% of job within 10 years*
    • Number of developers are doubling every 5 years **
    Hiring:
    • Hiring developers who learn on their own time is not
    sustainable. Their personal conditions change and the
    hiring pool is limited.
    • Hiring the best developers is become an arms race of who
    has the best offices, salaries, work.
    * The Future of Employment: How Susceptible are Jobs to Computerisation
    ** StackOverflow 2015 Developer Survey
    ** http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html

    View Slide

  44. @martincronje StackOverflow 2015 Developer Survey
    26.5%
    23.2%
    32.1%
    12.4%
    5.8%
    11+ years
    6-10 years
    2- 5 years
    1 - 2 years
    Less than one year
    Years experience

    View Slide

  45. @martincronje The Future of Employment: How Susceptible are Jobs to Computerisation
    Job computerisation
    • Out of 700 jobs listed
    • 25% have 90% probability by 2023
    • 50% have 66% probability by 2023

    View Slide

  46. @martincronje
    Same place, same time every week as with
    retrospectives and stand-up.
    Teams may not see value initially, give it a month or
    two.
    One stabilised start coaching others to run the
    sessions.
    Practices the katas with a smaller group ahead of
    the time to get an idea on what they are about.
    TIPS FOR
    THE ROAD
    SUSTAINABILITY PRODUCTION CODE
    INVENTORY
    GETTING BUY-IN

    View Slide

  47. @martincronje
    TDD and emergent design:
    Create a kata out of a recent story and experiment
    on a detached branch
    Refactoring:
    Use scratch pad refactoring to experiment with
    different ideas on detached branch.
    Take the best most recent code created by the
    team and refactor it.
    Also take the oldest messiest code.
    TIPS FOR
    THE ROAD
    PRODUCTION CODE INVENTORY
    GETTING BUY-IN
    SUSTAINABILITY

    View Slide

  48. @martincronje
    Test-driven design
    • https://en.wikipedia.org/wiki/Conway's_Game_of_Life
    • http://codekata.com
    Emergent Design
    • http://codekata.com (Checkout Kata)
    Refactoring
    • https://github.com/jbrains/trivia
    • https://github.com/emilybache (Especially Gilded Rose)
    Architecture
    • https://archkatas.herokuapp.com
    Story Mapping
    • https://archkatas.herokuapp.com
    TIPS FOR
    THE ROAD
    INVENTORY
    PRODUCTION CODE
    GETTING BUY-IN
    SUSTAINABILITY

    View Slide

  49. @martincronje
    .01
    .02
    .03
    .04
    LEGACY CODE KILLS AGILITY
    PRACTICE PRACTICE PRACTICE
    MAKING IT LAST
    CREATE SPACE FOR IMPROVEMENT

    View Slide

  50. @martincronje

    View Slide