Happy Labor Day Weekend, everyone! Of course, this being the start of the second week of my internship, I can't stop thinking about labor and the beginning of my career as a software engineer.
Much has happened in the first week of my work at Maxwell Health, so I'm going to try and condense it down to a few things that helped me get in the right mindset during this time. It's Wonderful to be reunited with such a supportive family there, but a very interesting and different feeling of being thrown into a completely new fire and getting to work my way out of it.
Exciting times! This post will mostly be journal-y but I'll also talk about a few things I've learned along the way. Your mileage may vary, as my sample size is 1ish.
1. Get a clear trail or blaze your own
Make sure that you've got a plan for what your first days are going to be like and what you'll be responsible for doing during that tie. HR will often use this time for orientation to your perks (benefits, salary, etc.), but don't expect all workplaces to behave this way.
Day one for a dev also includes setting up your computer (environment, introduction to their version control system) as well as an introduction to their git workflow. I myself found it helpful to ask each dev I encountered what tools/extensions they use, too, just to reduce the barrier to entry for coding later.
If it helps you like it helps me, try to get together with a more recently hired dev (if there is one) and try to document out the steps yourself. If the infrastructure you want isn't there, don't hesitate, create! A junior dev and I immediately realized that the wiki we were using wasn't as functional as we wanted it to be, so we implemented our own knowledge storing area using Hackpad since it lowered the friction of finding out info we didn't know.*
*Please be sure to make sure you're in line with your suggestions, as some might see adopting a new technology as criticizing their work. If something works better for you, maybe just use it yourself and save it for an informational lunch some time.
2. Be your inner cleaner fish
After you've gotten your setup somewhat locked into place, you need to get up close and personal with the code (this is, after all, what you've been dying to do). I suggest that you embrace your inner cleaner fish, and latch on to the nearest dev on your team.
In my case, I was lucky to have a few hosts that were willing to have me just hover around them while they go about their business, and I tried to keep my questions to a minimum, or at least until a break in the conversation/workflow. A few things about this that might cause a problem:
- The developer you pair with may not work well with constant interruptions. Make sure you time these or if they seem to be in flow-mode, try to save your questions until later if possible.
- You may be in an open office, where it's easy to get distracted. For these kinds of situations, try to see if you can book a conference room or find another slightly quieter place so that you minimize both your own and your host's distraction.
These shouldn't be huge barriers, but the benefits of latching onto someone are incredibly valuable. You can get the entire project/task workflow, version control workflow, and a rundown of the codebase all at the same time.
From the latchee's point of view, they have to think of this as an investment. You're taking away from some of their productivity in order to get up to speed even faster. So remember when the next dev comes on board how useful it will be for you to be open and accepting!
So for now I'm going to leave it at that. I don't have any other huge wisdoms to impart. You know the usual: fear is the mind killer, take risks, be bold, etc. It's all going to blend together. I know this next week I'm going to do my best to stay humble, ask better questions, and make sure that I'm flying on my own (at least partially) by the end of the week. For that to happen, I'll need to muster a fair bit o' courage and not lose sight that I've only been doing this for 4 months.