RMU Round 2: What I learned

Note: This is the third of several posts about the philosophical and technical learnings from my Ruby Mendicant University Web Development course:

Part 1: About the course & what it was like

Part 2: A first-timer’s process of styling a site

Part 3: What I learned from the course


While the previous post was about the tools I learned to use, this post is more about my successes, my failures, and the philosophical things I’ve picked up in this session.

My successes & failures:

Styled website WIN.

While I wouldn’t say I could jump in and whip up raw CSS from scratch, with the toolkits provided within Compass, Sass, and Blueprint, I can kick out a decent web stylesheet pretty quickly and without a lot of fuss. Most of the intimidation I felt about CSS was groundless, though it can still be punishing at times.

Web Fonts FAIL.

I tried several things, but couldn’t figure out how to replace my default font (Helvetica) with a font using Google Font Directory. Web fonts became a fight that I’d just have to have another day.

Overlapping styles FAIL.

One thing Compass lets you do is cleanly separate your stylesheet partials on a page-by-page basis, which seems to be how Jordan does his. I opted instead to create partials on a per-type basis (one for forms, etc.), and this bit me badly later.

I altered the styling of my form partial for an entry form, only to go back through my app just as I thought I’d finished to discover I had completely broken my file submission form.

This added lots of extra work when I felt utterly done with the project, and actually led to my epic Git FAIL.


This was the second major time I severely frustrated myself with my lack of Git knowledge. I didn’t realize git -rm actually deletes a file, rather than a reference to a file, and I did a git revert to before I’d fixed a bunch of broken stuff.

In the end, I wound up swearing at my computer a lot and ultimately re-doing a lot of work.

At my next convenience, I’m going to go through Jim Weirich’s Git Immersion, it’s an open tab in Chrome right now, waiting for me to learn how to suck less at Git.

Learning jQuery FAIL.

I had planned on learning jQuery as a part of this course, and it just didn’t happen. I watched a few screencasts and read up a bit, but didn’t find occasion to even dip my toe in the jQuery pool.

GeoKit WIN.

GeoKit is just awesome. It’s one of the nicest, simplest, and most useful web API tools I’ve used so far.

Google Maps FAIL.

I had assumed that someone would have written a nice Ruby API for Google Maps. The answer is “no, go learn Javascript and do it yourself.”

To embed a map, you have to stuff a lot of Google-specific code in your <head>, which doesn’t play nice with the concept of a layout page. It really doesn’t play nice with Haml, so it was back to ERB for me.

Even though I could look up an address and make a map display, wiring them together required a lot of work from Jordan to fix my mistakes.

On confidence:

This was a big confidence booster for me. The only thing standing between me and getting a website done is making the time to do it. If you want something, just do it.

On pacing:

The September session taught me that when you have 3 projects to accomplish, don’t wait until you’ve finished Project 2 to move on to Project 3. Start planting the seeds for all your projects early on, so that you’re not rushed to do 100% of anything in the last couple of days.

Or it *should* have taught me that. Instead, I tried to accomplish my projects serially, spending a few days on Project 1, then more than 2 weeks on Project 2, and less than 48 hours on Project 3. Needless to say, Project 3 was a bust.

On sleep:

Toward the end, I was working until at least 2 or 3 AM every day trying to get my app styled, and sleeping an average of 4 hours a night. Greg told me to ease up, that RMU isn’t meant to upset someone’s life balance. He was right that I was pushing myself too hard, as I have a tendency to fixate on a goal and not let up until I’ve finished, even when that isn’t the wisest course of action.

However, I like the idea of “excess, in moderation”. I pushed it really hard, but not so hard that I’m burned out from further work. Maybe in another 6 months or so, I’ll do another sprint where I immerse myself in learning some new thing or breaking some perceived barrier.

If I could go back and change things, I’d probably have scaled back my ambitions somewhat and pushed the average up to 5 or 6 hours a night. I think people were starting to notice that I was cranky.

“No heroes”

Greg added that RMU isn’t about elevating heroes. I hope my crazed ambition is not perceived as any kind of heroics, because RMU is a pretty personal journey for each student. There is no Honor Roll, there are no gold stars, and there’s no valedictorian. It’s not for one person to try to set a high score. I was striving for a very personal goal, to conquer my hesitance to design a website, and I feel like I (barely) achieved it.

Finally, thanks

Lastly, I want to reiterate my gratitude to Greg for running RMU and to Jordan for his inordinate amount of work in helping me achieve my goal for the session. I still have a long way to go before I’m a “real Rubyist” or a “real web developer”, but I’m much closer than when I got involved in RMU.

RMU Round 2: Process, Tools, & Techniques

Note: This is the second of several posts about the philosophical and technical learnings from my Ruby Mendicant University Web Development course:

Part 1: About the course & what it was like

Part 2: A first-timer’s process of styling a site

Part 3: What I learned from the course


This post is more about the process and technical challenges I faced in creating a full layout for the first time. In my final post on the topic, I’ll share more of the general lessons from this session.

For me, the process went as follows:

1. Mockups

2. Backtrack & fix (set the stage)

3. Create assets

4. Implement styling on page-by-page basis

This, with a lot of reading and learning about tools & technologies I needed to get the job done.

The mockup stage: Balsamiq, etc.

