I enjoyed giving a keynote speech at GOTO Berlin about "The Art of Embracing Change". The title of my talk was inspired by the subtitle of Kent Beck's "Extreme Programming Explained" and of course coaching is all about change. Keynotes are supposed to be opinionated and provide food for thought so I gave it my best shot.
At the heart of software development is an important truth "all things must change". Software is an amazing invisible material made of thought that can be changed any time - its softness is a defining characteristic. The available technology (frameworks/languages/libraries) that we can use to solve business problems evolves and business needs also change as the market evolves. Change is something a software developer is likely to grapple with throughout their career. Our instinct is to cope by fighting change, we owe it to ourselves to get better at anticipating change and handling it.
I talked about Conway's Law and how adapting code is affected by the layer of human communication around the code. I believe that part of why XP helps us to embrace change are the social practices of paired programming and collective code ownership which improve communication.
As a coach, I'm guided by a law of my own: "Code reflects the mood of the team" -- when teams enjoy their work, it has more care taken over it. After the talk Corey Haines mentioned that he has also seen this be a leading indicator with teams who measured their mood using MercuryApp.
I hope that we can clear obstacles out of the way so developers find joy in their work. One of the principles of the Manifesto for Agile Software Development is: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. In my talk I presented a hierarchy of programmer needs inspired by Maslow's - this is shown by Michele Ide-Smith in these wonderful sketchnotes.
The basic hygiene factors are a work envionment where developers can code and trust that they will use their time wisely. Team relationships help developers improve their ideas and learn from each other. Code must be valued by our organisation for us to feel it's worth investing our time in and attention to quality improves the ease with which we can work in our shared codebase. Someone commented to me after the talk that this hierarchy of needs has some parallel's with Dan Pink's Drive factors: Autonomy, Mastery, Purpose.
In a nutshell, my advice to developers who want to get better at embracing change is to become a continual learner -- seek to broaden your skills and expand your toolset for solving problems. Try letting go of being the expert and share your secrets. Change your codebase and your team mates, bring what you learned with you -- maybe you can arrange a developer exchange with another company. Seek out the state of Beginner's Mind.