Mentorship and working with the next generation of developers is important to our team here at Planet Argon. Five weeks ago, we welcomed our very first pair of React.js interns from Epicodus, a Pacific Northwest-based vocational school for aspiring programmers – Holly Wilkalis and Ginger Kretschmer. At the end of their internship, we asked our interns to reflect on the lessons they learned while interning at Planet Argon. Here's a reflection from Holly on her time as a front-end development intern.
When I showed up for my first day at Epicodus last October, April seemed so far away. “I’ve got six whole months to figure this all out,” I told myself. And yet here I am, already in the last week of the last phase of the program, my five-week internship. I consider myself extremely fortunate to have been matched with the outstanding Planet Argon team and I’ve learned a lot about development processes and best practices during my time here. Here are just a few of the lessons I learned over the last five weeks.
DON’T forget to set up your .gitignore
I know. This is one of the very first things you learn in code school, how could you possibly forget it? But it’s an easy step to overlook when you’re working on small stand-alone demo projects that don’t really matter that much. And nothing endears you to your new co-workers like when they get that first pull request and it’s full of stuff that doesn’t need to be there. (If you do make this mistake, though, it can be fixed).
DO comment your code
I know you spent an entire day writing and troubleshooting that bit of code that fixes that weird problem you encountered and you think that know you’re going to remember the logic behind it FOREVER. Trust me though, you’ll come back to it three weeks later after working on something else and it’ll be like you’ve never seen it before. Do your future self and your future co-workers a favor and add a brief comment explaining what’s up. You can thank me later.
DON’T be shy about asking your new colleagues if you can shadow them while they work
Fortunately my intern partner was more assertive about this than I am because watching smart people while they work can be a real learning opportunity. I learned a lot about troubleshooting and best practices and got a more detailed look at some really interesting client projects than I probably would have otherwise. (And your co-workers may even find it helpful to get some practice in talking through their process - it’s an important skill!)
DO ask your designer for clarification
This has been my first experience coding from a designer’s Sketch files, and looking back I probably should have asked more questions before jumping into the code. For instance, if the header style in a design varied a little from an previously established site style, which should take precedence? How much room do we have to modify that chart style if it’s not working on a smaller screen? How close to final is the copy and data?
Once you have spent more time working with the designer you’ll have a better handle on these kinds of questions, but until then it’s a useful conversation to have. You’ll get to know more about their thought process and it may well save you some time later on in the process.
DON’T be afraid to ask questions, but DO some research on your own first
It really is okay to ask for help, particularly if it means you will avoid breaking the codebase or making a lot of work for someone else down the road. As an intern no one expects you to have all the answers. However, you should get in the habit of spending at least some time trying to find the answer first. Your co-workers will appreciate you making the best use of their time and you’ll level up your Google and Stack Overflow skills. And if you do still have to ask for help, you’ll probably understand the answer a little better if you’ve done some background work in the meantime.
DON’T be afraid to experiment with a new framework or language while you’re here
As a student of JavaScript/React, I was pretty nervous about being handed a Ruby project and told to make some edits. But I was surprised - and pleased - to realize how much I could figure out on my own about this entirely different language simply by reading the code, connecting the dots, and consulting Google.
Besides, the great thing about coding is that you can make mistakes and and break some things in the the pursuit of knowledge and the world won’t end. (Especially if you were smart about it and are experimenting on a branch or on a cloned version that you don’t need to keep). And now that I’ve seen Ruby in action I’m interested to study up on my own and try some things out.
DO pair program with the office dogs (if there are any)
If you’re very lucky, there will be some office dogs who will let you scratch their ears while you think through a problem and it will make you at least 50% more efficient.
I’m really proud of our finished product, the 2018 Rails Survey results, and I appreciate the support we received from the team here. While I’m sorry to be saying goodbye, I’m excited to be taking everything I’ve learned with me to my next adventure, whatever that turns out to be.