Tuesday, December 13, 2016

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.

Tuesday, December 6, 2016

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.

Tuesday, November 29, 2016

Keeping Silence?

From Chapter 6 of the Rule of St. Benedict:

Let us do what the Prophet says:

"I said, 'I will guard my ways,
that I may not sin with my tongue.
I have set a guard to my mouth.'
I was mute and was humbled,
and kept silence even from good things" (Ps. 38[39]:2-3).

Here the Prophet shows that if the spirit of silence ought to lead us at times to refrain even from good speech, so much the more ought the punishment for sin make us avoid evil words.

Therefore, since the spirit of silence is so important, permission to speak should rarely be granted even to perfect disciples, even though it be for good, holy edifying conversation; for it is written,

"In much speaking you will not escape sin" (Prov. 10:19),

and in another place,

"Death and life are in the power of the tongue" (Prov. 18:21).
Given this teaching and the profound respect I have for Benedictine monasticism, from which this quote comes, why am I blogging at all? If I'm going to blog, why pick Benedictine monasticism and the work of software development, which seem to have practically nothing to do with each other? And why now?

Let me start with the easiest of those questions.

Why now?


There are a really just two reasons.

First, this will be published Tuesday in the first week of new year, and I like the symbolism of starting a new thing bright and early in a new year. No, I don't mean this will be published January 3rd, 2017. The church year begins with the first Sunday of Advent, which this year falls on November 27th, 2016. Whatever else I am, I am a very churchy software developer and little things like following the church calendar make me happy. You don't have to like it; it's just the place I'm coming from.

Second, as part of my continuing education and professional development I recently took a course from the Simple Programmer about how to use a blog to build a personal brand and keep growing professionally. If you want to try the course yourself feel free to check it out. John Sonmez, who runs Simple Programmer has a lot of good things to say, and is probably saying them from a much more straight-forward place than I will be. Neither John nor the course share any particularly secret bits of wisdom, but only because the "secrets" of how to be successful are actually widely known and widely not practiced. On the plus side for me, the course was the kick in the pants I needed to start blogging again, and it may do the same for you. Listening to John and following his advice won't make you a world-famous millionaire unless you catch an extraordinary lucky break, but it will leave you with a firm footing in the skills required to be reasonably successful in software development without having to count on such insanely good luck. Also, keep in mind that most software developers migrate out of software development over the years for a variety of reasons, and John's advice is likely to stand you in a good stead anywhere you end up going. If you're not interested in signing up for a multi-week, free (when I took it) email course on how to blog successfully as a software developer you can get a heck of a lot of what John has to say from the Simple Programmer blog or by checking out his interviews on .Net Rocks (here, here, and here). While you're there check out all the other fascinating people sharing their work with Carl and Richard.

Why this pair of topics?


Because these are perhaps the two most central facets of who I am today, and I see no reason to live a bifurcated life with the religious parts in one compartment and the software developer parts in a completely separate compartment.

For those of you who don't know, I was in residence as a monk with the Order of Julian of Norwich for two and half years, and those years were some of the happiest of my life. I am no longer with the Order because I felt called to be more engaged with the outside world than is possible for a cloistered, contemplative monk. Before that I had spent a decade or more working in the church in one capacity or another, practically all unpaid. After spending close to two years mourning my inability to get my living through church-work, I finally found my way into software development, thanks in large part to my brother, who preceded me in the profession. After doing the hard work of learning how to write software, I find I love the problem-solving and building that are so central to the what software developers do, although the good pay also helps keep me in the profession.

Besides intersecting in me, there's a lot developers can learn from a nearly 2000 year old tradition that has always been focused on how to improve oneself as much and as quickly as possible, and on how to cope with the many challenges that confront each human being in life. The same is true of Stoicism and Buddhism, but I am neither so you'll have to go elsewhere for that perspective.

Why not keep silent as the Rule seems to demand? It's not like anyone will be listening when this is first posted.


The truth is that I could keep silent. I could keep my head down and focus on doing what I'm paid to do during the work day and then come home to my loving family and just take care of family responsibilities. It could even be a vey happy life, but doing so would limit my professional options even more than being completely self-taught does. It would also prevent me from being of use to the broader developer community; something anathema to the communitarian ethos of Benedictine monasticism. I may never be a world-famous developer, or even world-famous in Poland so to speak, but I have a duty to give back to my community and it would be a pleasure if I can give back from those parts of my life that give me the deepest joy.

Because the intersection between software development and monasticism is more in the arena of life-hacks than algorithms and data structures most of what comes across this page each week will probably be of more use for those interested in ALM and Agile, but there will probably be times when the nitty-gritty of actually developing apps comes to the fore; there are certainly a few tasks peculiar to churches and religious folks that could benefit from automation. Benedictine monks are also notorious (among those who know) for their love for preserving old things, so perhaps I will even reflect a bit on what monasticism can teach about coping with legacy applications.

And if this isn't how the community needs me to give back, it will still be one more step along the broken road leading me to the places I can best be of service to my community.

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.