I cannot tell you how critical this is. The mockup stage is the part where you think through all the user’s paths through a site, what they’ll expect, and what context they’ll need to get what they want. You get a sense for visual priority and information design. All before writing one line of code.

The visual context simply cannot be guessed at or thrown in during implementation. My opinion is that if you’re not doing a thorough mockup before coding, you’re probably going to screw something up pretty badly.

I’ve used a lot of different mockup tools, including sharpie/paper, Mockingbird, HotGloo, Keynote UI templates, and iMockups for iPad. Balsamiq is my personal choice. You can learn it in 20 minutes, and cloning your mockup and then exporting a bunch of tabs to .png will save you lots and lots of time. My 2nd choice would be sharpie/paper.

Once it came time to actually style the pages, designing to a mockup didn’t tie my hands at all. It actually liberated me to work within the framework to offer the best presentation possible, without worrying about fundamental questions like whether to choose a 1, 2, or 3-column layout.

It took a few hours to think through properly, but I got those hours and more back when it came time to turn those mockups into styled pages.

The “Fix the broken pieces” stage

So far in my work at the office and in RMU, one consistent theme is that the thinking you put into the mockup stage will reveal flaws in the existing plan or implementation.

In this case, there were unfinished pieces of the app; features that were clearly intended but not built out, like an Announcements feature and a Puzzle Details page. The lesson here (intended or not) was that in order to move forward, you’ve often got to move back and clean up a little bit.

Once this was done, the stage was set for some actual design.

The “create assets” stage

This one seems optional, and Photoshop skills are not necessarily required, but I was sure glad I had them. I didn’t do any high-fidelity mockups or anything, but I did create my logo & background images, and tweak icons.
I also used a nifty little site called Stripe Generator to create repeating stripes, which is usually a laborious process involving Illustrator and/or Photoshop.

Last stage: Styling

OK, enough playtime. Now it was time to jump in and get my hands dirty. And then–

Haml, WTF?

I jumped into the project and immediately came to a screeching halt. Instead of my more-familiar ERB syntax, the views were in Haml.

Immediately, I was faced with 1) converting all the views to ERB, or 2) Learning enough Haml to get by. I figured that converting the Haml to ERB would require nearly as much research as just keeping it, so I decided to stick with Haml.

This was itself a crash course, and I came away both impressed and frustrated with aspects of Haml.

What makes Haml so great?

There are no closing tags. It has a Ruby-esque syntax, and it’s much easier to drop in native Ruby than in ERB. It uses CSS-style selectors. It’s terse, clean, and easy to read, once you’ve got the hang of it.

There apparently used to be serious performance issues, but they’ve since been ironed out, and Haml is about on par with ERB for speed in compiling to HTML.

What makes Haml frustrating?

There are no closing tags. That means that you’re in the realm of “significant whitespace” in your views. Personally, I don’t like having my views fall apart and spit an error at me because of my indentation.

Haml is optimized for cleanliness, not flexibility. Perhaps the most damning thing about Haml is that you can be almost certain that you’ll need to fall back to ERB (or have Haml interpret HTML via plain text, ugh) eventually for some edge case. If it works in HTML, it works in ERB. Not so with Haml. You’ll either wind up twisting something straightforward into knots to fit into Haml’s syntax, or fall back to ERB.

Would I use Haml again?

Basically, Haml is a lot more fun to work with than ERB, right up until it’s much, much worse. One surprising thing is that you don’t have to choose; you can use Haml most of the time and use ERB for your edge cases.

Yes, Haml did add a significant amount of time to my project. But depending on the project, it’s likely I’ll use it again in the future.

Once I got the hang of the markup, it was time to start styling my project. I wasn’t sure where to start, having never styled a page from scratch before.

But after my first go-round with CSS, I started getting really frustrated.

**Does CSS Suck?**

That’s a total troll question, so I’ll rephrase:

How did people do layout before Compass & Sass?

We had a pretty heated debate in the #rmu IRC room about whether CSS sucks. The sticking point was that an educational context basically isn’t a place to say that any given tool sucks.

But it’s a good question: Does CSS suck? Greg Brown has created a layout framework for PDFs in Prawn, which taught him that creating a flexible layout is a hard problem, and CSS has spent 10 years doing a pretty good job of solving that problem.

But Ruby developers used to having a universe of capability and spoiled on the “principle of least surprise” get a rude awakening. CSS is a crappy programming language, if that’s what you’re expecting.

With CSS, I kept having the experience of “tweak, tweak, tweak, KABOOM”. A small change may mean nothing, or that your layout collapses entirely, or your signup form is wrecked because of a seemingly unrelated change for another page.

That said, there are some frameworks that turn CSS into much more of the programming language that developers expect.

In fact, when it’s all working together well, I’d say that Haml/Sass/Compass/Blueprint combo is a pretty friendly way for developers to do design. Here are the pieces, broken down:

Sass: CSS, but like, for programmers. It adds some powerful features to CSS:

