How I Got Here…

I’m currently employed as a Frontend Instructor at Turing School of Software & Design, where I primarily teach React, Redux, React Router and testing with Jest and Enzyme. In an effort to promote professional development, Turing recently partnered with EarthVectors, Inc. to give instructors an opportunity to roll off of the instructional staff and spend 6 weeks with a company getting experience working on a dev team and with a production codebase. Sadly, my 6 weeks is coming to an end this week, but I want to share a few things have learned during this short time.

Day to day life…

I think it’s important to share some context about what my day to day work life has been like with EarthVectors (spoiler alert… it’s been fantastic!). I have been working with two other developers on an application for a genetics company who is researching childhood cancer. There is also a Product Owner/Manager who is remote, but very present via Zoom for daily stand-ups and Iteration Planning Meetings (IPMs). The atmosphere is extremely collaborative. For instance, during IPMs, the dev team is collaborating with the Product Owner/Manager in writing stories, grooming stories, and assigning a point value to each story (difficulty level of the feature). This is done in a very democratic fashion… it’s basically like Paper, Rock, Scissors, but you throw out your point estimation (1, 2 or 3). If everyone is consistent in their estimation, the point value is set. If not, each person on the team has the opportunity to share their reasoning behind their vote. Once everyone has been heard, a collective decision is made on the point value and the story is then placed in the backlog for the dev team to pick up when they are ready to start working on that particular feature.

This collaborative mindset also carries over into the development process. EarthVectors is a company that strongly believes in pair programming (as do I now). I found working in a pair to be super efficient. As the saying goes, two heads are better than one. It’s easier to catch mistakes when they pop up instead of chasing down errors later. We are typically all in the office together, with the exception of one day a week when we all work remote. No matter if we are in the office or working remotely, we always mob (all 3 of us) or pair on the same problem. This is nice because everyone stays up-to-date on what is happening in the codebase. Every decision that we make, from which story to pick up, setting goals for our pairing session, design decisions, etc., everything is decided as a team. I’ve now seen first hand the benefits of this work style, such as building trust and communication amongst the team.

Another core principle EarthVectors adheres to is Test Driven Development (TDD). I was familiar with TDD coming in and try to instill this practice in my students, but had never actually been part of a team that works in 100% TDD fashion. This is an incredible skill that brings a lot of value to a project. When the team begins to work on a new feature, we look at the story to gather any context and details we might need. The first goal is to write a failing test (easy). Then you want the errors in the test to instruct the code you write. It’s a constant red-green feedback loop. Basically, we always want to be writing tests that will drive out our functionality. I have found that this method produces lean and clean code. It gives us purposeful direction and prevents us from writing unnecessary code. I have officially drank the TDD Kool-Aid.

A few takeaways…

Coming in on day 1, I knew very little about the application we would be working on. I knew it was a Rails app with GraphQL and React, so I was just hoping I wouldn’t be totally lost. Diving into a new, large and unfamiliar codebase can be scary. And I’m not going to lie, it was pretty intimidating. But even though I didn’t know much about Rails and GraphQL at the time, I found that I could still follow along and understand what was going on. I attribute part of this to the team’s unwavering commitment to writing excellent tests. When you have good tests in place, they will tell a story of what the code is actually doing. So no matter the language, when you are just trying to get familiar with the codebase, tests are a great place to start.

When problem solving, always try and find the smallest possible step you can take that will move you in the right direction. Even if that step is pseudo-coding and drawing a picture. These things can be incredibly helpful! The same goes for refactoring. Start with the smallest possible step and follow that red-green feedback loop with tests.

Always strive for short feedback loops. Ideally, you are creating stories that can be delivered back to the Product Owner/Manager in the same day. Once the story is delivered, it is either accepted by the Product Owner/Manager or rejected with specific feedback to iterate on. If a story takes longer than a day to complete, consider reflecting on this story and thinking about how it could have been broken down into multiple smaller stories.

Great developers don’t stop at just getting something to work. You should strive to know exactly what every line of code is doing and why. This is where the most valuable learning takes place that separates you from the rest of the pack.

