Last night I pushed my first Rails app to production – you can find it at (oops! It looks like all the traffic has crashed the app. Hiding the URL for now) Here’s what it looks like.
It’s like a super stripped down version of Twitter – you can create an account and post statuses. It uses Twitter Bootstrap for some basic styling and Gravatars for profile pics. One obvious area for improvement (among many) is that right now, you can post a status as any user (not just yourself) and edit anyone’s status.
Despite this issue, I’m still very proud of it. Deploying the app to Heroku was a very satisfying moment and feels like a real milestone in my quest to learn how to code. I have a long way to go, but I thought I’d stop and share some lessons I’ve learned so far as a business guy venturing into web development.
Note: My friend Bevan is starting a Ruby on Rails Newbies Meetup in SF if you’re interesting in connecting in meatspace.
1) Have a learning plan
I signed up for Treehouse (referral link) in late December and have been going through their modules for the past 6 weeks . You can see my progress here. Treehouse was recommended to me by a non-technical friend (thanks Tony!) who found it very accessible and I completely agree.
Having a program or system, especially an interactive one that’s designed for newbies, is incredibly comforting. I know I can work my way through the modules and learn the basics without missing something important or getting too stuck. Obviously there are many options beyond Treehouse. CodeSchool and Lynda are paid subscription based models, and the Ruby on Rails Tutorial are other learning plans that would be worth checking out.
2) Setup is a big hurdle and something to be proud of
When I tried to learn Rails a few years ago, I struggled with correctly configuring Rails and Ruby. It was frustrating and embarrassing to be stymied by such a basic issue that I didn’t feel comfortable asking for help. That was a mistake. I am comforted by Michale Hartle (author of Ruby on Rails Tutorial) when he talks about getting up and running:
There is quite a bit of overhead here, especially if you don’t have extensive programming experience, so don’t get discouraged if it takes a while to get started. It’s not just you; every developer goes through it (often more than once), but rest assured that the effort will be richly rewarded.
So don’t be discouraged by the first hurdle of just getting setup. When you finally get it done, celebrate it – it’s a worthy accomplishment for a newbie.
3) Enjoy the grind
If I’ve learned one thing about building habits from the class I taught on The Science of Willpower, Habits and Behavior Change, it’s that rewards are an essential part of developing a habit. Treehouse naturally does this with badges and really leverages variable rewards by randomly showing a funny video every few modules as a reward.
But learning code is never perfect. When doing Treehouse exercises, I would get a weird error message that didn’t appear in the video and then hunt around for sometimes up to an hour until I figured out that I had missed a comma or a colon, or found a StackExchange post that fixed the issue.
I’ve been trying to reframe bug fixing from “wasted time” to “the grind towards improvement”, akin to the last few reps in a workout. Now, each time I figure out an issue I’ll literally stand up, pump my fists and shout:
“Yes! I beat this thing. No bug can hold me down!” Sometimes I’d eat a piece of chocolate too, to really reinforce that feeling of success and reward. You laugh but how the hell do you think we get killer whales to do flips at SeaWorld? It’s all about the right incentives.
4) Consistent effort really pays off
I estimate I’ve spent 20 hours working on various Treehouse modules (6 weeks x 5 days a week x 40mins/day). I started with building a simple website, then went through HTML and CSS foundations, then basic programming concepts, and finally building a simple Rails app. If you wanted to cut to the chase, you could probably start with the Rails app and speed things up quite a bit.
One of the nice things about a learning plan is that someone who is far more knowledgeable than you, has chunked the work of learning Rails into reasonable sections. I already wake up early to workout, so I just started a Lift habit for “working on secret project” and started waking up a little earlier each morning.
Over 6 weeks, I checked into that Lift habit 30 times and worked for about 40 mins each session. You could power through all 20 hours over like a weekend, but I actually think that the consistent effort is better because 1) it helps you build the long-term habit and 2) sleeping (in-between modules) helps you retain memories.
5) It’s ok to not know what you’re doing and just copy code at first
Sometimes I would feel weird about just copying and pasting code according to the Treehouse video, but I’ve learned to get over it. I know some people feel the need to research every last command, concept and piece of jargon that they don’t understand, but at least for me, that was counter productive.
You usually have to type a command or piece of code (ex: git push origin master) in more than once and by doing it again and again, you start to figure out what it is and what it means. I’ve realized that repetition leads to comfort, and comfort leads to understanding and understanding leads to mastery. This is something I learned from gymnastics. While it’s still scary, I’ve become ok with just typing in commands while knowing that I’ll eventually understand what it all means.
6) We are all standing on the shoulders of giants
Part of why Rails is so powerful, but also mysterious, is that it does so much work “for you”. The ability to use scaffolding to generate many of the major pieces of an application is amazing, but sometimes it feels like magic. Like driving a car at 200 mph – you can get where you need to go faster, but crashes are a greater concern.
Add to that the whole idea of gems. Treehouse had us using simple_form – a relatively innocuous gem for making our forms nicer, but also devise, which creates all kinds of user related functionality (creating accounts, resetting passwords) that I would never be able to do on my own. But that’s just the way this stuff works.
I’ve come to accept this as well. While I have an urge to truly “master the fundamentals” and “do it all from scratch”, how far does that take you? As Jean-Baptise explains in his wonderful essay “Dizzying but invisible depth” the more you understand about technology, the more you that even things that seem simple, like pressing a key on your keyboard, are “not quite that simple.” A great line:
Once you start to understand how our modern devices work and how they’re created, it’s impossible to not be dizzy about the depth of everything that’s involved, and to not be in awe about the fact that they work at all, when Murphy’s law says that they simply shouldn’t possibly work.
If you are strict about starting from “first principles”, you may have a long time to go before you’re even allowed to do so much as type into a text editor, much less coding a web application. Learning to harness to power of technology without fully understanding how every part works is an important and necessary skill – especially if you’re a business guy poking your head into the world of web dev.
7) It’s ok to mix in “window dressing” along with actual functionality
In building this basic app, Treehouse had us integrate Twitter Bootstrap and use some of the special CSS classes to make our stuff look sleek and modern. This wasn’t absolutely necessary, but boy does it make me feel better about my app. Having that pretty fixed nag bar and shiny buttons for posting status updates motivates me to keep working on the app.
Obviously the ease of Bootstrap has its own challenges (see previous lesson about standing on the shoulders of giants) but overall, nicer design doesn’t hurt anyone and makes the web a little more friendly for everyone. So if it motivates you to see your app “looking good”, don’t be ashamed to pursue some window dressing outside of learning “pure” functionality in web development.
8) Learn to get comfortable reading documentation
This lesson is one I’m still trying to learn. Documentation scares me. I just went and looked at the Devise documentation on Github and found a sample paragraph:
Since Devise is an engine, all its views are packaged inside the gem. These views will help you get started, but after some time you may want to change them. If this is the case, you just need to invoke the following generator, and it will copy all views to your application:
rails generate devise:views
What’s scary is really that I don’t understand a lot of what it’s saying. What does it mean for Devise to be an engine? As a opposed to what? How do views get packed inside a gem? What does it mean to copy “all views” to my application?
I realize that like copying code you don’t understand, it’s ok to read the documentation and not understand everything. If I have a problem with Devise, I can still hunt around and see if I can find what I’m looking for. Treehouse does a good job of showing us examples of how we might look at documentation to figure things out (rather than just telling us what to punch into terminal). So yeah, good documentation is a lifesaver to newbies like me, even when it still scares me.
Where to go from here
So now that I have this very basic app up, what’s next?
I have a few options. Treehouse started me immediately on learning Ruby basics and I might do that. I could also skip it and jump right into building social features for my web app with their advanced Rails tutorial.
When I think about mastering a skill, I know that getting good fundamentals (which you can skip early on) will pay dividends later. So I’m considering going through the Ruby on Rails Tutorial with Michael Hartl, or doing the entire project again, but documenting every step of the process carefully and actually understanding things this time.
I’d love to hear from experienced web developers on what they advise. And if you have any questions about my experience, please ask in the comments!