Getting Past Getting Started: A Developer Apprentice’s Story

When a field is always changing, and there’s always something new to learn, what does it take to go from apprentice developer to journeyman?

Questions like this have been at the back of my mind for the last few weeks, while I’m coding and in the times in between. Fortunately, this kind of thinking is encouraged during the Apprenticeship training program at Viget. Along with participating in the global curriculum and contributing to client work, the program's discipline-specific training portion has helped me gain new programming skills and a better understanding of what other skills I want to build.

On my second day at Viget, I received a copy of Edmund Lau’s The Effective Engineer, a book packed with lessons on how to learn and leverage one’s efforts at multiple career stages. By reading a few pages each night, I immediately picked up insights that shaped my approach to the apprenticeship. I’ve been more intentional and discerning about spending time on activities that will offer the best long-term benefits. My purpose in writing this article is to share ways that my first six weeks as an apprentice marked a shift in how I learned web app development.

Getting Started with Rails

To give some context, I never worked in Rails or Ruby before six months ago. I worked in science for over a decade. As a postdoc, I enjoyed using formulas in spreadsheets to streamline data analysis, and I dabbled a bit with running Perl scripts from the command line, but I wasn’t writing those scripts myself. I wasn’t doing any kind of computer programming until I decided to make a career change last summer. Like many coding bootcamp students, I started off learning fundamental front-end languages: HTML, CSS, and JavaScript.

The figure above was built using my own project data from GitHub, a site used to store project code in repositories. A single project can include multiple languages (indicated by colored dots) that line up vertically above the date when the project was last updated.

I built my first Rails app in September by following the steps outlined in the Rails Guides’ Getting Started tutorial. I made a few more apps after that and grew comfortable with MVC architecture - organizing an application into code for models, views, and controllers. However, I was getting by without understanding much about what was happening beneath the surface.

Being an apprentice at Viget has challenged me and given me the opportunity to dig deeper, giving me a better appreciation for all that Rails can do. At the beginning, I had a hard time understanding and extracting anything useful from the Rails API docs. Now, reading these same docs is an illuminating experience that helps me expand my toolkit. I’m getting better at seeing how to implement certain Rails conventions so Objects know just what they need and nothing more (Objects are a core concern in object-oriented programming). I am starting to identify places to use Plain Old Ruby Objects that fall outside of the MVC convention. I’m learning how to navigate these rough spots by mimicking solution patterns that have been used by others - both at Viget and in the broader Rails community. Importantly, I’m getting to see firsthand how a deep understanding of the entire Rails toolbox leads to better apps for Viget’s clients.

From StackOverflow U to Face Time with Mentors

The opportunity for mentorship is one of the best parts of being a Dev Apprentice at Viget. The face-to-face conversations about development challenges are a welcome departure from the long days I spent combing through Stack Overflow threads on my own. I used Stack Overflow so much in December that I earned a hat for visiting more than ten days in a row, “like clockwork.” (If you’d like to learn more about the site’s Winter Bash hats, here’s a great resource!)

As an apprentice, I meet with my official mentor at the beginning of each week to assess the past week and set new goals. He is available throughout the week when I have questions. Other Viget Devs have offered to schedule pair programming sessions with me and are open to spontaneous one-on-one sessions. We’ve discussed principles of object-oriented design and MVC architecture with direct application to problems I needed to solve. When I started to work on a client’s app for the first time, one Senior Dev walked me through the process of getting the client’s app running on my machine and took time for a more general chat about server configuration. After that, I was able to help resolve a routing bug and make display updates that the client requested.

I am still using StackOverflow, but I'm far less dependent on it because of the mentorship I’m receiving.

Scaling Up at a Steady Pace

When I started the apprenticeship, I knew I wanted to learn about web application development in a business-driven context, but I didn’t have a specific type of app in mind. I wanted to get a better sense for what kinds of apps clients asked for, and I was eager to learn more about what I didn’t know. The Dev team invited me to Viget’s internal #code-review Slack channel and gave me access to the GitHub repos so I could see the code that the team was working on. GitHub is a tool for maintaining and creating code with teams. Typically, a master branch is code that has been finalized for production; feature branches are used to build new features and will eventually be merged into a master branch. As I expected, client apps are much more complex than anything I previously encountered. The figure below depicts the complexity gap between apps I've worked on (represented in orange boxes on the left) and a Viget client app (the graphic that spans the full width).  

To get a feel for what Viget’s Developers were doing, I read code in pull requests shared in the #code-review Slack channel. A pull request (or PR) is a way of letting collaborators know that your feature branch code is nearly ready to merge into the master branch. I recognized some patterns but not enough to follow along with ease during my first week at Viget.

Fortunately, I was tasked with building a clone of the Hacker News site, which became a way to ramp-up my Rails skills and learn how the code-review process works at Viget. Previously, when I used GitHub for collaborative projects, my teammates and I would discuss pull requests offline. Being at Viget introduced me to how developers can use GitHub’s tools to embed conversations in between lines of code that are up for review in a PR. The PR code-review process has been one of the primary ways I’ve learned new Ruby methods and better ways to organize code during my apprenticeship. In addition to expanding my knowledge of Ruby on Rails, building my own app has let me safely experiment with git rebase and learn how to configure a server for app deployment.

Having my own app meant I had specific problems I needed to solve, and this changed the way I looked at what the rest of the Dev team was doing. Instead of skimming their code without an anchor, I was looking at production-ready code with very specific questions in mind. I'd start to ask how Devs at Viget solved the same problems I needed to address myself. When I wanted to write specs for a complicated button display, I looked at a spec someone had talked about during stand-up (the daily morning meeting where all the Devs give an update on what they’re working on). After seeing a novel way that a Viget app renders modular components during a paired-programming session, I was inspired to develop Presenter objects to simplify view logic myself. When I got stuck because I couldn’t figure out the correct syntax to render a partial from my Presenter, another Dev showed me where it was done in a client app.

Using resources wisely

Another way I’ve grown as a developer since being at Viget is improving the way I source the resources I need. By resources, I’m referring to all of the following: documentation for Ruby gems (libraries that can be added to a Rails app to quickly introduce new functionality) and other tools I am using, online tutorials, and blog posts from other developers. Here are links to some examples:

• Source documentation for the Devise authentication gem
• A tutorial from an online coding school on how to use Devise in a Rails app
• A blog post covering the use of Devise along with other gems

Source docs, tutorials, and blog posts from other developers can all be invaluable resources. However, there are particular strengths and weaknesses associated with each format that I didn’t know about when I first started to write code. Further, some problems are shared by poor quality resources in all three categories, so there are few instances when you can be 100% sure that anyone else’s ‘recipe’ will solve all of your problems without some additional tweaking. After encountering and resolving challenges associated with each, I’m getting a better sense for some of the gotchas.

---

To wrap things up, the apprenticeship has certainly exposed me to web development in a business-driven context, as I hoped it would. I have seen developers at Viget move fast to meet tight deadlines, but I also hear those same people taking time to discuss app design and database organization, strategies that make an app better. I know I still have a ways to go before I’ll be as quick as I’d like to be, but I’m glad I’ve had so many strong role models to follow at such an early stage of my new career.