Avoiding Common Pitfalls For Your Rails Internship

You’re bright. You’re personable. You’re passionate. You’ve been selected to ascend to the position of Rails Developer Intern this summer. It’s kind of hard to believe considering just yesterday, you were moping over having nothing going for you. But all that’s changed, because you’re the one. As it was for me, this just may be your first time working with Rails or doing a proper internship for that matter. On the other hand, Rails may be the only thing that you’ve ever known. Either way, I’m here to tell you exactly where I fell short to put you one step ahead of the game.

Disclaimer: The last impression that I’d like to make on the world regarding this internship is one of self-pity and negativity. Quite the opposite, this summer has probably been the most game-changing time of my life, all thanks to the unparalleled love and support that Vigets bring to the table day in and day out. Without Eli’s (my internship adviser) and other co-workers’ constant care and companionship for the past 10 weeks, I’d be infinitely less confident and prepared for my job search and life after college. So while this article is about how not to set yourself up for mediocrity, you may also be interested in this article which is more about how to set yourself up for success.

Code Reviews

One of the most valuable things about the Rails developer internship is getting direct feedback on your code from a sizeable team of seasoned experts. These reviews take the form of GitHub pull requests (PR’s) that you share with the dev team for inline critiques of your code. During my time here, I submitted only about a handful of PR’s which scarcely dealt with self-contained features. Rather than submitting one PR for a dozen different features to beat an impending deadline, submit smaller, more targeted and digestible PR’s. This way, one has a better understanding of what needs to be merged into a master branch, and the developers reviewing your code won’t feel dissuaded from even looking at it in the first place. Additionally, as soon as you open a PR and link to it for other developers to review, make sure to respond to criticism ASAP. Focus on addressing those concerns to close out the PR immediately and then get on with the rest of your life. You’ll thank yourself later when you’re not having to beg the developers to give their thumbs up on a bunch of long overdue, incomprehensible code.  

Debugging

It goes without saying that you’re going to be learning a lot of stuff, especially if you’re new to this business. With every additional error you’re bombarded with by Rails and Heroku logs, you’ve essentially got two options to act upon - well, maybe three. Firstly, you can blindly stare at your laptop screen and hope the error just goes away without you having to think about or do anything. Secondly, you can scour the internet to find some random chunk of code from God knows whom, slap it onto your application, get just lucky enough for things to not be in flames, and move on. Lastly, you could be the responsible programmer that you truly are at heart and take the time to learn the root cause of the error and really understand how that bit of code you’re copying and pasting does its magic. I’ve learned to be willing to stop in my tracks and reason through difficult debugging sessions rather than impetuously hacking away. This boils down to simply working smarter, not harder.

Learning and Doing

Finding that Zen-like balance between learning and doing on the job has been a challenge - there’s very real danger in blindly doing one or the other. From time to time, I found myself indulging in a full day of programming tutorials and videos, which, though related to the task at hand, were simply too broad in scope to be directly applicable to what needed to get done. I call this phenomenon within development learncrastination - the feeling that one must spend a ton of time studying up on topics before feeling able to do something useful with said knowledge. The flip-side to this disorder is diving into build out too quickly without having the fundamentals securely under one’s belt. Learncrastinators eventually find themselves getting little to nothing done, because they constantly feel underprepared to tackle their work. Conversely, the very many times that I’ve cranked out code without knowing enough has been equally debilitating. You end up wasting a ton of time guessing on how to debug errors and how to properly and most efficiently go about building your app. Unfortunately, striking this balance between learning and doing is nothing but a matter of practice, so keep at it.    

Discipline and Focus

As the work began piling up, I started losing my grip on sticking to a regular schedule. To get a sense of the discrepancy between my vision and reality, here’s what my days resembled at the summer’s onset -

9:00 am: Check email/notifications, prepare for day.

9:30 am: Typical work/meetings of the day

3:30 pm: Look up terms mentioned by devs, review scram challenge tasks, and skim through bookmarked technical articles.

4:00 pm: Type up handwritten notes for the day.

4:30 pm: Write up blog post for the day.

5:00 pm: Go home.

Instead, this is more like what my day ended up looking like with time.

8:00 am - 7:00 pm: Hack through programming tasks interspersed through mandatory meetings.

In other words, I was no longer regularly looking up unfamiliar terms, reviewing my schedule and goals, and diligently reading through technical articles. Rather, I was mostly staying late and brute-forcing my way through programming stumps. Perhaps better planning might have reduced the amount of time spent feeling lost, freeing up time to do those things that I had hoped to do on a daily basis. For me at least, I’ve learned the importance of not letting go of these rituals lest one lose sight of the forest for the trees.

Reaching Out

If only I got a dime for each time I should have reached out to one of the developers for clarification on unfamiliar technologies, methodologies, and errors they’d mention. This applies equally well to whenever I felt unsure about the quality of my own code. I mostly felt embarrassed for not knowing things, or afraid that I’d be wasting others’ time by asking questions that I felt should be obvious to me. Clearly, there is nothing more self-destructive in the life of a developer than this mentality as it’s left me with a bunch of unanswered questions, unclarified issues, and a mild affliction of the imposter syndrome. Considering any one of the developers would be more than happy to work through a problem with you at any point in time, I’ve learned it’s my responsibility to help myself get help from others.

Soft Skills

Aside from doing better in a technical capacity, I could improve my communication and collaboration skills and professionalism. More often than not, I’d discover a slack message or notification one or two hours too late. Through regular meetings with the other interns, I’ve realized just how inconsiderate I could be by prematurely shooting down others’ ideas and opinions before really hearing them out. Along the lines of effective and fair communication, I’ve learned to demonstrate greater professionalism by keeping track of my own progress and more frequently updating the team on where I was with my work. And finally, though slightly unrelated, I was pleasantly surprised at the beginning of my internship to learn that Viget developers have really awesome camaraderie going for them. Alongside collaborating on impossible projects being the wizards they all are, internal communication between Viget developers is casual and outright hilarious. Rather than regularly contributing to the animated, ongoing internal discussions, I was passive and self-involved the majority of the time. I’ll be sure to take cues from future work environments to match their language and behavior patter

Moving Forward

Clearly, there’s a lot to be learned from an internship experience with Viget. Foremost, the company’s emphasis on excellence and integrity has done wonders for my own perspective on the importance of doing good work and the pleasures of honest collaboration. This internship has given me more than adequate exposure to all aspects of web development and the tech industry at large. With my newly equipped skills, experiences, and relationships, I feel excited to ride the transition from the sheltered bubble that is my liberal arts college into the real world where real things get done. So, thank you to everyone at Viget for a host of lifelong lessons learned, and best of luck to future Rails developer interns!