People are very interested in Mendicant University, but there is very limited public information out there about it, even now that we've been working on the experiment for nine months aleady. From March 26th to April 8th, I'll be posting short stories daily that might give a better picture of what's inside my head, as well as what's going in the ivory tower that is our Ruby Progamming school.

As I mentioned in the previous post, my roughly three years of on-again, off-again college attendance was a mixed experience. There were certainly plenty of courses and professors who following the 'my purpose is to generate grades for transcripts' formula, but the percentage of instructors who actually gave a damn was much higher than what I found in primary school. One professor in particular exposed me to a style of teaching that has altered the way that I think about Life, the Universe, and Everything.

Leaving school for a while and then coming back, I found myself overqualified for introductory math courses, but with not enough options for advanced courses due to a lack of available open courses. Fortunately, through a stroke of luck one other student (John) was in a similar situation and our professor Dr. Uebelacker offered us an interesting alternative: An independent study in Topology (not to be confused with Topography). The course material itself sounded interesting to me and was enough to win me over, but when I heard about the way he intended to teach the course, I could not be more excited.

The style the course was taught in was a modified form of the Moore method, named after a topologist who popularized the idea by coming up with a way to teach Topology that allowed the bulk of the materials to be developed and presented by the students taking the course. In the context of our independent study, what it meant for us was that rather than reading a series of lengthy explanations about fully fleshed out proofs and listening to long lectures on the various topics, we used an exercise book which broke the materials down into manageable chunks and required us to work through developing the proofs ourselves. We then met on a weekly basis to discuss our results, along with the obstacles we ran into along the way. This basically meant that John and I would take turns making fools of ourselves on a chalk board while Dr. Uebelacker heckled us a bit and then helped us find our way. Occasionally, John and I would find errors in each other's work, or have competing proofs that solved the problems in a few different ways. This lead to lengthy discussions among the three of us about what sorts of best practices apply and what the pros and cons of each approach were, not unlike the sorts of discussions you might encounter between folks contemplating software design or pairing together to solve a particular programming challenge.

It is fairly obvious that one benefit of this approach is that if you prove something yourself, you will need to understand it much better than if you had just read a proof and made use of its results. Additionally, it's not hard to see that my earlier comment about how teaching causes you to learn something much more deeply would apply here, since every ad-hoc presentation was a teaching opportunity. However, there were many other emergent lessons to be taken from this sort of course which were a lot more subtle.

The constructive nature of the course blurred the lines between the curriculum and personalized exploration. Because you needed to generate the proofs yourself that you later built on, there was nothing in your way if you wanted to explore a side track. Taking this course offered me a formal way of understanding that if you've got a question you want to explore, that there are ways to find your answers without looking them up somewhere. Often times we turned 'I wonder if...' questions into informal proofs that would reappear later in the course as a required exercise. While most of the times these amounted to little more than footnotes in terms of their net impact, the mere notion that we could form conjectures, prove them, and make use of them was an eye opening realization that we weren't simply learning about math, we were also doing math. While we didn't have the time, resources, or environment that would facilitate us to generate genuinely new knowledge, we certainly were experiencing that sort of growth personally, which was tremendous practice for the kinds of things I'm working on now that do take me into uncharted territories.

Finally, the nature of the course baked curriculum, pedagogy, and evaluation all into one cohesive experience. We didn't hand in any written work for this course, but showing up after not doing the reading and the necessary legwork to test out and build upon the ideas we were discussing nearly guaranteed having nothing to say in a class with only two students in it. Evaluation came in the form of presenting our ideas and then discussing them, and even occasionally in the form of observing Dr. Uebelacker make a mistake in his own lines of reasoning and then allowing us to try to fix them. While the responsibility to do the work was individual, the process of evaluating it and making into something of value was a collaborative one, making it so that all those involved had an interest in helping keep things moving along.

In this course, I learned not just Topology, but a whole new way to look at the world. Dr. Uebelacker would go on to correctly point out that the format doesn't apply to everything, and in fact the next independent study we did together on Galois Theory was taught in another format. But when Moore works, it really works, and it can totally change the way you look at formal education. It did for me.

