This week at my new job, I was once again reminded of the differences between coding alone and coding as part of a team.
One of my tickets required me to add a new column of data (indicating whether some products offered a free trial) to an existing table. If a free trial was available, a green checkmark was displayed; if not, a greyed-out checkmark was shown instead.
In our database, each product has a free_trial? attribute 't' for "true", or 'f' for "false". Eager to demonstrate my Ruby skills, I dived into building and implementing a new method to accomplish my task. But then (thankfully!) I paused and asked myself: "Self, why not check to see how the green and grey checkmarks were generated for other table columns?" I found the following code block:
<% @aspects.each.with_index(1) do |aspect, index|%>
<td class="aspect-<%= index %>">
<span class="icon-circle <%= green_or_grey(@product_aspects[product.id], aspect.feature) %>">
<i class="gg-check"></i>
</span>
</td>
<% end %>
The key snippet is the span statement which contains the green_or_grey method. This method returns true if aspect.feature is included in the @product_aspects[product.id] array. However, in my case, I wasn't checking to see if an array contained an item; I was checking to see if an attribute was equal to 't' or 'f'.
I was stumped for some moments, before I realized that I could reference a one-element array containing the product's free_trial? attribute, and then pass in 't' as my second argument. Then the green_or_grey method would return true if product.free_trial? == 't':
<%= green_or_grey([product.free_trial?], 't') %>
During code review, my teammates warmly commended me for figuring out a way to use the existing method (and of course I felt all warm and fuzzy inside lol). More importantly though, I felt proud of myself for taking the time to understand, respect and re-use the code I'd been given. In the moment, creating new code may feel easier and promise a certain level of progress, but could end up bloating and complicating your codebase unnecessarily.
Top comments (6)
Congrats on finding a solution that made you smile:). That's really cool that you working in the field with rails. That's what I am do doing in bootcamp it's a main part of the curriculum. So when I need help I know where to come lol. At what point in your career you felt comfortable goin through big unfamiliar code baseses?
well my career so far is only 30 days long LOL! I just started my first-ever dev role.
My company's stack is mostly RubyOnRails; I actually gained most of my Rails confidence from configuring DevTo's platform on my local dev and learning their codebase to the point where I could create PRs for some issues. Even though we learned Rails in bootcamp, it wasn't the same as working on a codebase that I wasn't the only developer on it lol.
That's one small drawback to the bootcamp experience, in my opinion. Unless your bootcamp has you working with other students, mentors and professional devs from the beginning, you get the habit of being judge jury and executioner over your own code. whereas in a professional environment its more about understanding what others have coded, synchronizing with your team's dev flow, being comfortable with code review, etc.
Wow congrats on you first dev job!!!! ๐. You are right about getting accoustom to using other codebase besides your own. In my bootcamp we are paired to do projects together and then our code gets reviewed via PR once accepted then we can merge. So far that has been a learning experience because I never did a PR before lol. We also will be contributing to open source projects I think and we do have mentors.Thats really cool how you pull the codebase for this site and studied and contribute that's takes patience and will power,I'm sure it's intimidating at some point.If you don't mind ne asking how difficult was the interviewing process ? Did you do a technical interview ?
Absolutely, the whole interview process took about 2 weeks.
First was a take-home coding exercise which they gave 3 days to complete. It was in Ruby and involved creating Classes and methods to process the data given. It was moderately challenging, for me anyways.
Second step was a non-technical phone conversation with the business people; this was more behavioral in nature - how do you work with others, etc. This was the most pleasant part of the process lol.
Last was a 3-hour on-site interview which was very technical; they used scenario-based questions, whiteboarding and pair-programming. At any given time I was speaking with 4-5 devs at a time, so it felt a little overwhelming. But I gave my best answers, and was sure to say "I don't know yet" when I didnt have a clue about a question.
Thanks for your reply, I guess there is no running away from it huh! Technical interview must present it self lol. You are a great writer also maybe you should write a book sometime.
It's the difference between owning the codebase and providing input to the codebase.