Almost immediately after I stepped down from my leadership role at Mendicant University, people started to complain that the school had lost its vision. As a reaction to this sentiment, the homesteading group announced their intentions to resurrect several projects I had killed off, as a way of “returning to the roots” of the school. While this idea seemed to be well received, I doubt that executing on it will get the school even one step closer to where I wanted it to be, and that saddens me.
The good news is that now that I am free from the burdens of actually having to implement my own ambitious (and possibly crazy) ideas, I can offer up an alternative vision of the future of Mendicant University for its community to consider. These ideas are not meant to be taken as gospel, but instead are simply meant to shake things up a bit. I no longer can claim ownership of what “Mendicant University” means, but what follows is a sketch of what I currently see when I close my eyes and step into my imaginary world.
How to bring Mendicant University back to its true roots
The whole idea of Mendicant University starts and ends with purposeful programming. With that in mind, the most important question we can ask ourselves is not how we can create a better teaching experience or how we can make our activities attractive to a broader audience. Instead we should ask ourselves how we can make our efforts more meaningful.
In this sense, the Mendicant community ought to be defined as a group of people who are keenly interested in optimizing their lives so that they can make helpful contributions to the world. The abstract, disconnected nature of software development should be seen as a true enemy of the radical humanization we seek, and we should fight it by developing counterexamples that paint a few bright lines across the endless sea of grey.
To that end, our central activity should be producing useful software that solves human problems in the real world. As much as possible, we should aim for the lowest levels of Maslow’s hierarchy of needs that we can, because that is where the most visceral forms of suffering come from. Because each and every programmer lives near the top of Maslow’s pyramid rather than at the bottom, we should do our part to help others climb a bit higher.
To sustain ourselves, we cannot neglect our own needs, and in fact should do all that we can to build up a support system through the Mendicant community and through other connections in our lives to help make sure that we don’t find ourselves sliding downwards while we help lift others up. This means that practicing our vocational skills and contributing to open source projects that are development-centric are indeed meaningful, but only to the extent that they allow us (or others within our group) to pursue our more lofty goals. A careful balance needs to be established here, and I see this as the biggest challenge to Mendicant University’s long term goals.
While I could ramble on about the philosophy and motivation behind these ideas, I want to focus instead on how to put these ideas into action, as that is what is most likely to be helpful to Mendicant’s homesteaders. With that in mind, I’ve come up with the following five step plan for turning the school around.
STEP 1: Establish and curate a list of core projects.
A small list of core projects that Mendicant University is working on should be created and actively maintained. These projects would be focused on fundamental human needs rather than the needs of software developers.
At the most basic level, things like Mission of Mercy and Main Street Mission are obvious candidates, because they both address real physical suffering in the world. Projects like Swan4Kids are also worth considering, because they are targeted at basic emotional needs of children and could potentially radically change the lives of disadvantaged young people.
Projects such as rstat.us are harder to judge. To be certain, working on federated communications systems seems to be an important issue now that internet censorship and corporate control have become real rather than theoretical concerns. However, the readily available alternative means of secure and decentralized communications (such as email) make me wonder whether rstat.us is truly essential. Still, there is a lot to be said for making something a little bit better for a whole lot of people, and that is worth thinking about.
Things that DO NOT belong on this list, despite the fact that they are valuable, are things like the Ruby Documentation Project, Practicing Ruby, and pretty much anything that is specifically meant to benefit software developers. That does not mean that Mendicant University should not work on those things, only that they should not be core activities.
Once the list of core projects gets established, a great deal of effort should be taken to make it as accessible and easy to understand as possible. There should be a clear explanation of why each project has been included on the list, and it should be easy for community members to find out how to help with each of them.
STEP 2: Keep the momentum building on the core projects.
The first step to ensuring that the core projects get the attention that they deserve is to make sure that the community does not get spread too thin. Ideally speaking, no one project should dominate the work done by the community, and projects that have atrophied or fallen out of regular maintenance should be culled from the list. It is better to work on a handful of useful projects and execute extremely well than it is to try to solve all the world’s problems at once. There should be an open process for updating the list over time, one which encourages our community members to actively question whether or not our time has been well spent on each project. It is essential for this list to stay up to date and relevant, so there needs to be an individual or a group within the community who actively maintains it.
Additionally, our weekly standups on the community mailing list should be augmented to include summaries of progress on each of our core projects. Each person could mention what they did that week, or one person could summarize everyone’s contributions, but one way or the other frequent status updates need to be provided to the community. This could be as simple as saying, “nothing happened with Mission of Mercy this week, but here’s how to help”, and including a link to the relevant documentation. If doing this via the stand-ups proves to be too much of a hassle, then including this information in each Unicorn’s Horn might work instead. The important thing is the regularity of the updates, not the medium.
Most importantly, we should get in the habit of having regular days where we can get together and work on these projects. Establishing bi-monthly hack days could work for this. One possibility is to run hack days from 18:00-02:00 UTC on the 5th of every month, and from 12:00 UTC - 20:00 UTC on the 25th of every month. Specific dates and times aren’t important, but we should try to come up with a schedule that overlaps with an hour or two of time for most people in most places semi-regularly.
STEP 3: Build a support system to accelerate progress.
We can and should continue offering office hours and study sessions, and we should do what we can to promote open source software development that will help make our work on our core projects easier. However, we should evaluate these things in a more need-based fashion, keeping a clear focus on our more essential goals.
That having been said, teaching programming to all sorts of people, regardless of whether or not they are actively interested in participating in Mendicant University’s core operations can be quite useful in a number of ways. The same goes for contributing to open-source projects that aren’t on our critical path: these kinds of activities can help others to get to know about us and our mission, and also help us broaden our perspective and encourage cross-pollination of ideas within the software development ecosystem. For this reason, we should probably encourage folks to come work on whatever they’d like during our project days, even if they’re not specifically related to our core projects.
If we can find a bit of balance, both our old methods and new approaches can co-exist peacefully. I think that simply labeling activities that focus on helping other software developers as “support activities” will go a long way. This label should also be applied to any administrative work or infrastructure work we do to keep the school running, because it also needs to be done in moderation if we want to use our time wisely.
The general idea here is that we need to periodically take a rough guess at how much effort is being put into our support activities, and then try to gauge to what extent they are helping us move along our core projects. Over time, we will learn which support activities are helping us and which are wasteful, and we’ll be able to adjust accordingly.
STEP 4: Hold quarterly “Purposeful Programming” retreats.
The most common lament of Mendicant University alumni is that by eliminating our core skills course, it is harder for newcomers to get the community bonding experience that our school became known for. Many of our alumni also found that the focused feedback and deep challenges involved in the core skills course facilitated a kind of explosive growth that is hard to find elsewhere. By changing the way that Mendicant works, we have definitely lost some of those benefits.
The reason we stopped doing the core course is because we wanted to focus more on sustainable efforts and balanced living. We decided that the core course simply took too much out of everyone to justify its benefits, and decided to take things another direction. However, we didn’t quite realize just how much we lost when we gave up the core course, and so it’s not surprising that homesteaders are thinking about reviving it. I am very much against that idea, but there may be a way for us to get the best of both worlds.
If this new vision of Mendicant University was put into action, it would be possible for us to run a much deeper form of group activity on a semi-regular basis. Rather than running core courses, we could instead run quarterly retreats in which we all get together as a community to work on our core projects in a week-long focused effort.
The basic idea would work like this: retreat participants would agree to set aside a week to either clear some time off of work, or forgo their leisure activities so that they could work together on one of our core projects. During this period of time, we’d do a bunch of different activities ranging from actively hacking on important bugs and features, to writing documentation, to running sessions to help newcomers get familiar with the project. We’d try to make sure that anyone who wanted to participate in the retreat could do so, regardless of their skill levels.
We would expect all retreat participants to put in some real, focused work, even if they were beginners. If someone didn’t feel confident enough to write patches themselves, we might help them set up a local version of whatever software we were working on and ask them to help test out new changes, or we may ask them to take notes about our progress. We wouldn’t expect people to spend a full week doing nothing but participating in our retreat, but asking for an hour or two per day of work for at least 5 of the 7 days might be reasonable. This is especially true considering that we’d be working on some real, useful project, not just academic exercises.
If the Mendicant University community implemented the first three steps in this plan, I would be happy to take a leading role in coordinating and facilitating these quarterly retreats, although I would also need help from the folks who are actively maintaining whatever project we decide to focus on.
STEP 5: Establish some shared values as a community.
Right now, Mendicant University lacks some definition because it is unwilling to sketch a clear picture of what it means to be a member of its community. In the past, we had struggled to find our feet and didn’t want to be too specific about what our goals were because we wanted to avoid accidentally alienating people. However, the plan I’ve laid out here today provides a much more coherent answer to what Mendicant University is all about than anything we’ve come up with before. This could mean that a more specific definition of what it means to be a Mendicant University community member might be easier to develop under this model, and doing so might not be a bad idea.
An important thing to note is that this new vision of Mendicant University closes a few doors while opening other ones. Organizers and community members would be taking on a much more principled and almost spiritual viewpoint about their relationship to software development, and to do so effectively, the folks involved would need to really believe in these ideas. This plan is something I can get behind, but we’d need to see many others express the same feelings before we went full tilt into the wind with it.
The costs and benefits of changing the Mendicant University name to something else entirely should also be discussed. While this plan is true to what was deep in my heart when I started the school, it does represent something very specific and potentially very different than what most of our community members signed up for, and so we need to think about whether this is a pivot or a complete change in direction. This is a question I’ll leave up to the homesteaders, but it is definitely important to think about.
~~~
In the end, having a sense of vision is not about what you can see from your current vantage point. It is about creating a world in your mind that is better than this one, and then developing it brick by brick until others see it too. Whether the homesteaders pick up my ideas or press forward with their own, I hope they take that lesson to heart.
Written by Gregory Brown on 15 July 2012. If you enjoyed this essay, please share it with your friends.