Variables (e.g. $light-gray: #f7f7f7)

Mixins (e.g. @include bordered-table)

Nesting & Inheritance (I didn’t use these much)

SCSS: It’s Sass but with CSS syntax. Basically, Sass is for people who really hate braces and semicolons, and SCSS is for people who want CSS compatibility. SCSS seems to have become the de facto standard for new Sass projects.

A very minor gripe is that because of the syntax change, a lot of the tutorials you’ll see will be hard to understand in SCSS, as Sass was the preferred syntax at the time they were written.

Compass: Compass doesn’t do a good job of delineating its role from that of Sass. The fact is, the majority of the benefits they claim come from Sass, but the additions Compass brings make it absolutely indispensable to me now:

The ability to define and mix in partials

Auto-compiling for Rails projects

A whole bunch of pre-defined (and easily configurable) mixins.

Compass gives you a nice framework to start from, and a project folder that is relatively easy to keep clean and organized (though I did manage to mess that up later).

For an example of the benefits of Compass/Sass, if I wanted a drop-shadow and border-radius on a div, first I’d import the partial:

@import "compass/css3";

Then I’d include the predefined mixins in the style for that div:

@include box-shadow;
@include border-radius(10px);

Combined with the ability to define your own mixins, this is a huge time and sanity saver.

Auto-compiling stylesheets is also awesome, because it means every time you save a change, you get real-time feedback, as if you were editing the CSS directly. It also recompiles each time the server is restarted, so every time you push an update to Heroku or it spins up your instance, it throws an error while the stylesheets compile. I’m not sure how to get around this, but it’d be irrelevant if you had a dedicated box that didn’t spin up/spin down like Heroku.

Blueprint: Blueprint exists independent from Compass, but it almost seems like they were destined to be together. It includes some decent defaults for a Grid system, forms, and typography.

960gs vs. Blueprint Grid

Basically, a grid system is a way for you to define the horizontal layout of your pages so they don’t look crappy. They pick a default column count of 24, so you can cleanly split a page into 2, 3, 4, (or 6, or 8 ) columns. It’s configurable, but the default seems like something I wouldn’t be likely to change.

Brian Hogan (PragProg author of “Web Design for Developers”) recommended I choose 960gs over Blueprint’s grid due to 960’s better documentation. However, I hadn’t realized that Compass includes mixins for Blueprint’s grid system.

So I chose Blueprint grid.

To demonstrate how awesome Compass is, I’ll go back to Compass mixins:

Let’s say I want to create a simple 2-column layout with a header, footer, main area, and sidebar. This is a pretty basic request, but handling this in CSS requires a lot of careful pixel calculation and repetitive typing.

Here’s all you’d need to do it with Compass/Blueprint:

.two-col {
#container {
@include container; }
#header, #footer {
@include column(24); }
#sidebar {
@include column(8); }
#content {
@include column(16, true); }

What amazed me is that I was able to get the project completed despite the initial uphill battle of learning these tools. I’ve only scratched the surface of all the amazing things you can do with Sass, Compass, Blueprint, and their associated mixins, but I look forward to using them more in the future.

Seriously, how cool is it to be able to take something from a thought to full visual execution?

That’s not to say the road was perfect. In my next post, I’ll talk about the rest of what I learned, including my EPIC FAILS.

Ruby Mendicant University: Round 2

or: How RMU is teaching me to stop making excuses and get stuff done.

Note: I’m going to break this into several posts about the philosophical and technical learnings from my Ruby Mendicant University Web Development course:

Part 1: About the course & what it was like

Part 2: A first-timer’s process of styling a site

Part 3: What I learned from the course

If you’ve been following this blog for a while, you’ll already know that I participated in the September session of Ruby Mendicant University’s Core Skills course.

Much like the mafia, one doesn’t graduate RMU, you just get pulled in deeper. There are course offerings for alumni that range from more advanced Object-Oriented design practices, writing skills, statistics, and more. After a few months of relaxing mixed with a little bit of mentoring and casual participation, it was time for me to dig back in for the first Web Development course.

This time Jordan Byron (@jordan_byron on Twitter) ran the course, and it was his first time teaching. Anyone who has endeavored to tutor, advise, teach, or mentor knows that this is about an order of magnitude harder than you’d expect.

It was clear that Jordan cared deeply about helping us succeed, but that didn’t change the fact that everyone involved was biting off a bit more than they could chew. But for my part, Jordan’s help meant the difference between success and failure, and I learned a great deal thanks to his oversight and involvement.

For me, I’ve been learning Ruby and web development mostly by myself in my spare time for the last couple of years, and the sudden boost you get by having guided, time-bound projects is staggering. Even having been through it twice, it’s tough to imagine learning so much in less than a month.

Where I started from:

I had zero experience with CSS or true web design before this course. While RMU students must pass a Ruby-oriented challenge to get in, setting a baseline for Gregory Brown to work from, no such bar existed for the Web Development course.

This put Jordan at a bit of a disadvantage compared to the other courses offered within RMU. I showed up with no existing skills, expecting to be tutored in the most basic aspects of styling web applications.

The course:

The course itself was tough. Here were the requirements, roughly, in my words:

1. Submit an existing project for peer review, and review at least 3 classmates’ projects. Keep the discussion relatively high-level, more about frameworks, challenges, etc. rather than implementation details.

2. Take an existing project from barebones functionality to a fully styled site.

3. Create a geo-oriented project using Google Maps or similar geo API.

