Rails makes you pragmatic

Published: 2013-08-25

Tagged: rails

My adventure with RoR started as an intern at AD:60 and it was fun. Pretty soon afterwards I was promoted to junior web dev and I did Rails, more Rails and only Rails.

At that point I had minimal programming experience but I did know how to wrap my mind around a problem, fish Stack Overflow and reference manuals for the right (or almost right) functions or libraries, look at existing project code, type out a solution, test it out, and finally push it to the repository.

Since then I've had the chance to read a few thousand lines of code and type out quite a few of my own. What's more important - I had the chance... no! The pleasure! Yes, the pleasure to go back and rewrite my own code when it started misbehaving. I was able to see how hard it is to maintain bad code, because damn it, even I had trouble untangling it. And we're talking about code that was barely four weeks old. That's how fast code beings to rot.

I quickly found and read The Pragmatic Programmer and it caused quite a stir, yes sir it did. First, it gave me an idea of what good code should look like. Second, it showed me how much working with Rails already taught me. Let's start at the end.

Rails MVC and OOP

We all know and love the MVC way of doing things. I can't really imagine doing any medium or large web-development project without using it as a guide. It takes a while to get used to if you are new to this game but once you get it, it becomes so ingrained that you don't even think about it.

Then you go a step further. You get into the whole fat model - skinny controller thing. Your methods become shorter and shorter. You divide and conquer more and more. You make your code more and more readable and you start to have a knack for naming methods. Gone are the days of method names over 30 or even 40 characters long. Gone are the terrible times of methods over 10-15 lines high.

On a deeper level, your mind is registering how these abstract things - these objects - interact. You start churning out modules and you being to extend things. You don't even think about this, but you're doing it because you saw it in someone else's code and you think it's cool. Funny. The more you learn, the less code you actually end up writing.

Even after a fairly short (but intense) time spent working with Rails I found myself trying to write modular, contractual and DRY code. Rails made me do it. That and being able to work with a bunch of truly awesome people. I'm at that wonderful spot where I'm good enough to derive pleasure from coding, but bad enough to see a billion ways to improve, which is immensely motivating.

The Pragmatic Programmer

This is quite a popular book and many programmers will have at least heard of it by now. I remember trying to go through it last summer but my almost complete lack of experience stopped me about half way through. How can you comprehend things such as orthogonality, modularity, or contracts if the largest program you ever wrote had all of 50 lines of code?

After getting my foot in the door and getting a few months of experience, I went back to it and charged through it, nodding my head and thinking of all the places I've already seen some of the knowledge applied. I also clenched my teeth when, quite often, I remembered places where I broke some of these guidelines. Of course, you can never adhere to anything too strictly, but if I were aware of some of these ideas back in April or May, I may have ended up writing anywhere between half a thousand to a thousand lines of code less than I did. I would have created more stand-alone modules with smaller functions for easier maintenance and unit testing.

Writing good code is hard. In my subjective experience it requires a much broader overview of a project at step 1 - you have to be able to see, at least vaguely, how all the parts of a project will work together. It's totally different than just throwing a bunch of code at a problem, making a procedural solution with a few dozen edits. It feels kind of like setting a new physical exercise goal. It hurts. But you start to see results and you like them.

I started working on a tiny nginx log to d3js graph parser and rewrote it almost completely after reading the Pragmatic Programmer. Making any changes to it is a dozen times easier because of how things are divided. And I have tests that show me if a change I made breaks things. When I look back at another piece of parsing code I wrote back in January, I recoil, but I'm soothed by the fact that I will feel the same thing about my current code in a few months. Ain't no way but up.

Conclusion

It's quite simple really. The more experience you get the better you are and the more you begin to enjoy whatever it is you're doing. Or - the best way to learn to code is to just code. Do it for at least four hours a day. Become a better craftsman. Make better code.

P.S It's hard to convey in words the sight of jagged black swallowing up a blood red sky. Just fly to Iceland, make sure to land at night.