NOTE: I have a handful of other folks who really inspired me in my days at University of New Haven, in various ways. They include but are not necessarily limited to Dr. Sharma, Dr. Fischer, Dr. Eggert, Dr. Griffiths, and Dr. Daniels. However, I singled out Dr. Uebelacker because my Topology session with him has shaped the way I look at training and teaching in general, and in RMU sessions in particular.

People are very interested in Mendicant University, but there is very limited public information out there about it, even now that we've been working on the experiment for nine months aleady. From March 26th to April 8th, I'll be posting short stories daily that might give a better picture of what's inside my head, as well as what's going in the ivory tower that is our Ruby Progamming school.

One thing I like about Sir Ken Robinson is he has a way of concisely describing things that I've felt viscerally for years but didn't have the adequate words to describe. In particular, I like the way he breaks down the concept of education into three categories: curriculum, pedagogy, and assessment. Pedagogy is the bit where the real teaching happens, and like Robinson, I agree that it's the most important of the three components. I need to look no further than my own experiences in primary school and in college to see the huge difference that an emphasis on pedagogy can make.

Most of the educators I interacted throughout school were nothing more than glorified proctors. They handed me input material pre-defined by their state and federal curriculum requirements, in the format that those requirements prescribed, and then expected from me output that could be objectively tested and measured so that it could be attached as a line item to my student id number on a 'permanent record'. Both individually and taken as a group, good scores were considered an education success, and bad scores were considered a failure. Rarely were any of my teachers even permitted to interpret this in a different way, let alone act upon it and produce materials that would actually challenge students to think freely rather than numbly follow a sterile process of information collection and verification. Fortunately, some of the teachers I had were subversive types, and so I learned at an early age the difference between being taught a lesson and being 'educated'.

Listed in rough chronological order, here are the things that my real teachers did for me in primary school that the average 'educator' wouldn't dare try:

• In third grade, after realizing I was bored with basic arithmetic, a teacher wrote up a custom hand written lesson for me covering some basic algebra examples. During a study session while everyone else was doing arithmetic examples, I worked on the problems she gave me instead, and she'd occasionally stop by my desk to quietly give me some hints. I failed miserably at the problems she gave me because they were way above my level, but she taught me a ton in the process.
• In fourth grade, that teacher was re-assigned to teaching fourth grade. By luck or by back-room dealing, I ended up being the only student to stay in her class. In either case, it gave me another year of the occasional custom lesson and at least someone who supported me beyond what the exercises called for.
• In sixth through eighth grade, a shop teacher started all sorts of miscellaneous programs for bored students, including building kayaks from scratch and launching model rockets. Most of these programs ran far over their allotted time within the course, but the teacher let us use the shop whenever we wanted, including to work on our own personal projects. He almost certainly broke every rule the school had about this sort of stuff, and ended up buying materials on his own frequently to fund the courses.
• Throughout high school, a few science teachers hosted several independent studies to allow me to persue my own interests. They let me play with pretty much any materials I wanted, taught me on the spot lessons when needed, and one even started helping me design a circuit for a binary clock similar to the ones they used to sell on ThinkGeek.
• A teacher at the middle school that Jordan Byron and I went to gave us chances to do music and sound recording stuff for shows, I mostly helped run wires but Jordan learned a ton from that. He also gave us access to video editing machines and let us hang out and use the equipment well after he left and just told us to lock the doors on the way out.
• That same teacher got me a job as a sysadmin in my school district in my senior year of high school, because he knew I was good with computers and I was actually A+/Network+ certified. I hated that job and it eventually got shut down due to politics upstream, but it meant I got to start on paid computer work much earlier than most people have a chance to.

I could list out more things like this, but now that I write them out, I realize just how boring and ordinary each one of them sounds. They're just the logical things that a real teacher might do given the resources and time to provide opportunities for individualized education to those who clearly want it. But the thing that makes them interesting is that as a result of them, I frequently got in trouble with administrators or fell behind on my assigned work, making me graduate high school only slightly above the middle of my class. Additionally, while most of the things above sound harmless, most of these teachers made it clear to me that I shouldn't tell people about what they were doing for me, because they could get in trouble or even fired for it! You would think that such treatment would be reserved for those educators who were fondling girls in the closet or making racist comments in class, but not for those who umm... actually wanted to live up to the responsibilities that should come with their job, right?

