Please watch this video.

Greg Brown, creator of several open-source projects and the free online Ruby Mendicant University that I participate in, put together an incredibly thoughtful video addressing my most recent post, point by point.

Thank you Greg, it’s incredibly enlightening. I still plan to collect the best of the responses to that post, but by and large, this pretty much covers it.

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.

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).

Why it sucks to be a new programmer (and how you can fix it)


About 18 months ago, I had a life-altering conversation with someone who showed me the magic-wand-like powers of Object-Oriented-Programming, and it didn’t take very long for me to fall madly in love with writing code and making things. It was like writing, but then making the words literally dance.

Since then, it’s often been a bit of an uphill battle, requiring all my fortitude to stay on the learner’s path instead of retreating into places where I can feel competent again.

While I now feel like I’ve made it across the most difficult chasm, I think we leave a lot of people behind somewhere along the way, or intimidate them out of starting at all.

I believe this is a cultural problem that is going to start repairing itself as programming becomes more mainstream, but there are things you and I can do right now to help.

From a newbie’s perspective, here are 3 reasons why programming culture is frightening, and some ways to make the culture more welcoming:

1. No one seems to be able to remember the embarrassment of being a newcomer.

It’s not that experienced coders don’t care, it’s that most people either live and breathe code, or they have zero interest in it. I think most programmers and non-programmers assume that if someone has an interest in coding, they started in junior high, and were fully onboarded by a CS program in college.

That’s no longer true, and it shouldn’t be a surprise that many are now cross-training from backgrounds of all kinds, especially those that have a lot of contact with programmers like designers, writers, and entrepreneurs.

Sadly, it’s still somewhat rare for someone to start learning to code out of the blue. So those of us that are new are far enough between that it can be easy to feel like the dumb kid in class, and that it’s best to keep quiet lest we be found out.

When I have asked questions, I’ve often immediately regretted it, feeling like an idiot. I ask the wrong question or in the wrong way, and the experience is deeply embarrassing.

I believe if every experienced programmer dedicated one blog post a month to a “newbie question”, or one evening to seek out someone new and answer their questions, we’d have a profoundly different culture.

Most importantly, when stupid questions are asked, be patient and perhaps share that you were once where they are now. Help them undertand that there really isn’t anything to be embarrassed about, and if asking the wrong question exposes some underlying misunderstanding, take the time to correct it.

2. Newbies can’t understand a word you’re saying.

Programming, more so than almost any other profession, is almost completely opaque to outsiders, due to a high level of insider jargon, even for people who work with computers. A year and a half on, I often run across conversations that make my head spin.

Generally, programmers are looking for something interesting. And many, in looking for new tools, technologies, or boundaries to push, don’t realize how intimidating it is for new programmers to see or hear these conversations whizzing by six or seven levels above them.

I’m convinced that this fortress of jargon is one of the reasons there are few women in programming. It’s great for guys: you suffer the paddlings of stupidity for a while, and then make it into the fraternity of coders.

But this “red rover” mentality doesn’t jibe with the mental models of most women I know, and it requires a very special kind of adventurer to be willing to defy this tradition, like the girls on my high school wrestling team.

This is a tricky one, because speaking in programmer’s jargon is a huge timesaver. But every once in a while, remember that many people don’t know what you’re talking about, and take a moment to explain, include a footnote, or even link to a Wikipedia article about one of the arcane things you’re discussing.

3. The truth is out there (somewhere), but so are a lot of other things.

One of the most frustrating things as a newbie is that it takes an incredibly long time to find answers to simple questions. I wind up using a hodgepodge of various methods found via Google to solve almost every problem.

Often, I’ll get so stuck that I get profoundly discouraged, feeling as if I’ll never catch up and acquire the knowledge to be decent at this. If only there were someone to ask!

Nine times out of ten, I’ll eventually stumble on the correct answer and the victory is that much sweeter. But most of my struggles are small enough to an experienced developer that having someone to ask questions would have accelerated my learning dramatically.

Ultimately, “shut up and code” is a great (and sometimes the only) way to brute-force through problems. But for many, having someone (preferably multiple someones) around to ask can make the difference between giving up and seeing it through.

Be that someone. Be the one to welcome new programmers (and entice non-programmers) to the joys of coding. Join a local Users Group. Jump into online discussions. Put a note on your website that you’re happy to take questions, even if you can’t answer them all.

You’ll enrich the lives of others, because programming, as you know, is an incredibly rewarding creative pursuit, and having more people at the party is good for everyone.

Who knows… maybe that new developer will wander into Hollywood and help make a movie that doesn’t portray programming in a completely ridiculous fashion. And in the end, isn’t that all programmers are asking for?