For me, step 2 took the lion’s share of the time. As it wound up, this list was a little *too* tough, and relatively few (or perhaps none?) completed all the requirements. The session was deemed a good pilot for future sessions, and a lot was learned on all sides.

“Uh oh, I’m gonna drown.”

There wasn’t a lot of additional instruction. There was a goal, and a list of potential resources and tools (put together by Jordan and augmented by the students). Jordan’s work is also open-sourced, so it was possible to go see how he solved similar problems if you were willing to dig into the code, though I discovered this a bit too late.

I quickly realized that I was already in over my head, and this “sink or swim” course would likely see me fail unless I drastically upped my output. For a relatively experienced web developer, this would have been 5-10 hours a week.

But like the core course, I found myself far enough behind that I required about 20-25 hours a week to catch up to where I should have been in starting the course. I’ll talk about why that may not have been such a good thing in the final post.

First assignment: Peer review

The first assignment was straightforward, simple, and fun. Our job was to post some work we’d done, ask questions about it, and comment on the work and questions of our peers.

I wound up commenting on all but two of my classmates’ projects, and hoping in vain that I’d get back around to the other two. I learned a couple of things that I was immediately able to do to improve my site, and saw some cool implementations that others came up with.

I did have to run out and research a little before I felt comfortable answering a lot of the questions. All in all, the first assignment was a bit time-consuming, but not particularly difficult.

Second assignment: Style a website from scratch

I’ll cover this at length in my next post. Basically, it took all but the first few and last couple of days.

Third assignment: Geo-aware application

I basically flubbed the final assignment, having left myself with less than 48 hours to complete it. After Jordan cleaned up my messy code, I got a basic mapping tool running using GeoKit to geocode an address, and Google Maps to display it. All in all, not my finest hour, but I’ll cover a bit of what I learned in the final post.

In Part 2, I’ll go through some of the implementation details, and what I had to learn in order to take a webapp from a barebones implementation to a fully-styled, “invite your friends” site.

I’ll also ask the flame-baiting question, “Does CSS suck?”

A few words on Steve Jobs

via http://dylanroscover.deviantart.com/

I found myself strangely affected by the news that Steve Jobs was taking a leave of absence. I don’t know the guy. I just buy his stuff. We never found time for a personal chat during my brief stint as an Apple Store employee.

So why did the news make me so melancholy, even to this minute?

It might have something to do with the fact that it was his commencement speech at Stanford that planted the seed in my mind that life is beautifully and tragically ephemeral. I didn’t know what to do with that information at the time, but over the past few years, this mindset has really shifted me to strive to live a life of purpose.

It only occurs to me now that, just as he saw a vision of the future at Xerox PARC in the 1970s, he saw another 8 years ago with touch/gesture-based computing, and he’s been absolutely driven to see it take hold. It’s happening now, and it’s irreversibly changing the way people interact with computers. The iPad isn’t some gadget, it’s a puzzle piece in Jobs’s vision of literally altering the future of humanity.

Is it egotistical for him to believe that if he didn’t bring about these visions of computing, from personal, to graphical, to touch, that they would never have existed (or would have been horribly mangled)? Yes, definitely. Is it true? Almost assuredly.

When Jobs and Gates were asked about legacy a few years back, Steve brushed off the question. I thought it was odd, but I get it now.

The term “legacy” tends to be associated with the question, “How will I be remembered?” Alfred Nobel didn’t want to be known as a merchant of death, and he did indeed radically change his legacy. Bill Gates turned his focus 180 degrees, from taking money from rich Westerners to raising the standard of living for the world’s poorest 10%.

Steve Jobs has no time for that. For him, the idea of legacy is probably a distraction, because he goes into work every day with the intention of changing the world, not the way he’ll be talked about after he’s gone.

Jobs says that he once had to choose between an “important” business meeting and a date with the woman that would someday become his wife. His thought was that if it were his last day on earth, he’d choose seeing her. So he did.

What would I do if today were my last? Would I be doing the same things with my family? Is there enough of my own mission in my work that I’d still be there? If not, why? What am I going to do about it?

It’s important to note that Jobs doesn’t say “live each day like it’s your last.” He just poses the question and says that when he has too many consecutive days where he doesn’t like the answer, it’s time to change something.

If you haven’t watched his speech, please do. He implored those students (and by extension, me, and you) to not spend your days living someone else’s life, because there’s so precious little of our own.

I’m grateful for the lesson, and hopeful that Steve will recover fully and to continue to embody it.

Why “Sell the hole, not the drill” is bogus

via teh Googlez

If you’ve ever worked in marketing (and possibly if you haven’t), you’ve heard the phrase “sell the hole, not the drill”.

That’s a ludicrous example, because it’s patently wrong.

I was brainstorming logo ideas this evening: one was an arrow having hit the target, and the other was a first-person view, looking down the shaft of the arrow, with a target downfield.

Which one has emotional resonance? The arrow in the target, no matter how perfectly placed, is still and lifeless (not to mention a bit cliché).

However, with a different point of view, you can convey anticipation. A drawn and held breath. A steady hand. The tension in the bow. A moment of truth.

It’s my assumption that people don’t practice archery to see an arrow placed in the center of a target, but to experience the emotional swing that occurs between that point of extreme tension and the thrill of accomplishment afterward.

