If the “method” label is to be attached to XP/agile, it should be in terms of a method for producing better developers rather than a method for producing better software. Better software comes from, and only from, *better people.”
David West wrote the above in Object Thinking (emphasis mine). From the context, it seems that when he uses the phrase “better people” he means it simply as a synonym for “better developers.” But it seems like it would also be a great phrase to capture something Kent Beck emphasized in Extreme Programming Explained:
XP is my attempt to reconcile humanity and productivity in my own practice of software development and to share that reconciliation. I had begun to notice that the more humanely I treated myself and others, the more productive we all became.
When I think about people who treat themselves and others more humanely, “better people” sums it up nicely.
When I was first getting into Extreme Programming (XP), the question of whether I was treating others humanely wasn’t on my radar screen. I was focused on the technical practices: I want to know how to test! How to write small stories! “Treating others humanely” didn’t seem to address any of my felt needs, so I didn’t pay the idea much attention.
But something happened during my time in XP circles. I started to absorb the values of the community, as I saw how they both flowed from and undergirded the practices. (David West refers to this absorbtion as “enculturation.”) Specifically, I started treating others more humanely, just as Beck has said!
This was even more surprising because I had tried to learn to treat people better in the past, but I had never been able to make much permanent progress. I even had to leave my previous job because of an anger issue I couldn’t keep under control, no matter how hard I tried. Yet this time I had begun to change without any conscious effort.
I’ve been trying to puzzle out how I was able to become a “better person” this time. Not as a repeatable set of steps that others can apply—everyone’s path to growth is different. But so I can be appropriately grateful for the factors that played a part. And in case any of these are helpful for others on their journey.
Each step I went through can be summarized by a core belief. The beliefs start at self-reliance and an implicit judgment of others, and they gradually progress toward a need for others and a real respect for their differences and worth.
My starting point was believing:
1. “I have it all together.”
For most of my career, I was able to figure out what I needed to succeed and advance in my career. I was able to pick up new frameworks and languages as I needed to. I was able to communicate with non-technical people. I was able to deliver good software in a reasonable timeframe. If things weren’t going well, all I needed to do was try harder, and I was able to get over the obstacles.
This eventually fell apart, though. As the software you’re working on gets more complex, it goes beyond the point where you can keep it all in your head. That’s when more bugs start to creep in, releases get late, and hours get long. When that happened, I realized I didn’t have it all together. I had a real sense of my own need to learn from others’ ideas. At this point, my core belief changed to:
2. “I need to do better.”
This is when I started reading. I read blog posts, listened to conference talks, and attended meetups. Anything that offered help, I was interested in. These formats were all helpful, but eventually they all pointed me back to books for some deeper learning.
As I read The Pragmatic Programmer, Practices of an Agile Developer, and Extreme Programming Explained, it seemed that agile practices offered the help I needed. So I tried to start following them. But I couldn’t figure out how to do testing effectively in the apps I was working on. And I certainly couldn’t convince my team to do testing as well.
Others were applying agile practices and seeing the benefits from them, but I wasn’t able to. I realized that books weren’t enough for me to learn these practices. Not only did I need new ideas from other people, I also needed help from other people putting those ideas into practice.
So at this point my core belief changed to:
3. “I need help doing better.”
As it turns out, some life circumstances gave me an opportunity to find help. As I mentioned, I had to leave my previous employer because of anger issues. As I was job searching, I decided to look for a team that was succeeding at agile practices, so I could learn from them. And I couldn’t have found a better place than Big Nerd Ranch. My team has helped me learn how to develop a testing strategy for an app and how to think through the design of code in an evolutionary way. They’ve helped me to learn the importance of code review for knowledge sharing and catching bugs.
But the way I learned these things wasn’t how I expected. I didn’t mainly learn them by observing my team and doing what they did; they actively taught me. People took the time in code reviews to explain the principles behind their feedback, and to offer suggestions. People on other projects were willing to pair with me to work through a problem together. They were available on Slack for any questions. They were patient with me when I acted frustrated with them, although I was really frustrated at myself.
Through this I realized that it’s not enough to be around people who know good practices: they need to care about me enough to teach me. I need the involvement of others. And recognizing this helps me to treat them better. Early on at times I treated them better out of a fear of losing these relationships or even a job. But as time progressed, I gained a deep respect for the expertise of my team, such that I wanted to treat them well.
Up until this point the pattern had been that my core belief had changed and then my circumstances changed in response. This next change is different, though. I went through some experiences, and those experiences only gradually changed my belief. This change was toward the belief that:
4. “Anyone can teach me something.”
When you’ve started to learn something, the best way to solidify it is to teach others, and I got some opportunities to do that. I started a meetup on software crafting to dig into testing and OO design together with others, and as part of it the attenders pair program together on TDD coding exercises.
Also, I attended an OO design training workshop with Sandi Metz. The contents of the training were the basis of her book with Katrina Owen, 99 Bottles of OOP. I had already read through the book, so although I hadn’t done the exercises I was more familiar with its ideas than other attenders, who hadn’t read the book. Much of this workshop was pair programming as well.
As I pair programmed in these environments, I realized that whenever I pair with someone less experienced than me, I learn. It’s not just that I learn by figuring out how best to explain what I know; it’s also that the questions my pairs ask and the insights they share help me to understand better, and to better learn how to explain to others.
This was another major mental shift for me. Anyone can help me learn! Knowledge and help doesn’t flow unidirectionally from the more experienced to the less.
Note, though, that this understanding still implicitly puts people on a linear progression of experience. It would take another experience to help me to learn that:
5. “Different people and situations have different needs.”
At the start of 2017 I spent six months on Big Nerd Ranch’s iOS team. I knew the iOS team didn’t have quite the same level of automated testing as the web team, and I was curious why. I resisted the temptation to think that I would be the hero who would help them step up their testing, because I quickly realized what a ridiculously arrogant idea that would be. Big Nerd Ranch is one of the most well-respected iOS consultancies I know, so it would be foolish for me to assume I would show up and save the day.
I asked quite a few members of the iOS team why there wasn’t as much testing in iOS as on the web. They had a lot of helpful observations, so I wanted to put them to the test to see if I would be convinced. Sure enough, after two projects and several attempts on my part, I became convinced that in the context of the iOS apps BNR builds, the cost/benefit ratio of testing is much more costly than on the web. (I’ll write more about why this is in a future post.)
From my experience on the iOS team, I learned to be more context-sensitive. Different technologies have different strengths and weaknesses. Different types of application have different constraints. And different people are ready to learn different things.
So it’s not a matter of everyone being at different points on the same path. We are working in different contexts, and we learn and work in different ways. I can’t say for sure that, for example, an iOS developer needs to first do more testing and then all their problems will be solved. The other person always has far more information than I do about themselves and their context. They have to figure out their answers for themselves. My role is to get to know them, do my best to understand them and their context, share my own experiences, and let them decide if something seems worth trying.
In this post I’ve been summarizing what I’ve learned as “kindness,” but I think a more precise word would be “respect.” At the start of my journey, my self-sufficient view carried an implicit judgment of anyone who had not been able to pull themselves up by their own bootstraps. But each time my core belief changed I gained more respect for people: that they may have expertise, beginner insights, or even a different perspective. I moved from judging them to giving them the freedom to figure things out for themselves, and I learned how to engage with them in a way that encouraged that freedom.
Where I Go From Here
I was hesitant to title this blog post “How XP Made Me a Better Person” because it might sound like I think I’m a better person than others. To the contrary, I have personality-test evidence that I’m far at the extreme of low compassion— statistically, most of you are better at all of this than me! All I’m saying is that I’m a better person than I used to be. I want to celebrate that, but I also recognize that I have a long way to go.
One of my biggest long-term goals for my treatment of others is to become more selfless. Despite everything I learned above, notice I’m still talking in terms of what others are teaching me. What if someone has no interest in helping me? What if they’re actively undermining me? I want to be able to treat people like that with kindness no matter how they’ve treated me. That’s what makes a hero. Ghandi. Martin Luther King Junior. Corrie ten Boom. At least in some small way, I want to be able to follow their example. I want to do what Jesus said: “love your enemies and pray for those who persecute you.”
I have a long way to go to get to that point. But at 35 years old I feel like I’m finally making progress. I finally want to treat people with kindness. “Becoming a better person” is a lofty concept, so it’s surprising that a crucial step on the path for me has been something as mundane as a programming methodology, Extreme Programming. And the creators of XP were content to keep it focused on programming; they didn’t even want to expand it to business management. But it’s not suprising that taking a basic human value seriously would lead to improvements in software development. Despite how we programmers tend to forget it, or try to, we are humans, after all.