In my time studying at university, things got a little better, but only slightly. Many teachers were too busy or too frustrated with the lack of quality of their students that they fell back on the same drill and test routines that plague primary education. But many others did start to give me interesting projects and enough academic freedom where I finally felt like I was being encouraged rather than stifled by the academic process. One in particular did some special interest courses with me that paved the way for the way that I'm running RMU, and so he deserves a story of his own! 

People are very interested in Mendicant University, but there is very limited public information out there about it, even now that we've been working on the experiment for nine months aleady. From March 26th to April 8th, I'll be posting short stories daily that might give a better picture of what's inside my head, as well as what's going in the ivory tower that is our Ruby Progamming school.

In yesterday's post, I detailed my own personal story of how I got to the point where I could collaborate with and teach others. I also revealed the fact that since I was given so many great opportunities in life, I find it an absolute duty to find ways for others to benefit from the same good fortune I stumbled into by sheer luck. This to me is a key difference between a training relationship and a mentorship relationship.

A good trainer can give you incredibly useful skills, and to do that they need to understand enough about you to pick the techniques that will be effective with you. But a mentor must go beyond finding the most effective way for you to learn skills A,B,C and needs to touch on what you really want to do in life, and who you really are. Because mentoring relationships are inherently personalized, there's no way to put a dollar value on what they're worth. So for me, I feel it'd be impossible to settle up with JEG2 and feel like I had paid him back for the effort he put into me. That left me with no choice but to try to find some way to pay it forward through community service.

Back before I was even out of the baby pool as far as coding was concerned, I tried to help others by emulating what JEG2 had done for me. I tried to help beginning programmers learn how to code, with mostly disasterous results. At the time, I did not realize that it isn't simply a matter of presenting the information that the person needs to hear, but also reaching them in the way they needed to be reached. There are at least a few of my friends that I fear I've probably scared away from programming for life, or at least set them back by years by emphasizing on all the wrong things. I learned the hard way that without firm guidance from someone much more experienced, an advanced beginner teaching a novice is a bit like the blind leading the blind. Of course, at the time I assumed that because I had a great teacher, I myself would be a great teacher by default, and so assumed that every student I had was stupid until I started noticing all the evidence to the contrary. Thinking that the act of teaching was merely the act of providing access to raw information and explaining it was killing my ability to be useful.

My lack of success as a mentor early on forced me to find some other way to help. I was arrogant enough to blame my students, but not ignorant enough to see when my efforts weren't bearing fruits. Two things ended up working out much better for me: Writing a lot of technical articles, and hacking on open source projects. I was selected early on to be one of the initial bloggers for O'Reilly Ruby, which is now defunct, but at the time was a huge opportunity to get myself exposure. Similarly, through prodding from JEG2 I had been accepted into Google Summer of Code 2006, which gained me lots of attention from the community who I had accidentally tricked through my hubris into thinking I knew what I was doing. Between these two opportunities, I was able to finally feel like I was helping people. Many folks enjoyed my writing and my code, but many others taught me lots through their feedback about just what I didn't know. I even wrote a self-published book about Ruport with Mike Milner to combine these two passions of mine. Through years of repeating this process, I humbled myself a bit. Lesson learned here: Fuck up in private and you may never realize it, fuck up in public and you WILL learn something, whether you want to or not.

I decided that I wanted to stick with a lifestyle that let me hack on open source as much as possible, and write as much as possible. Thankfully, my early work with BTree Technology and later with Madriska Media Group made this very much possible by letting me choose my own hours, commit to only what I felt I had time for, and generally just make my own plan. I have always enjoyed my consulting work because I really like seeing the direct impact of my work on businesses, and over the year, that has become a real passion of mine. But sooner or later, I felt like I needed a break from that and wanted to go purely into open source coding for a while. Hence, the original Ruby Mendicant project was born. Of course, being one who tends to overcommit, I decided that with all my newfound free time, I'd also want to write a proper Ruby book that shared in a more humble way the lessons I had learned over the years, and so Ruby Best Practices was born around the same time.