However, someone selling a bow to someone would most assuredly sell on its specifications and its championship pedigree.

Likewise, people buy drills to build their dreams. But they know that their dreams deserve the best tools. It’s why the cordless drill tantalizes with “18 Volt”, “450 in.-lbs. of max torque” and comes in construction-site colors like yellow or red. It doesn’t say “3.6 holes per minute”.

Because someone buying a drill understands its basic function, they can project all their anticipation, hopes, and desires on a simple inanimate object. They draw the line from the drill to finally getting that deck built. And because they did the dot-connecting, their emotions are fully engaged. You just stand back and collect your drill dollars.

The counterpoint is with newer, harder-to-understand technology. Apple’s done a masterful job of connecting the dots between a box full of circuit boards and a finished home movie, and turned what is basically mobile videoconferencing into a heartwarming way for far-away soldiers to see their newborn babies.

But as a product matures, people start resenting being told how to feel about the tools they already understand, and can create their own emotional reasons for buying. They just want the best solution or tool out there.

As long as your customers understand what they want, go ahead and sell the drill. And if people don’t yet understand your product, service, or market, you’re not exactly selling drills, are you?

Grabbing a shovel

“You’re obviously talented and sharp. But I have no idea how to use you”.

About the third time I heard this from different bosses, I felt like an utter failure. Why would someone as capable as I felt be so woefully misunderstood and underutilized?

As it turns out, it was 100% my fault, and the fix isn’t all that hard.

As I outlined in another post, a coworker shared the secret of his relatively stress-free work environment (the same environment that stressed me to the point of physical illness). He was a free agent. He was only there because he wanted to be. He woke up every day and made the decision to come to work because it was what he wanted to do, not what he had to do.

But I couldn’t just be a free agent. I didn’t know where to start to develop that sense.

As it turns out, a different piece of advice he gave me later was the missing piece, the building block that earns you that free agency. I was going around in circles worrying about how I, a brand-new programmer of less than 6 months, could contribute to our large and intimidating project. He told me this: “I’m looking for people who will just grab a shovel and get to work. If you can do that, great.”

On the marketing side, I’d spent so much time trying to convince people that I had good ideas that I never bothered to just get things done. It didn’t help that the department didn’t have any clue of what we should be getting done. We just knew we needed big ideas that could recoup our ever-expanding millions in losses.

But in my interactions with the development team, they weren’t interested in ideas. They were interested in execution.

This flipped my whole world upside down. Actually, it had been upside down my whole life, and this flipped it right side up. I realized that I could simply “grab a shovel” and start helping the customers by adding small improvements to the code. I would just dig in and add copy changes in one place, fix small things in another, or add features.

I had needed decent e-mail support as a member of the Marketing team for years. So I set about adding it in myself, and had it done in a matter of a couple of weeks. I asked our lead developer, “This was so easy. Why didn’t we have this sooner?”

His reply was a bit coy: “Because we didn’t have you to build it.”

That was the most liberating feeling in the world, because I was proving value to myself and to anyone who cared to pay attention.

The same fear that kept me from achieving at work now holds me back from contributing to open-source projects: I spend so much time being intimidated or hoping someone will tell me what to do that I would rather wait than start trying to contribute any way I can. I still let this happen too often, but from here, I plan to just dig in, find something to fix, and get it done.

In my new day job, I come in every day and try to grab a shovel and get to work. No one has expressed a lack of knowledge of what to “use me for”. Rather, they know that I am going to be digging, so now the only concern is to make sure that I’m doing so in the right place.

The process isn’t complex: I keep a list of the things I want to get done. I check in with my coworkers and tell them what I want to do for the day. At the end of every day, I know how I feel about what I accomplished. There’s no technique, I just know whether I feel good or bad about a day’s efforts, and so I strive to push a little harder so I can feel good at the end of every day.

I also keep my eyes peeled for places I can get things done and just go for it. I spent so much of my life waiting for permission that it’s a bit jarring to just start doing. But here’s what I learned: if you require permission for everything, I can guarantee you’re going to waste your talents and your life waiting.

So now, I try to take a risk, go out on a limb, and do something good without permission once in a while. It gets my heart racing to know there could be some negative reaction, but it seems like those are the times where I get real traction on the most important things.

If I’m hiring someone, I’d rather pick up someone holding a shovel than someone with a sign that says “I have some great ideas about digging if someone will just give me a chance.”

Stop talking about it. Grab a shovel and get to work. I promise you’ll be happier.

The 5 life-changing lessons I learned from RMU

It’s been nearly 2 weeks since I completed my Ruby Mendicant University course and joined the growing ranks of RMU alumni. I’d hoped to put together my thoughts earlier, but the exhaustion has just worn off.

Being on the extreme “novice” end of accepted students, the experience of RMU was more trying (and tiring) than perhaps some others. But experience or no, it’s pretty intense. On the other side of the crucible, I find myself with several lessons I’d managed to escape until now. I thought they’d be worth sharing.

Lesson 1: When you see opportunities, don’t forget opportunities to help.

For those who aren’t familiar, Gregory Brown is a profoundly skilled, pragmatic, and good-hearted developer who saw a big hole in the education of Ruby developers: too many reach an intermediate level and are unable to make further progress.

