Individualism and Community?

From Chapter 1 of the Rule of St. Benedict

The third kind of monks, a detestable kind, are the Sarabaites. These, not having been tested, as gold in the furnace (Wis. 3:6), by any rule or by the lessons of experience, are as soft as lead. In their works they still keep faith with the world, so that their tonsure marks them as liars before God. They live in twos or threes, or even singly, without a shepherd, in their own sheepfolds and not in the Lord's. Their law is the desire for self-gratification: whatever enters their mind or appeals to them, that they call holy; what they dislike, they regard as unlawful.

This chapter begins by listing out four kinds of monks, Cenobites who live in monasteries under a Rule and Abbot, Hermits who trained in a monastery and are now ready for spiritual single combat, the Sarabaites described above, and the Gyrovagues who are even worse than the Sarabaites because, unlike the Sarabaites, the Gyrovagues don’t even stay in one place long enough to experience hardship.

And what sorts of people are venerated within the software development community?

Consider the depiction of Mark Zuckerberg in “The Social Network”, or the Linus Torvalds’s reputation. Consider the depiction of Alan Turing in the recent movie. Really, consider the reputation or hagiography we’ve established around all the “Greats” of our industry. In every or almost every case, we talk about them as if they stood alone, a great lone visionary who rose up from the roiling mass of lesser beings, creatures who couldn’t tell the difference between a microchip and a potato chip or think that Cobol is a misspelled color, by toiling away in isolated obscurity to bring forth some shining gem of software, which totally revolutionizes how the mass of humanity lives their lives. While I’m sure it varies from place to place, a significant portion of our community all but worships the “rock star”, “ninja”, “hacker” developer or the greybeard/neck-beard who knows the whole stack of technology being used and can trouble-shoot any problem from an obscure hardware issue, through the OS, to your application logic, and do it all in half the time it would take a regular person to debug a problem in the application logic. And those of us who have difficulty living up to the image of a successful cowboy coder or lone genius are sometimes encouraged to despair and think less of ourselves. If we’re in a good place we are also reminded that we’re more talented than we sometimes think.

What is the reality of doing great work in software?

It isn’t the cowboy coder or the lone genius. Alan Turing, as brilliant as he was, worked with plenty of smart people. So did Steve Jobs and Mark Zuckerberg, and none of their work would have amounted to a hill of beans without the time, energy, and passion of all the people involved. There is probably a benefit to having a talented, (semi-)benevolent dictator-for-life like Linus Torvalds for Linux or Steve Jobs for Apple, but there is no greatness without a strong community hidden behind the “great man” at the top. Google is perhaps the most high-profile example of this fact, being founded by two people are having a history of celebrating the work done by its many teams, although you can learn the same thing from the surprisingly low profile NASA.
This shouldn’t be surprising to us. Early Christian monasticism in Egypt was very clearly grounded in men and sometimes women going out into the desert alone to live alone as hermits, and they also found that practically everyone needs to start off in a community even though the goal for Christian monks was just a profoundly personal, not the urge to change the whole world as they knew it.

So where to from here?

It seems reasonably obvious that we software developers should be a lot more explicit about recognizing and thanking our teams for all the hard work they do. But remembering Benedict’s criticism of the Sarabaites, we also need to identify something like a Rule to follow that will help us actually build great software. We also need to have a vibrant, larger community of software developers to help us understand where our Rules don’t work and how we can change our processes and practices to better achieve our goal of creating great software. Perhaps the larger community can also help us express what it means to describe something as great software.

Those last two points are where things get sticky.

Having a Rule is a lot like having regulations on software development. Probably no one wants such regulation imposed from outside software development, and plenty of software developers would rebel at even another software developer trying to tell them how to do their job better. They’d even be a bit right to rebel if they were just being forced to adopt a methodology or set of techniques like Scrum, Scaled Agile Framework (SAFe), Kanban, Extreme Programming (XP), or Mob Programming since each requires buy-in and a certain amount of comprehension to work well.

There are user groups, meet-ups, and conferences to begin to make the software development community real, and we should definitely be visiting each type of community and talking with the folks we meet there as often as our busy schedules allow. There are also many wonderful blogs, podcasts, and vlogs out there for those looking for community online. There may even be forums that can provide a good outlet for those who want to engage the broader software developer community online. For community the stickiness comes when we start talking about how broad it needs to be and how things are going to get paid for. You may disagree with me, but I firmly believe that the embodied software development community needs to engage with “dark-matter” developers. As a whole they have a great deal of experience in and potentially knowledge about how to build software successfully. They are also the people we’re going to have to work with in many companies when we show up with a burning desire to create great software. The problem, of course, is that they don’t engage with what community already exists for software developers. Additionally, most communities of software developers are at least loosely formed around a specific set of tools or sometimes a language provided by a specific company, which naturally limits the appeal of each specific group. There are probably ways to deal with the breadth issues, but the possible solutions run us up against the second sticky point, money. Obviously software development is a business and supports a whole ecosystem of recruiters, tool makers, and certification providers around it. User groups, meet-ups, and conferences are all normally paid for at least in part by these same groups, as well as major software companies, and all of them do so with the expectation of getting something out of it of material value. All of this is fine as far as it goes, but it opens up the possibility for conflicts of interest that then have to be negotiated by sponsors, presenters, and attendees. This goes well reasonably often, especially with experienced leadership from the group and/or the biggest sponsor, but it doesn’t always. Currently those who most often reach out to help train dark-matter developers tend to be the least good about separating sales from professional development.

No, really, where to from here?

I don’t know. There are some things each of us can do to strengthen the software development community, including being familiar with practices and techniques from things like Scrum or XP and participating in local meet-ups, user groups, and conferences as we’re able, but it seems like software development is doomed to always be a very fractured community. It’s a bit sad, especially since I’d love to have something like a Bar Association or Plumbers Union for software developers, but the dream isn’t consistent with the way things work in the industry today and I have no idea how that could ever change.

The quotation from the Rule of St. Benedict is from Saint Benedict's Rule for Monasteries, translated from the Latin by Leonard J. Doyle OblSB, of Saint John's Abbey, (© Copyright 1948, 2001, by the Order of Saint Benedict, Collegeville, MN 56321). A full copy of this translation can be found at osb.org.