Reflections on Rails

Sixteen years ago I learned HTML from HTML For Dummies — I became a webmaster. Geocities and Xoom became my playgrounds, and web-rings were our only faux-SEO. A classmate made fun of me for organizing my content with tables instead of frames.

Since then, however, web design and development more-or-less blew past me while I pursued other interests and then eventually (somehow, inexplicably) built a career in Human Resources. Sure, every single job benefited from what little HTML and CSS I knew, I became fairly decent with WordPress, and I had a passing familiarity with Bootstrap.

However, for the most part, I was fairly mystified by how, say, Twitter and Instagram were built, and I basically just knew HTML5 as “that thing killing off Flash” (a medium I knew fairly well from my instructional designer days).

About a month ago I decided to change all that: to finally learn what it meant to be a full-stack developer.

Full disclosure: I also wanted to prove a hiring manager wrong — the one who passed me over for a job because he didn’t think I could comprehend basic Salesforce development. I was, after all, from HR (cue a thousand wailing employees).

Roughly four or five weeks into this and I finally have an MVP built with Ruby on Rails. And it’s been an immense learning experience. I want to share some scattered thoughts on this trip as a record for me and potentially a guide for other aspiring developers. But first: why Rails?

I have to confess I actually want/ed to learn Python and Django. I feel more pythony, if that’s a thing. Looking back, I got decently far thanks to some tutorials from Jessica McKellar. I joined MeetUp groups. Got ready to settle in. Then totally stalled out.

I’m not sure what did me in, but I do remember struggling with routing and the pains of developing on Windows. I wish someone had just told me, Get a virtual IDE: here’s what that is and how to set one up. Actually, years earlier an attempt at Ruby failed for the same reason; that is, I couldn’t get everything properly installed and configured in Windows and didn’t, at that time at least, have any facility with Ubuntu. I think most experienced programmers vastly overestimate what it takes for total greenhorns to even get off the ground.

So, onto PHP. This is a language that had really dirty connotations for me. For years my non-technical understanding was that PHP is very easy to learn, but very easy to botch, and very much being left behind. I heard this had changed, however, and my early stabs at PHP made good sense to me.

Unfortunately, for reasons I don’t remember, my PHP and Zend project was scraped as well. I felt pretty sure coding wasn’t for me, that all the projects in my head would never materialized, and I’d be doomed to a life of troubleshooting WordPress plug-ins.

Then, lo and behold, the hero I didn’t deserve emerged from the rubble of Ruby gems strewn around me: Michael Hartl. If anyone — grandma, street bum, McDonald’s burger-flipper, HR infidel — ever asks about learning Ruby on Rails, the only real answer is Hartl’s Ruby on Rails Tutorial
(hereafter RRT).

I actually looked at quite a few other tutorials, including books and video courses. I won’t name them, because I respect their attempts, but I absolutely cannot recommend Hartl’s work enough. Some say you should start with something even more basic than RRT, or that you should be a Ruby guru before going to Rails.

Maybe, maybe not. Personally, RRT was perfect for me and I went in knowing neither Ruby nor Rails, let alone git and the other vast bodies of knowledge that I’ve discovered go along with being a real developer.

Part of my background is in training and I can really respect how difficult it is to do what Hartl’s accomplished with RRT. The two big keys for me:

  1. RRT is opinionated. Unless you’re also a newbie, you cannot possibly understand how bewildering it is to see coders arguing online. We just have no context for what y’all are talking about, and as a result the new learner is left with dozens of choices that they’re not at all equipped to make. Often, in my opinion, these choices are also totally irrelevant to the beginner because they’re addressing concerns we just don’t have; e.g. scaling and concurrency, which I get is important, but I really just wanted to get something online.
    Hartl, on the other hand, basically says, There are lots of ways to do this. I recommend this one way. Starting with: sign up for Cloud9. Seriously, just do it and avoid the thousands of headaches that you’ll encounter when developing on your local machine. (Particularly if said machine is, like mine, running Windows 7.)
  2. RRT is detailed. Even now, with ever-so-slightly more experience under my belt, I look at other tutorials and am amazed at how much is glossed over; e.g. “Welcome to our tutorial! First, generate a model and some views. Got it? OK, let’s try using an external API…”
    RRT, to me, really strikes a great balance between giving you what you need to know, when you need to know it, without getting lost in the weeds or flying by too fast. For example, whereas others might say, “Start by cloning our training repo…” Hartl assumes (I think correctly) that the target audience for his book very likely knows very little about git and versioning, so it’s very helpful to start with things like, You see, there’s this site called Bitbucket…