And speaking of great developers, I hit the jackpot when it comes to the people I had the pleasure of working with over the last 6 weeks. I learned a lot about what kind of mentor I want to be to others in the future. I have to give a huge shoutout to Kim Hendrick and Mihir Parikh at EarthVectors. They are so knowledgeable, so patient, so kind, great teachers, even better humans, and just overall badass developers! I can’t say enough good things about them and will truly miss being their sidekick!

Thank you!

Lastly, I want to thank Turing School of Software & Design and EarthVectors, Inc. for making this opportunity possible. I am so grateful for this experience and the people I have met along the way!

Jumping In At The Deep End… was originally published in EarthVectors on Medium, where people are continuing the conversation by highlighting and responding to this story.

Super intimidating, right?!? All I could think about was “I don’t know these people. I don’t speak/write their language. I am still so new at this. What if I screw up?” I recently read someone else’s similar encounter where they compared this feeling to walking up to a group of strangers at a party. That’s exactly what it felt like! So, we introduced ourselves, explained that we were new here, and that we would love to try and help out in some way.

So here we go…

Being so unfamiliar with Ruby, getting the project set up locally was a bit of challenge. It seemed as if our machines wanted to fight with us about which version of Ruby we should be using. However; once we conquered that issue, the rest of the project setup was fairly simple. Thanks to excellent documentation, we were able to follow along step-by-step installing the project’s gem dependencies, configuring the site, creating a PostreSQL super user, creating the necessary databases, and seeding them with massive amounts of data. This was definitely a good lesson on the importance of well-written documentation. So now came the moment of truth… starting the server and seeing if we had at least followed directions correctly.

It worked!

At Turing, we really focus on celebrating the small wins… this was one of them! We exchanged high fives, but the celebration was over as soon as we opened Atom and saw the size of this code base. It was by far the largest any of us had seen and was definitely a reality check of what’s to come in the real world. It was a maze, and all I could think is “how in the world are we ever going to be able to navigate through this?”

I quickly came to the realization that simply finding any one thing in this code base was going to be like finding a needle in a haystack. After spending some time getting familiar (and I use that term loosely) with this enormous code base, we read through the CONTRIBUTING.md and began to sift through the issues to see if we could find something relatively small and simple enough for us to tackle as first time contributors. The CONTRIBUTING.md is always a good place to start when working on an open source issue. This is where you will find instructions for how to contribute to the project and information on workflow, how they prefer a PR to be structured, etc. The issues are usually structured in a way that you can filter by any number of skill sets, such as “good first issue”, “rubies for newbies”, “angular for newbies”, “beginner’s issue”, or “ux”.

After exploring different parts of the application’s UI, we decided to go with a CSS issue that we felt would be manageable. The code we wrote to fix their issue was not difficult. But like I said before, the challenging part was to find and target the correct element in the code. As a group, we were reasonably certain that we had provided a solution to their issue without causing any harm to the rest of the application.

Time to submit a PR

We made sure to carefully architect our PR just as they had laid out in the CONTRIBUTING.md. I can’t really explain why, but for some reason I was extremely nervous and anxious about submitting it. Did we do everything correctly? Are we 100% sure we didn’t break their application? These, along with many other thoughts continued to flood my mind. Granted… I’m an anxious person by nature anyways. I had also fully prepared myself, and almost expected, to not get any kind of response. But that wasn’t the case at all! Someone actually reviewed our PR that same day. Truthfully, I was shocked. I had heard of people having bad experiences, i.e. the person reviewing their code just being a total jerk. However, the individual that reviewed our code was surprisingly kind, super supportive, and offered great feedback.

Lessons learned

Overall, this was such a positive experience. I realize that this is a great way to start learning a new language. You just have to jump in and know that you have great code examples to go by right in front of you. Most importantly, you have to trust that if the owners of a code base have labeled some issues as “beginner issues”, they will most likely be helpful and supportive of you in your plight to contribute. But also know that contributing to open source doesn’t always mean you have to be contributing code. My group was also able to create new issues that we found as we were exploring the application. There are numerous ways you can find to make valuable contributions.

Final thought

Contributing to an open source project builds confidence and experience. Just do it!