Front-to-Back: 4 Takeaways from an Application Developer Intern

Coming into Viget as an incoming sophomore, my goal was to be a sponge. Through my college organization, Hack4Impact, I had the opportunity to work on the front-end of web applications – utilizing software and languages like React, Tailwind, and JavaScript. But, for this summer, I wanted to try something completely different to broaden my skill set and understand what I wanted to do in the future… in enters the Viget Application Developer internship! 

Initially, I was hesitant to apply – I would have to learn Ruby and the mysterious black box that was “the back-end.” But I decided to take that risk, and am grateful that I did. My advisor and the rest of the application development team provided me with encouragement and resources to solidify my foundation in Ruby on Rails, via numerous pair programming sessions and by building a series of small Rails apps that slowly got more complex. As of now, I am confident enough to say that I can model and build an involved Rails application from scratch.

I wouldn’t have been able to pick up Rails as quickly as I did without my initial front-end experience informing most of my learning process. Here are my 4 takeaways from a front-end developer turned back-end developer:

1. Balance modularization and readability
   
   With my experience in the front-end, I started out by breaking off large pieces of Ruby embedded HTML into reusable partials, just like how I learned to with React components. This saved me so much time and made my code significantly more clear for myself and for Robert, this year’s UI development intern, who had to work with the same code. But this process became more complicated when applied to the back-end, where excessive modularization hindered readability. I had to consider questions like “should I keep this constant in the config file or would that hinder a new developer’s understanding of what that constant does?” and “should I write this SQL query in one line or separate it out into multiple simpler lines?” Coming to a balance between these two factors helped me think through the purpose of each line of my code while making my codebase much cleaner.
   
   

2. Work smarter, not harder, with gems
   
   Complicated pieces of code for features like adding attachments are interesting to dissect and extensively customize, but on a shorter timeline, it simply isn’t worth it – it would be much more valuable to work on novel features. That’s why gems, just like JS packages, are important – there’s no need to reinvent the wheel. One example of a gem I used extensively in the intern project is the pg search gem. My task was to filter a number of records by search, and after discussing it with my advisor, he suggested I find a way to implement Postgres full-text search. I evaluated the available packages on GitHub and settled on the pg search gem for its ability to filter through records by attribute and its good documentation. After a quick exploration using the gem in a side project, I was able to check off a complex MVP feature more quickly than I had initially expected.
   
   

3. Prioritize Test-Driven Development
   
   Test-Driven Development is not just a buzz word to drop in an interview. This style of development can help prevent and diagnose errors in the database, model, and view levels and save a lot of time guessing the error via a long stack trace. I got pretty deep into the intern project without writing tests, but then realized I was wasting more time searching for errors than actually fixing them. So I read more into the testing pyramid and implemented model and controller level tests with RSpec, factory_bot, and shoulda matchers. RSpec is a testing tool written in Ruby that is a syntactically easier way to write tests compared to the built-in Rails Minitest. factory_bot simplifies Rails fixtures and makes it easy to build different versions of the object you are testing. Lastly, shoulda matchers are RSpec-compatible one-line tests for Rails functionality such as model validations and associations. These are all gems, another example of work smarter > work harder!
   
   
   

   

   
   

4. Understand project time constraints
   
   Styling already has its limitations, but adding database tables and associations into that mix adds to the complexity. This was the hardest part for me but one of the most rewarding, because by understanding how long each development segment was going to take, I was able to present an application that included all of our team’s core features. For the intern project, my involvement started after the initial features were decided on and design wireframes were beginning to be created. I started with data modeling to better give myself an overview into how the database will be structured, and set up an initial repository. The next step was to generate all the models and their respective controllers and routing, ensuring that the user journey is mapped out according to the wireframes. The last, and longest, part of the timeline then comes from building out the views for each of the controller actions, as numerous iterations are required to implement every single functionality

The more I delved into back-end development, the more I felt like I was becoming a better programmer and felt more confident in my contributions. For me, one of the biggest indicators of this was attending the daily dev team standup and feeling like I understood what they were talking about more and more every day. Whether you want to pursue a career in application / full-stack development or just learn something new, taking apart the black box that is “the back-end” is a valuable experience.