I assume Michael Hartl is cutting me a check right now, but let’s move on to my scatterbrained list of just the few things I’ve been learning. I hope this is amusing to developers and helpful to aspiring developers.

  1. Again, I cannot stress again how helpful it’s been to have Cloud9. My one complaint is that the memory (500 megs) you get on the free plan seems so insufficient that it probably frustrates more people than it helps; despite being unemployed, I felt I had to pay to upgrade.
  2. One of the best (and most frustrating decisions) I made was to use Hartl’s tutorial, but write my own app. Meaning, I didn’t build his Twitter clone, but rather immediately started working on one of the sites I wanted to build — in my case, something better than Google Sheets or Excel to manage my job search (including jobs I wanted to apply for and jobs I’d already applied for, but wanted to track the status). This choice forced me to really understand what Hartl was teaching rather than just copy the code verbatim. My approach worked well until the very end (chapter 11 or 12) when Hartl’s app and my app had diverged in functionality enough that I had to strike out on my own — jump out of the nest a little early, so to speak.
  3. Routing is really, really hard for me. I still struggle with it, and I’m not completely sure why. If you are new like me, trust me when I say rake routes is your friend.
  4. You know who else should be your best friend? A debugger. I have no real analog for this in my line of work, so it really did take me some learning to be able to read and interpret error messages. Perhaps I’m just thickheaded, but I often found myself doing the following: Hmm, the debugger says it had trouble routing this. I better fiddle with my model, and then tweak my controller, and I should certainly futz with my view. Oh, huh, it turns out it was a routing problem. Even yesterday the damn thing was telling me there was an error on line 105 and I was off furiously poking at line 125 instead. So, all that to say: trust your debugger — he’ll lie or obfuscate sometimes, but not nearly as much as you’ll do to yourself.
  5. Code is scary. I spend a lot of time trying not to be afraid of my own code. By this I mean that sometimes things are working and you’re not sure why, so you don’t want to touch them. This is, of course, inimical to learning. It’s so, so easy for me to see now how ‘technical debt’ accrues, and potentially very, very quickly. If there are black boxes in your app — things doing things in ways you don’t understand, or things that could be doing things that you just don’t use — you have to open them all up and wrestle with them. (For me right now, it’s a folder called Helpers. Why are you there? I know you can, uh, help me and my app, but pretty please can I just play with jQuery instead?)
  6. For what it’s worth, a few other things that seem harder-than-they-should-be for me personally: nested resources, git, passing params up, down ,and sideways, and maybe the asset pipeline to some extent. Oh, and AJAX, bloody hell.
  7. Every single hour spent coding is a reminder of everything I don’t understand, and managing this frustration is not inconsequential. Focus. Pick a feature. Code it. Pick a bug. Fix it. Learn that one thing, and then move on. Bouncing all over the place trying to absorb syntax by osmosis is very, very unhelpful. Also unhelpful: believing that code from 2010 is still automatically workable in 2015. StackOverflow is a minefield of incorrect code, inefficient code, outdated code… But of course, it’s been totally invaluable for learning.
  8. Test-driven development (TDD) is hard and annoying and I feel huge amounts of guilt over how few tests I have, even though I clearly see the benefits. I’m a little terrified to type in bundle exec rake test right now.
  9. There’s so much more to a dynamic site than I ever would’ve expected. I was so used to the simplicity of Open Notepad++, write stuff, save, upload via FTP, voila. Now I more fully understand the specialization in this industry; I get now why you’d have an entire person or team dedicated just to deployment. But thanks to Hartl and Mother Necessity, I have at this point at least scratched the surface of things like Mandrill, Cloudflare, Heap, and Heroku (and spent hours comparing the latter to offerings from Google, Amazon, and Microsoft). I enjoy being able to read Hacker News in a more informed way and truly get, for example, why something like Codeship exists.
  10. Speaking of deployment, I just have way more respect now for what this involves. I’ve dealt with a lot of SaaS vendors and will admit to being a little hard on them in the past when they had to take us offline for a few hours in order to upgrade/patch. Now, seeing what it takes to get my absolutely puny app online, I can understand why a massive enterprise cloud app might need to go dark and why all those same vendors have moved, or are trying, to continuous deployment models.
  11. Don’t use SQLite in dev and PostgreSQL in production. I’m not totally clear on why Hartl recommended this, but I really regret it now. SQL in general is still a bit of a black box (see #5 above), and this is exacerbated when running into differences between databases.
  12. Problem-solving in programming is absolutely the best. It’s so satisfying in ways that certainly parallel problem-solving in other domains, yet feels like its own thing. That said, I am still learning and re-learning that sometimes the best way to solve something is to walk away for a day or two. I’ll admit that I almost gave up this entire endeavor a couple times when I felt I’d hit an insurmountable wall. Coding is just not for me. Your brain isn’t built for this. Find a new hobby. No one’s making you get this dumb MVP online. These feelings are probably really natural, but they’re really tough for beginners.

That, in mini-novella form, is a small part of what I’ve learned over the last 4–5 weeks. So far to go still, but it’s been absolutely worth it to this point. Now off to see if my 3rd attempt at implementing Papertrail will be successful.

TL;DR — I learned a lot of Rails in a month. I still don’t know much, but I at least got a site up.

--

--

--

Mission-driven professional interested in organizational development, imaginative leadership, talent management, social impact, and the #Cynefin framework.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Kevin Cole

Kevin Cole

Mission-driven professional interested in organizational development, imaginative leadership, talent management, social impact, and the #Cynefin framework.

More from Medium

Ruby on Rails Get Query Filter

Why use Ruby and ActiveRecord and?

How normally is done

Avoiding Active Record Disorientation

Key Benefits Of Choosing Ruby On Rails For Your Project