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.

Living by Rule?

From Conference 1, Chapter 5 of the Conferences of John Cassian,

As those, whose business it is to use weapons of war, whenever they want to show their skill in their art before a king of this world, try to shoot their arrows or darts into certain small targets which have the prizes painted on them; for they know that they cannot in any other way than by the line of their aim secure the end and the prize they hope for, which they will only then enjoy when they have been able to hit the mark set before them; but if it happens to be withdrawn from their sight, however much in their want of skill their aim may vainly deviate from the straight path, yet they cannot perceive that they have strayed from the direction of the intended straight line because they have no distinct mark to prove the skillfulness of their aim, or to show up its badness: and therefore while they shoot their missiles idly into space, they cannot see how they have gone wrong or how utterly at fault they are, since no mark is their accuser, showing how far they have gone astray from the right direction; nor can an unsteady look help them to correct and restore the straight line enjoined on them.

I think this fairly well summarizes the core challenge of every human endeavor, although it is a bit of a run-on sentence in modern English. In whatever we do, we have to have an ultimate goal and we have to have some idea of how to go about achieving that ultimate goal otherwise we're just boxing with shadows. In monasticism, the primary tool for living this sort of disciplined life is called a Rule, like the Rule of St. Benedict quoted last week. Actual monastic rules and the equivalents for software developers are far too detailed to cover in a single post, but hopefully you can see some connections between this and project management tools and frameworks like Scrum. However, for now let's focus on sketching out what sort of rule software developers require .

As software developers, what is our ultimate aim?

The reality is that there isn't one thing that motivates all software developers. Some of us want to be world famous, or at least "world famous" in our own part of the industry. Others are just interested in making cool things, or even cool things that make other peoples' lives easier. Some of us want to make the world a better, happier place even if we're not building the sexiest piece of technology. A great many of us are in it at least partially for the money, sometimes to become rich (often in addition to becoming famous). For most of us each of these reasons probably plays a role at different times. None of these are especially good or bad on their own, although the impulse to help others is probably one of the most noble reasons to do anything, but they also don't have much, if anything, to unify them so let's take them one at a time and look at how we might best achieve each one.

Want to be a wealthy, "World-Famous" developer like Mark Zuckerberg or at least John Sonmez?

The immediate aim in this case is actually very clear. You need to market and sell yourself constantly, tirelessly, and persistently to everyone you meet. It helps if you have something to sell, but expertise isn't actually required as long as you're clear that you're not selling a level of expertise you don't have. If you want fame as a software developer but don't know much of anything yet, you can always start out small and super focused. You could be the Android ListBox guy or the iOS TreeView lady and start getting known while you increase the depth of your knowledge. John can help you out here much more than me since he's done a really good job of marketing himself and his brand (no really, I get a remarkable amount of email from his site), while I'm far more willing live a life hidden in the heart of Jesus. Anyway, your actual rule in this case should probably focus on how often you post blogs/videos/podcasts, what your content focuses on, what you do about getting that content in front of others, and a bit about your study plans so you don't look like an idiot in front of everyone who encounters you.

Want to push back the theoretically or practically limits of what is computationally possible?

If you're more interested in the theoretical side, aim for a PhD and take as much advice as you can get from academic CS folks. If you're more interested in the practical side you probably still want at least some sort of advanced degree in CS, although you might be able to do as well by targeting a company that has the sort of hard problems you want to solve, like Netflix, Groupon, Google, or Microsoft. The odds are extremely good that you will need to both engage in extensive academic study and do a lot of networking to land where you can actually achieve your dream of doing cutting-edge work. In this case skills are of paramount importance closely followed by whatever networking you need to do to get access to the groups that are already working on whatever hard problem interests you most.

Want to do good and make the world a better place with software?

Focus! What does making the world a better place mean to you? On one end of the spectrum there are charitable organizations you could work for. Humanitarian Toolbox is the only one I know of that is specifically focused on developers using their software development skills for charity, but I expect other charitable organizations hire a few developers. On the other end of the spectrum you could make the world a better place by making an online shopping experience smoother and more enjoyable. If you work for Amazon this could even improve the lives of millions of people every year just a little bit. When you know how you want to make the world a better place you should be able to see what sort of rule will help you get there. In the meantime, practicing your skills will probably make it easier to contribute when you finally do decide on a destination.

Want to have an economically solid, reasonably happy life funded by writing software?

Congratulations, you will almost certainly find what you're looking for since software development is fairly hot at the moment with lots of opportunity, although more experienced developers frequently seem to find ways to stop being active developers. Just remember, it's better to place your sense of security in your ability to find your next job than in whoever happens to be paying you now. Businesses come and go, but there are always problems that folks need solved. With that in mind, achieving security requires maintaining adequate skills in the languages, tools, and frameworks folks want to use (ie. both old and new tech) and solid networking. Marketing is helpful, too, but as a rule of thumb even developers that don't do much professionally outside of work make a reasonably good living.

While following a Rule of Life can take you further than you could ever imagine faster than you could ever believe, the practice is quite demanding and has significant risks. Consider what the Customary of the Order for the Order of Julian of Norwich has to say about the customs that make up the lived reality of their Rule.

Customs themselves do not have to prove their value before they are practiced, nor do they presume to have a universal, binding truth for [everyone]. While the meaning of most customs can be explained through their relation to the core charism of the community, the deepest understanding can only be achieved through giving ourselves to their practice wholeheartedly. This demands trust in the community and trust of the customs themselves, and yields a great store of wisdom as we learn their value from within. Living a life together that is customary produces a stable community and builds a habit of trust. It creates an atmosphere which fosters prayer and the total conversion of self. In the discernment of a vocation, great inability to practice, or continual conflict with, the customs of the community is a likely sign that one is not called to live in this community.

In short, it is often easier to feel that one has failed the rule than see the rule as having failed, especially if one has embraced the rule as thoroughly as required to get maximum benefit. Embracing a rule wholeheartedly also means that a genuinely bad rule will hurt you very badly, very quickly. This is why it is often best to use an existing rule and make sure you take time to reflect and consult others about what they're seeing as you adopt and practice a rule.

It is critical to confirm that your disciplines are helping you come closer to hitting your mark, and to change them if they're not working after a reasonable amount of time. You can't tell if things are getting better without looking to see where your arrows are landing.

The quotation from the Conferences of John Cassian is from A Select Library of Nicene and Post-Nicene Fathers of the Christian Church from 1894, translation and notes by Edgar C.S. Gibson. Full copies of this particular work can be found at Christian Classics Ethereal Library since it is no longer covered by copyright. The quotation from the Customary of the Order of Julian of Norwich is from the edition promulgated on the Feast of St. Francis de Sales, 2011.