Both RBP and the Ruby Mendicant project that brought us Prawn were tremendous successes in the sense that they filled big gaps that needed filling. But somehow, they left me feeling unsatisfied. In a case of the grass being always greener on the other side, soon after I completed these projects, I turned back to consulting with a renewed sense of energy, and in the course of a year with Brad's help made huge positive changes to the way we do things at Madriska, and built up a set of processes and a team that totally kicks ass. I think the draw of consulting to me was once again being able to see the fruits of my own labor, something you tend to miss when you do open source. In open source projects, while you may get some really awesome contributions from people from time to time, they come in fits and spurts and the vast majority of your interactions end up being with users, who often don't quite understand how free software projects operate. It's also very rare for people to show what they've used your software to build, even in a healthy community. Thus, the impact is more visible in consulting than in open source, on an average day. Writing is a little bit better in that the reactions tend to be helpful or positive, but generating buzz is a job in itself and isn't quite fun.

Over time, I got a bit fed up with an internet that you can pour so much into, know that people are using and appreciating your work, but get so little back in the way of feedback. I still struggle with this and feel like it's quite unfair until I realize that my own patterns of behavior reflect the same thing I'd want to criticize. How many authors of open source projects that I've used do I thank for their efforts. Not nearly as many as I should.  How many projects do I patch or report bugs against? Even fewer than those I send thanks to? How many inspiring things do I read each day that I either don't share at all or only go as far as posting a RT on twitter? God, it'd be embarrassing to mention that number. I don't think that we're all bad people for not doing these things, it's just the nature of the beast. The internet is a huge consumption machine, and producers rarely get proper acknowledgement for their work. My heart feels lighter when I go to users group meetings or conferences because the most common word I hear on the hallway track is "Thank you", either for work I've done, or coming out of my own mouth to someone else I've appreciated. That tells me we do give a shit, but that the internet is vast, and we're just too busy to say thank you all the time.

I still wrestle with those feelings, and have worked to figure out how to solve them. Then it dawned on me: the real joy and growth that comes from this feeled is through interactions, not mere production and consumption! This is the difference between giving a talk and a giving a training, which I learned by first doing some trainings at Lone Star Ruby Conf, and then later working on Compleat Rubyist with David A. Black and Jeremy McAnally. In a training, you're giving people some useful information, but then working with them to make sure they understand it and getting to see a glimpse of how they use it. This is profoundly different than talking at a group of people who have their heads down in their laptops for 30-45 minutes, or writing a long winded post on an open source project so full of assumed knowledge that the reader must have their mind reading device engaged to make heads or tails of what you've just said. Trainings not only help people, you get to see that you've helped them! This closed the loop for me, and made it so that I felt my efforts were being matched with a sense of personal satisfaction that helped keep me emotionally stable as I put great effort into these things.

By the time I started really digging into training people, I had learned a whole lot more about the field and was finally ready to admit how full of fail my earlier attempts were back when I was still in the kiddie pool. But as I said at the very beginning of this post, the thing that separates training from mentoring is that the former is a fixed, fairly well defined commitment, that you can at least begin to guess at the value of. Mentoring is about the long game, and is about personal connections. But this is something I truly didn't realize until *after* starting RMU, so we'd be jumping ahead to discuss it now. More about that in a future story!

People are very interested in Mendicant University, but there is very limited public information out there about it, even now that we've been working on the experiment for nine months aleady. From March 26th to April 8th, I'll be posting short stories daily that might give a better picture of what's inside my head, as well as what's going in the ivory tower that is our Ruby Progamming school.

Those who have followed my works know that it's no secret that I've credited virtually all of my success in software development to a single mentor, James Edward Gray II. Given the huge amount of people I respect and have learned from in this field, this may seem like a bold or even disingenous claim to make. But despite those concerns, it's a truth that I'd bet my whole reputation on.

For a period of about three years when I was in my teens, JEG2 spent time with me on a daily basis showing me first, what a bad Perl programmer I was, and then later, what a bad Ruby programmer I was, even if he started learning Ruby only a couple months before I did. Before I met James, I thought I was an awesome programmer, and I didn't yet believe that programming is an inherently hard thing to learn. In fact, I didn't even realize that programming isn't a single skill to master, but instead a complex web of related activities that are impossible to practice in a narrow minded, linear fashion. With James as my mentor I learned that you don't just need laser-like focus to be good at this kind of work, but you also need to be able to carry a lantern from time to time to shed light on the big picture.