I must admit that the conniving marketer in me would have seen a very easy way to extract money from the wallets of these budding developers. But Greg’s instincts being more of the “change the world” variety, he saw an opportunity to experiment with the idea that open source ideas can change the face of education.

People that join RMU are taking advantage of one of the best learning opportunities available in the world of programming, and it’s completely free to participate. I hope with that opportunity comes a sense of a longing to help. You may have earned a spot in the program or alumni status, but it’s humbling to think that the community has bought your way into a first-class education.

I think Greg’s passion for contribution to a larger cause is inspiring and contagious. RMU is slated to launch over 100 open source projects in the next year, and there will be ample opportunity to contribute (financially, by volunteering, or on the projects themselves).

Lesson 2: Find an excuse to take the first bite of the apple.

I don’t know if it’s just me, but I imagine that many new programmers are intimidated by the world around them. It sometimes reminds me of what it feels like on the first day of high school. The projects are big and solve complex problems, other programmers are megageniuses, and established community members seem as if they had been assigned that status by deity. Also, some of them have moustaches.

It was a fellow student, Anita Kuno, who worked with me to crack open a relatively complex project and dissect it. At first it looked impossible, and alone, I would have given up. Anita’s advice was to find something I understood and latch on. I did, and was surprised to find a piece I could get my brain around. Then, working my way outward, I figured out the purpose of the program and got to understand its architecture.

That’s the nature of programming, I think, and RMU was the first to bring that out for me. There’s no reason to be intimidated: it may take a little extra work, but it’s not hard to find a way to get your foot in the door.

Whether facing a difficult problem with a blank sheet of paper or a complex project that seems impenetrable, the big revelation for me was “OK, so I can’t solve this. So what can I solve?” After that, it’s just a matter of time and work before the solution unfolds, and it’s profoundly gratifying.

Lesson 3: A working product comes first.

I’ve heard it pontificated, but RMU drilled this into my brain: Priority 1 is to ship. Before RMU, I had 3 or 4 half-products pushed in a mutant state with no ability for people to interact with them.

During RMU I shipped 2 functioning products. They’re proto-sites with no CSS and limited capability, but I learned an incredibly valuable lesson. You should be in a big hurry to make something that sees the light of day, solves a problem, or makes someone smile.

That’s not to say that sloppy code is OK in shipping products; that’s just douchey, especially to newbies like me. But prettifying beyond the point where someone else could read, interpret, and contribute on your project seems a lot less valuable than getting another awesome feature or product shipped in that same timeframe.

Lesson 4: Do not underestimate the power of community.

RMU is not a solo gig. The people I’ve interacted with have taught me nearly as much as Greg. I believe it’s actually engineered that way.

However, I don’t think even Greg anticipated the quality or quantity of response he’d get from community members. The people that have gathered from around the world actively participate in IRC chats, cross-project contribution, impromptu projects, and even contributing to the core of RMU itself… it’s staggering to me.

It’s also been great to see the alumni stick around to help the incoming group with questions and moral support. The community is the culture and the brand of RMU. Ultimately, this community will surpass Greg as the “owner” of RMU (and he’s no stranger to this concept after running several open source projects).

The idea and pitch for RMU was strong enough to attract a passionate group of people, but it’s the people that bind to each other and to a shared goal. These are friends from all over the globe that I plan to stay in touch with indefinitely. How cool is that?

I don’t know what I’m going to do with the rest of my life, but I hope it leverages the good that a passionate, engaged group of people can do.

Lesson 5: Don’t listen to DHH.

OK, that was a blatant poke in the eye. But DHH and Jason Fried would tell you never to launch a product without a business model, and I imagine they’d tell you never to launch a community initiative without a sustainability model.

But if Greg had waited until he had a solid “business plan” behind RMU, it may never have gotten off the ground, leaving the situation in the world exactly as it is. Or it would be drastically different, scaled down, or less ambitious in its goals.

Instead, RMU has already helped dozens of developers “level up”, and created an incredibly tight and productive global community, with tremendous upward momentum.

Sometimes you just have to take a breath and jump, and figure out how to land safely on the way down.

Greg’s fearlessness in tackling the problems that RMU confronts is inspiring. By nature, I’m a cautious cat. I measure two hundred times and cut once. I would rather not participate than risk rejection or looking stupid. I was almost too afraid to become a father. Why should I be afraid of any of that? Being afraid is not how you change the world.

So I guess that’s the real lesson 5: Not just ignoring, but obliterating fear is the only way I’m going to make a dent in my life or in the world.

Thanks to Greg, Jia, Jordan, and everyone that’s contributed to RMU so far, and I hope to pitch in when and how I can.

So yeah, RMU was valuable for me. It’s indisputably valuable for the community. Hope you’ll help keep it going.

If you don’t like blah blah blah, leave.

Some pretty tough talk from the You The User blog basically states that if your job isn’t making you happy, excited, engaged, challenged, etc., then it’s time to walk out the door.

Most reactions were along the lines of “you must not have kids”, or “that’s fine if your job is a plaything”.

The thing is, Matt (Matthew hates being called Matt, apparently) is in large part correct. So while it does tend to engage the automatic-eye-rolling mechanism in my brain, there’s something valuable here to investigate.

Imagine one semantic tweak to his list. Instead of

