Finding flow: learning Ruby on the job

I’d graduated from university with a degree I loved but the prospect of finding a stimulating job, let alone a career, was slim. I wasn’t sure where my life was leading. I was stuck.

This podcast on design thinking talks about two distinct challenges in everyday life. Dave Evans, who teaches Designing Your Life at Stanford University, calls these challenges “tame” and “wicked”: tame challenges are solvable, whereas wicked challenges are mutable.

It was a wicked problem I faced; wicked, but actionable. So I began to learn to program. I attended a RailsGirls event, began online tutorials, and then attended my first RailsCamp. Not too long after, I was hired by The Conversation as a junior developer to learn Ruby on the job. Over a year later, it’s past time to reflect on my early months in development.

The practicalities

Before walking into the office for my first day, I wanted to make sure I understood a few things to take the pressure off those first few weeks. Not necessarily programming, but understanding day to day practices that encourages the development day to “flow”.

Command line

The Command Line Interface, or console, is your terminal window where you type commands. The more familiar I became with my command line, the more I could focus on programming instead of worrying about remembering the command to type into console.

Git

Git is a distributed version control system, which tracks code changes made by multiple users over time. Give it a go here. I used this frequently when trying to understand branches, repositories and multiple user collaboration.

Editor

Choosing an editor is an individual decision. I use Atom as it is what I’ve always used and I’m most familiar with it. In the same vein as understanding CLI and git, understanding your editor and its tools is a great way to gain confidence.

Other popular editors are Sublime, RubyMine, Vim and Emacs.

The necessities

Questioning confidence

I’m not a confident programmer (yet). But I am confident in my work environment, in my ability to find something in the codebase, I know how to ask questions and, most importantly of all, I know that it’s ok to make a mistake.

Mistakes happen to everyone, no matter how high their skill. Once I realised that not everything I wrote had to be exactly correct the first time, I got the confidence to play around more and explore other avenues to achieve the same result. I often ask my colleagues: “Why is this piece of code written this way?” More often than not, the reply is: “I’ve done this 10 times, and I just know that this way is better”.

Removing such unnecessary pressure was a relief. Thinking that you’ve got to write something correctly the first time is unsustainable and impractical. My colleagues know this, because they’ve done it 10 times. Code is a lot like archaeology. I often find myself weaving through files and methods before finding the solution to a problem. Learning takes time; so does confidence.

I had no prior experience working in technology, but I studied Ancient Greek for a few years. Learning a “dead” language is not too dissimilar to learning to program. Both require application, consistency and revision. And hard work. Lots of hard work. I applied the same practices to learning to program as I did when I was learning Greek.

I keep a running doc that contains everything from notes of idiosyncrasies within our code base, to what to run in the console if assets aren’t compiling properly. In a separate doc are more general notes. If I hear an unfamiliar phrase, then that goes in the doc. Later, I consult with Google or ask a colleague if I’m still unsure.

Asking questions is hard. Identifying the right question takes a surprising degree of skill and vocabulary. It helps if I break it down into a few stages. I try to state: what I’m doing; why I’m doing it; what I’ve already tried; what I don’t understand and what I do understand. Don’t be afraid to say you don’t know what something means. Asking a question often leads to pairing or can be quickly resolved by posting a code snippet in Slack.

Establish routine

In my first few weeks I had a few key tasks I did everyday or week. These became a routine I could rely on to explore and familiarise myself with the codebase, which helped to build up a solid workflow foundation. It also helped me identify a balance between independent learning, pair programming and information processing that I adhere to each day.

One of the earliest routines I established was running a rake task. I had to understand: what is a rake task and how do you run it; what is bundler and why is it important, how git works with more than one person working on a project, and how the code review process worked for the team. Although familiar with many of these things independently, working that knowledge into a team environment is a whole other challenge.

Establishing a routine gave me familiarity and confidence within both the team and the codebase; I slowly began to have more confidence when pairing on small, self-contained projects within the code base that stuck to a standard Model-View-Controller and Create, Read, Update, Destroy, flavour of development.

Looking back, I realise how much of a benefit this was. Our code base was (and still is) huge to me. Implementing standard programming practices I was familiar with, having done some online tutorials, but within a large codebase being worked on by multiple team members gave me valuable insight and confidence in the early months. The more familiar I became with different sections of the code base from such small tasks meant I was later able to pick up more complex cards within the same area.

Goals

Defining goals early on was surprisingly difficult. I wasn’t sure what was realistic. I observed day-to-day interactions between colleagues and thought about how I could reach a similar level of skill and confidence. I was reading every pull request submitted by my colleagues (although I certainly didn’t understand everything I read). I wanted to be comfortable writing articulate and considerate reviews, to have informed discussions about the decisions they’d made, and to contribute my own opinions.

Identifying practices my colleagues did with ease each day allowed me to articulate a specific goal. My first goal was to be able to confidently review, and subsequently merge, a variety of pull requests.

This can be: “I tried this out and it works as expected”, or “I tried this, but noticed that the email field accepted invalid values”. I often hear juniors say they feel as though they can be wearing on their colleagues, that they’re distracting and demanding. By throwing myself into the review process I felt more comfortable in my role as a junior: I can do this, I was contributing to the daily-workflow, helping the team prepare to ship software to the live site.

Be brave

A strong theme in this post has been: I don’t know. Learning to program does not follow a straight trajectory, or adhere to a set of rules. If you know and understand one line of code, that doesn’t mean the next line will make any sense to you. And that’s ok. Programming as a junior isn’t all about solving the problem or writing the code. It’s also important getting comfortable with the idea and process of doing so.

Here are a few useful links that have helped me out at various stages over the past year:

If you’re a junior, mentor or considering stepping in the world of development, I hope this has helped.