Once you know that a lantern is a key part of the programmer's survival guide, that opens you up to make meaningful connections in the broader software community. The next step is being able to form a clearer and clearer picture of what this field is about, personalized by your own desires and interests. Back in early 2004, Ruby's community was still somewhat centralized and it was fairly easy to get a group of people in a single room or on a mailing list and call them a representative population of Ruby programmers. During that period of time, I was particularly inspired by a handful of folks from Ruby's old guard, in particular Matz, Jim Weirich, Francis Hwang, James Britt, Hal Fulton, Zed Shaw, and David A. Black. It's not a coincidence that most of these folks happened to also be on JEG2's list of heroes, both because of the centralized nature of the community, and because I assumed that if James found someone technically interesting, that he probably had a good reason for it. Studying the works of these individuals, I found that they had lots of different views on things, and that sometimes, they had ideas or opinions that conflicted with what JEG2 believed, but didn't appear to have any obvious flaws. This is when I learned that even something as objective as programming has both subjective components and things that are sufficiently complex to cause experts to reasonably disagree with one another.

Over time, JEG2 and I transitioned from a purely student/mentor role to a role of collaborators, in which I could actually meaningfully help out in some way. My first project with JEG2 was HighLine, in which he did most of the work, but that to this day, there is at least some of my own code in it that wasn't completely ripped out and re-written. Later, JEG2 acted as an active collaborator on the first big project that I led myself, Ruby Reports, even if he didn't actually write much code for it. While it's not really a terribly important detail in the grand scheme of things, I think it's an interesting historical note that the Ruby 1.9 CSV standard library's initial development started as a need for the company that I was doing work on Ruport for.  Once the lines of our relationship blurred a bit in this manner, it gave me the necessary motivation to connect with others as collaborators. As a result of this, I ended up getting my first patch accepted to an open source library that I didn't help build by sending Aaron Patterson a couple crappy changes to Mechanize. Somehow this lead to a good friendship with him, even if that friendship mostly consists of me calling in the occasional favor to Aaron and by sheer coincidence, not doing much in return for him. I guess a single accepted patch buys you a lot!

Soon enough, I found myself in a situation where people were submitting patches to my own projects, and over the years gained great benefits from getting to know folks like Dudley Flanders, James Healy, and Mike Milner on my Ruby Reports project. Work on this project led me to a subcontracting gig that JEG2 helped me set up by just making an introduction for me to the founder of Madriska Media Group, Brad Ediger. What started as a bit of work on a single project led to a lasting business partnership with Brad and I that has now gone on for something like four years. This relationship has been so successful, that I pass all my consulting leads through Madriska not because I couldn't handle them on my own, but because I love working with Brad's company so much. While these days RMU prevents me from doing any active development work for Madriska, the commission I receive from my team's work, along with the small amount of project management I do for Madriska helps cover some of our basic living expenses. Without James, there's no telling if I would have ever met Brad. That'd be both a community loss as well as a personal one, considering that Brad is now defacto lead developer on the Prawn PDF generation library that I started but never quite finished.

These days, JEG2 and I have diverged quite a bit in our respective paths, but our interactions in my formative days as a software developer have shaped me in ways that I'll never be able to fully grasp. I take it as a good sign that sometimes we disagree these days, and that once in a while, I end up being the one who teaches JEG2 something in the process. But it should be at this point pretty obvious why I credit so much of my own success to James. After reading this story, you may be wondering what happens emotionally when someone takes on an arrogant, hot headed teenager who thinks they're some sort of Perl guru and shows them exactly how much they're missing, and then follows that up with all the support necessary to turn a train wreck into a success story? In my case at least, you end up with someone who feels an absolute responsibility to pay it forward in whatever way I can. More on that in our next story!

Note: this is a bit of an unfiltered ramble, but I wanted to make some sort of public statement about how our first week after PuzzleNode's launch went.