If you aren’t being challenged in your job – leave.

I read it as

If you aren’t being challenged in your job – What are you still doing there?

And rather than

If you think you are successful – leave and find something or somewhere where you aren’t. When you become successful again – leave again.

I see

If you think you are successful – why aren’t you looking for somewhere you aren’t?

Then, rather than the “15 commandments of walking out in a huff”, we have some serious points to consider.

This way, if the answer is “I can’t get another job” or “I need this paycheck”, you at least have a graceful way to beg out of the discussion. However, you’re most likely wrong. I don’t meet many people these days who leave a job, never to find another source of income.

This idea of being a free agent was impressed on me by a dear friend. And the idea is career- (and life-) changing, because instead of a wage slave, you’re free to be the absolute best. If you’re undervalued, underused, or underappreciated, you can be confident that it you can go be the best somewhere else. Why settle for less if you don’t have to?

The trick is realizing you don’t have to. Let me share one piece of wisdom that this friend gave to me in my darkest hour:

If you feel like you are trapped in your job, you’re not, and it really is probably time to leave.

Life is too short to not soak up every challenge. And as I’ve come to learn, it’s also too short to spend in a job you hate but fear to lose.

And unless you work for the government, if you hate your job, you’re going to lose it sooner than you think.

So yes, the post may sound like it’s being dictated from an ivory tower, but there’s a solid foundation beneath that tower. My advice is that if you find yourself disagreeing violently, you may want to give some thought to your current situation.

My (hard-won) list of resources for new programmers

There’s a nebulous space in courtship, where “casual” becomes “serious”, and words like “dating” give way to heavier terms like “relationship”. Remember the first time you called someone a “girlfriend” or “boyfriend”? Remember the awkwardness of saying it? It’s like trying on a shirt that doesn’t fit right.

In that same vein, I’m a Ruby programmer. That’s the first time I’ve ever said or written that. It feels just as awkward and forced as the first time my now-wife rolled her eyes at me when I tried to label her as “my girlfriend”.

So as a sort of follow-up of my last 2 posts, I want to express utmost gratitude to the people who do the hard work of remembering the inner turmoil of the newbie and creating help, handholding, and support for the profoundly intimidating process of learning to program. Some of them have been friends and colleagues, but many have helped by publicly sharing their knowledge.

It took me 18 months to assemble this list. I hope that by collecting these resources in one place, someone out there that’s struggling like I did (and still do) will have a shorter path through the inevitable tough parts of learning to program.

