Collective Idea

Collective Idea Logo

Jonathan Pichot

Becoming a Rubyist

By Jonathan Pichot on February 25, 2013 in craftsmanship, patterns, rubyist, and testing

I joined Collective Idea six months ago. In that time, I’ve had the chance to throw myself into a new language. Just like learning a new spoken language, learning a new programming language means learning a new way of thinking. Here are some of my reflections on becoming a Rubyist.

Coding is Human

My initial attraction to Ruby was the community’s emphasis on clear, human-readable code. You can only write so many nested foreach loops in PHP before you begin to look for a more succinct and rational language. When I began exploring Ruby, I was struck by Matz’s human-centered philsophy of increasing progammer happiness, and of the principle of least surprise. I was also itching to program in an Object-Oriented language. (Though PHP does have objects, the framework I worked in previously is almost exclusively procedural.) Even now, when I write an each loop in Ruby, I can’t help enjoying how nice it looks.

Reading Russ Olsen’s excellect Eloquent Ruby, I realized that programming could be an aesthetic exprience as well as a logical one. Steve Klabnik has spoken on these themes, putting programming in relation to literature and philsophy. It’s very typical when talking to other Rubyists to hear code described as ‘beautiful’ or ‘clever’. For me, coming to understand programming in these terms connects it with other human pursuits. After all, a community that produced _why must understand art as well as engineering.

Patterns are (educated) Opinions

I learned quickly after joining Collective Idea that there is rarely one right answer to a programming problem. It’s been revealing to hear the differing opinions in the office over everything from Ruby conventions to Rails patterns. Simply listening to these conversations has made me a better programmer. It’s also made me want to take the time to develop my own well-supported opinions.

The freedom that comes from not having one answer (and a language that lets you open any class!) is incredibly empowering, but it can also be paralyzing. When I encounter decisions that have architectural implications, I’m still uncertain on how best to move forward. I’m afraid of making a decision that I regret later. I don’t yet have the benefit of experience to help me weigh the pros and cons of any one approach.

I encountered my first significant technical debt a few months after starting. I was working on an app that functions primarily as a glue between several different services. On certain actions, it makes calls to at least 3 separate services, having to coordinate and process the responses from each. My controller had gotten out of hand, and I had mixed up some business logic in with my models. My tests were straining, edge cases were breaking the app, and I knew I was Doing It Wrong™.

Discussing with colleagues how best to move forward, it was suggested I try a pattern one of them had had recently written about. Called the Interactor pattern, it seperated all my interactions with outside services into a seperate class. It was beautiful, it just felt better, and my tests agreed.

Testing is Craft

You can’t spend much time working in Ruby without hearing about the importance of testing. At first, I had a typical reaction, wondering how writing more code would make me more productive. The more I did, though, the more I realized how good tests lead you to write better code. My first tests, of course, weren’t very good. But they got better. And after watching Geoffrey Grosenbach excellent series on RSpec (he’s recently updated it for RSpec 2), I began to fully grasp isolation and why small methods are awesome.

I also began to understand what the industry buzzword around ‘craftsmanship’ really means. I’ve worked in software long enough to know firsthand how easy it is for projects to underperform and go over budget. Building software is unlike building almost anything else. It’s essentially collaborative logic-making. Because its product is incredibly malliable, it needs clear and specific guidelines. Becoming a ‘software craftsperson’ is having the humility to realize that one person cannot fully conceptualize the complexity of the entire software stack. We write tests because we know we’ll make mistakes, because we’ll have to maintain what we’ve built, and because we don’t know who might have to work with our code in the future. This may be old news to TDD diehards, but that doesn’t make the idea any less powerful.

In short, becoming a Rubyist has been one of the most rewarding processes in my career. It’s made me appreciate what I do on an aesthetic level, it’s brought me a creative freedom I didn’t expect from programming, and it’s given me the tools to be proud of what I build.

By Jonathan Pichot on February 25, 2013 in craftsmanship, patterns, rubyist, and testing

4 Comments

  1. Daniil

    Daniil February 26, 2013 http://www.daniil.ca

    As someone who is in the middle of confusing yet exciting effort to change careers once again and finally get to work with Ruby full time (which means a lot of self-learning on top of current unfulfilled FT job) I just wanted to thank you for this article! You put why Ruby is such a beautiful language so eloquently and the feeling of doing something right in the language that makes sense. But you also mentioned the human element, that it’s ok to feel lost at times because it’s for those moment of clarity that it’s worth persevering and getting better.

    Thank you :)

  2. Fred

    Fred February 27, 2013 http://runtime-era.blogspot.com/

    I used to say that Python is my favorite programming language, but after a few months of Ruby, I think Python will have to take a close second. I completely agree that the language is just pure heaven to read.

  3. Harisankar P S

    Harisankar P S March 03, 2013 http://rubykitchen.in

    +1 for the way you have described your experience with Ruby. I personally felt that Ruby’s programmer friendly nature makes you look into things more important in software development – such as design patterns and architecture.

  4. Mike Joe

    Mike Joe August 13, 2013 http://dev.cobub.com/

    Ruby is one of the most understandable programming languages. It is just heaven on earth. An adept programmer could do wonders with it and not be bored.

Post a Comment

Contact Us

Find us on Google Maps
Collective Idea
44 East 8th Street, Suite 410
Holland, Michigan 49423 USA 42.790334-86.105251

Follow us on the Interwebs

We are currently available for medium and long term projects. Please get in touch if we can be of service.