Last week, we launched a programming quiz website called PuzzleNode as a fun way to conduct new student admissions for Ruby Mendicant University. While the primary purpose of this site is to act as a sort of entrance exam for our core skills course at RMU, it is also suitable for general use. Because it is modeled in the style of Project Euler or the Internet Problem Solving Contest, people aren't limited to solving the puzzles using Ruby, any language will do.

In less than 7 days, we've had 110 people create accounts, 27 attempt at least one puzzle, and of those folks, 12 solved at least one problem. Two folks have even solved all four problems, which amounts to no small amount of work. These numbers are modest, but better than we expected for a project that has only indirectly been mentioned through our call for participation for RMU. People seem to enjoy the problems we posted so far, and we're still seeing new signups each day. But after a week or so, we're feeling more embarrassed of our execution on this project than we are proud.

PuzzleNode was built in the same manner that our original work on university-web was conducted; an hour here and an hour there between active RMU operations such as courses, alumni network activities, and other administrative work. The code is something Jordan and I hacked together whenever we got a bit of spare time. This is not how we usually like to do our work, because it results in sloppy, unreliable products. To put it bluntly, we hardly tested either the puzzles or the application at all before we went live with PuzzleNode, and that was a very bad idea.

In the first hour after launch, I immediately detected a critical bug in the system that we did not anticipate ahead of time. We were using send_file for our file downloads, which worked fine when running the app in our local environments. But we quickly found that send_file did not work on our production server, which is Passenger based. I did not yet get a chance to look up the root of the issue, but I had run into this problem once before and found that it's possible to work around it by using send_data instead. So, I went ahead and cargo culted that old fix and it solved the problem, but likely not before lots of folks tried to download input files and got 0k file sizes.

Soon after that, bug reports started to roll in about the problems themselves. We simply hash uploads and compare them against a reference fingerprint, which means our system is very stupid about things like whitespace. This is something we're okay with because we keep the output specifications very simple, but two of our own solutions did weird things with whitespace by accident. We forgot to put a trailing newline at the end of our solution files, which is unintuitive and caused a bunch of false-negatives for submitters until we fixed them and re-uploaded them. Soon after that, the real problems began to uncover themselves.

Two of our four problems did not have unique solutions, which when you are using hashes to verify results, is a big problem. One we fixed by uploading a slightly modified input file which guaranteed a unique output. Another we fixed by introducing some instructions on how to break ties between equivalent solutions. It took a long time to discover that these problems were flawed, and took a fair bit of back and forth with frustrated submitters who were quite sure they had a correct answer, but not sure why PuzzleNode was telling them they were wrong. Thankfully, these folks took it in stride, giving us patient, helpful bug reports until we uncovered the root issues and solved them. Fixing these problems caused solutions to start rolling in, a sign that things were looking up. But somewhere along the line, bad turned to weird.

Lots of folks successfully solved Problem #1, so we had assumed it wasn't flawed. But we were also receiving problem reports from folks who were pretty  sure their solutions were right, which felt like a contradiction. Sure enough, our solution was wrong, but not for any reason that we could predict. We learned via a tweet that apparently, the support for Banker's rounding in BigDecimal in Matz's Ruby (MRI/YARV) is broken, and always has been. That forced us to implement our own rounding function, and cross check it against JRuby and 1.9.3dev to confirm our new answer. This seemed to solve the problem, but required us to post a glaring disclaimer that basically said "Be careful not to get bit by the same bug we did".

In the end, this whole thing feels like a bit of a clusterfuck, but it's worth mentioning that it was never meant to go this way, and that we've already put plans in place to prevent this from happening again in the future. Our original plan was to run the puzzles internally within RMU's alumni network for several weeks before the entrance exam opened, to test both the app and the puzzles for correctness. I was also supposed to sanity check the rough drafts of puzzles the students wrote, and maybe even hand verify their solutions. But instead, what I ended up doing is uploading them the day of release and letting them loose on the public. Such is the life of running something like Ruby Mendicant University, which is in almost in every possible way akin to a startup environment in which I'm the frazzled founder left holding the bag when the shit hits the fan. As important as PuzzleNode is to us, it was one of 100 things I needed to do for RMU that week.