As a very green Ruby developer (dabbling with C# and Python), this list is going to be pretty heavily biased. If you want to see anything added, hit me up in the comments or on Twitter and I’ll try to keep the list updated.

Zero Experience

To people with no programming experience, it looks like a black box, and the number of people that holds true for saddens me. Anyone who wants to someday run a business should understand the basic precepts of programming, just like anyone planning to drive across the country should know how the basic components of a car work together.

Learn to Program by Chris Pine: When my friend Jarom showed me this book, it was the start of a new, happier course in my life. I can say without hyperbole: everyone should read this book. You’ll know after a couple of weeks of reading and coding whether it tickles your fancy. The book is free online, but buy a copy. I’ve given two away to people who are happier because of it.

Learn Python the Hard Way: Zed Shaw (@zedshaw) is a controversial figure, because like me, he’s got a big mouth, and his intentions are often misinterpreted (sometimes, I think that’s his actual intention). But there’s no question that he’s given and given to the programming community, and really understands and cares about new programmers.

Python for Non-Programmers: It’s a bit of a cheat to post a list inside a list, but like Ruby, Python is a great language for new programmers, and this is a great place to get started.

Ruby in 20 Minutes: It’s not the best tutorial out there, but it is lovely to look at and should give you a hands-on feel of what it’s like to write code in Ruby.

Humble Little Ruby Book: Jeremy McAnally, who is a dog that wears glasses, wrote a delightful book for Ruby beginners. It’s a great supplement to Chris Pine’s book, and chock full of quirky personality.


I still count myself among the newbies, but that protective cocoon won’t hold me much longer. This is the time when you can write and read straightforward, simple code, and ask questions like “what the heck is a lambda?”

Ruby Koans: The brilliant, incomparable Jim Weirich came up with a way to train semi-new developers on the joys of Test-Driven-Development. The Koans comprise an incredibly clever, fun interactive programming puzzle. I failed to complete the last full exercise, so I need to go back and try again soon.

Ruby Inside: Peter Cooper’s blog is the definitive Ruby news source, and I’ve discovered many, many helpful tips and articles. Plus, Peter is an amazingly cool guy who wrote the book…

Beginning Ruby: From Novice to Professional: This is the book that helped me take the step beyond Ruby’s scripting capabilities. Peter Cooper’s writing style is delightful, and the book came highly recommended, with good reason.

Roadmap for Learning Rails: If nothing else, Wyatt Greene’s Techiferous blog reveals how deep the rabbit hole goes when learning Rails. Most people learn Ruby to get into Rails, and this is a good plan to get your first project built if that’s your goal.

Railscasts: Ryan Bates is the Karl Malone of the screencast world: he just delivers. There are few meaningful subjects he hasn’t yet covered. He’s no-nonsense, giving you just the short-and-sweet facts, then moving on.

Teach me to code: Charles Max Wood is an up-and-comer, with well-done screencasts (as well as podcasts and interviews) for coders of all skill levels. It’s nice to get a different viewpoint, and he tends to inject more depth and personality into the topic at hand than Railscasts.

Pragmatic Programmers: What can be said about PragProg? It’s the best independent tech publishing house on the planet. You can very, very rarely go wrong picking up any book out of their library.

Rails Dispatch: Engine Yard has spun up a great Rails blog with posts and screencasts by Rails luminaries like Yehuda Katz. It’s not always newbie-friendly, but the screencasts are worth a watch.

But who can I ask for help?

The programming world is full of people who, while busy, are happy to help new programmers. Here are a few places to find them:

Google: Google is the king of the hill, and answers about 80% of my questions. Please, don’t bug people with questions that a quick Google search would have turned up. More importantly, don’t be embarrassed to ask questions that Google doesn’t answer for you. Where do you think Google got those answers in the first place? Your question could help future newbies get out of the same jam!

Stack Overflow: Don’t get sucked into the BS “communities” that charge to answer questions. Look for solid, community-driven Q&A sites to get your programming questions answered.

User Groups: Aside from Google, joining a local User Group is the most valuable thing you can do. They’re filled with people who have struggled just like you. Even if you work with other developers, it’s extremely helpful to get outside of your own circle once a month. And someday, you’ll be able to contribute back to the group.

Hackfests: I went to a Hackfest and felt so out of place that I snuck out the back. Don’t do this! Say you’re new and ask if you can pair with someone (likely, this will just be watching them code). Better yet, bring a dinky, sad project of your own and don’t be embarrassed to ask questions about why it’s not working!

Conferences: If you fall in love with programming, be prepared to attend 3 or more conferences a year, and not corporate-driven booth-babe-fests like CES or Macworld. Conferences run by and for the community are so packed with insight, I’m still absorbing lessons from one that I went to 6 months ago.

Mailing Lists: Historically, mailing lists are a nightmarish, labyrinthine mess. But then Google came along and helped them regain sanity. For most projects, you’ll find answers (eventually) in Google Groups.

Freenode IRC: Sooner or later, every programmer has to become familiar with the “crazy old grandpa” of the Internet: IRC. It’s dated, painful to set up and use, and oozing with geek credibility. Hackers love it because it can’t be regulated, controlled, or put out of business, and it’s a key form of communication for many open-source projects. Have a question you want answered? Get to know Freenode.

Rails Mentors: RailsBridge has created a place to learn and eventually, to teach. Pick a topic and find a mentor who will help you, at no cost.

Twitter: I’ve curated what I think is the world’s best list of Twitterers. Rather than list them here, just follow everyone I do and gradually unfollow the people that annoy you. You’ll connect with some astonishingly bright, talented, and helpful people.

Ruby Mendicant University: Lastly, Gregory Brown’s RMU has been like strapping a rocket engine to my learning process. The community has been unlike anything I’ve ever seen. I cannot thank Greg enough for dedicating time to educating people through the hardest phases of learning to program. Please support this endeavor when he’s accepting donations again.

If I’ve missed anything, and I assuredly have, leave a comment below or hit me up on Twitter (I’m @tehviking).

Saying “You Suck, New Programmers” is not helpful.

After posting my last entry, I saw an article (via Jon Baer’s tumblr):

10 Reasons Why People Initially Suck at Programming

I kind of want to take it point by point, because the title and attitude of the article waver between helpful and douchey.

1. Programming isn’t right for everyone? Wrong. Everyone should know how to write code, at least a little. In this computer-driven society, it’s part of knowing how the world works.

2. It takes time. Duh. That’s not particularly helpful.

3. They have the wrong attitude. What? Learning to program is a profoundly humbling activity. The only enemy is the tempting option to quit in frustration at ourselves.

4. Start with the basics. Exactly. Ignoring advanced programming theory and sticking to basics is the only way through without bending your head into a pretzel.

5. Google. Google. Google. Google. 70% of my programming is done via Google. But that leads to its own set of frustrations, as I outlined in my last entry.

6. Plan ahead. Not at first. Advising to plan it out on paper first is solid, but not really for beginners. That’s like TDD: you have to know what you’re planning, and that comes through painful, blind fumbling at first.

7. Google your errors. Yes. Although this kind of an addendum to #4.

8. Study the language & syntax first. Wrong. My problem when starting out was “too many books”. I had all this abstract learning about Ruby, but little hands-on experience. When putting fingers to keyboard, I quickly learned I knew nothing. Everything I really, truly know came from failing, then looking up or asking, then doing it right the 2nd, 3rd, or 50th time.

9. What’s your algorithm? What? Asking a new programmer for an algorithm is just plain mean. But I think there are 2 gems in this bullet: “sleep on it” (works for me) and “you’re making it too complicated” (almost always true!).

10. Don’t wait for someone else to help. Eh… I think a big part of what’s wrong with programming is this “lone wolf” style that produces wanna-be rockstars and cowboy coders. No, you shouldn’t wait on someone to help, but there should absolutely be more resources and people to help new developers.

That’s my point-by-point analysis. I feel strongly about this, but if you disagree, feel free to comment or bitch me out on twitter.