Thankfully, our "Ready... FIRE! Aim..." approach has its limits, and we're actually craftsmen and professionals at heart. We know when we've botched a release, and we botched this one. We were scared that if we didn't release it on the date we promised, it might get buried under 100 other things, and bringing the site live forced us to treat it as a real thing. But we wasted a lot of people's time with badly tested infrastructure and problems, almost entirely due to my own lack of available time to do the proper QA checks. So, with that in mind, it's not enough to say we're sorry, I want to make sure something gets done about it.

Starting tomorrow, PuzzleNode is going to have a proper support structure for it. One of our alumni at RMU, Brandon Hays, has kindly volunteered to manage the triage, testing, production prepwork, and launch of new problems. We are also going to modify PuzzleNode so that we can pre-release problems to the RMU alumni network so that they can be tested ahead of time. In the future, every problem will be solved by at least a few testers before it goes live. This will also serve as QA testing for the app itself, which now that we're out of crisis mode on, we'll commit ourselves to working on in a bit more careful fashion. But when things do break down from time to time, you'll have an official way to reach us, and someone ready to help you when you do. This is what we should have launched with, and I'm sorry that we didn't. But hopefully, our ability to fix things up quickly will restore any confidence we lost by doing such a sloppy launch.

Stay tuned to the announcements page on PuzzleNode for details about the support system we're putting in place. Until then, please go ahead and try the puzzles now if you haven't seen them yet, or try them again if you were having problems before. All in all, it's a cool site that our staff and students have put a lot of effort into, and I hope that it becomes a fun diversion for any hacker who enjoys a good puzzle from time to time.

PS: For those concerned about the broader problem that the velocity of the materials and tooling being produced around RMU is coming at the cost the quality and consistency of our work, we hear you. The spring and summer are going to be dedicated to doing less, better, and we're taking lots of steps in that direction. More to come about that soon. And for what it's worth, all these corners we've been cutting are because we pour all our energy into making RMU courses themselves amazingly high quality. But there are ways we can keep that up without shipping crap for our supporting systems.

The Ruby Mendicant University Study Hall is an opportunity for Ruby beginners to be paired up with somewhat more experienced developers to help them work through the problems they're having. This program consists of a series of 45 minute discussion sessions over IRC between beginner-level Rubyists and mentors from the Ruby Mendicant University alumni network.

We will be hosting our second week of mentoring sessions from 3/14-3/18, for more details, please see the RMU Study Hall #2 announcement on the RMU website. Our first session back in February went great.

The notion of "fail fast" is something of a mind virus among software developers. It doesn't matter if you're talking about hacking on open source, developing products for a startup, or just spiking on a bit of experimental code at work, people want you to quickly realize when you're headed up the wrong path. This is the whole motivating factor behind the "release early, release often" culture in the free software community, the backbone of most iterative development workflows, and probably a big part of what drives the whole test-driven development obsession. While there is definitely a reason why this idea is so popular, I find lots of folks miss the point.

The key mistake I see people make is to assume that you learn as much from your failures as you do from your successes. This sounds attractive, because it lets you pat yourself on the back regardless of the outcome of your work. But in my own experience, while failure always teaches me something about myself, it only really gives me some insights on how to avoid that kind of failure again in the future. This sort of insight is nowhere near the same thing as learning how to succeed.  With that in mind, my tendancy to embrace "fail fast" is focused on a much more simple motivation: Quickly realize what I'm doing wrong, so I can stop doing it and try to do something else instead. While this isn't nearly as romantic, having rapid feedback about what ideas of mine are stinkers helps me avoid going down a deadend road at a snail's pace.

Real experience is gained through frequently seeing your efforts lead you to success. If you find yourself failing all the time, rather than chalking it up as some sort of learning experience, you should re-evaluate your goals and either learn to accept more modest forms of success, or consider trying some entirely new ideas. What I've found is that while both success and failure leave a certain amount to chance, it's easy to chain together either successes or failures in an accumulative fashion. Whenever possible, I feel I learn and grow a lot more from chaining successes than I do from chaining failures.

It's true that if you're not failing at least of the some time, you're probably not growing. But if you're failing most of the time, you're only learning how to be a failure. To prevent this from happening, use "fail fast" as a metric for finding the right sort of environment and the necessary conditions that you can carve out some success in, rather than a crutch to fall back on when things don't go as expected.