|
I just started my 100% remote dev job last week. It’s been pretty interesting. My laptop and some earbuds were shipped to me. They arrived my first day. I had emailed my manager beforehand to let her know that I would probably be missing any morning meetings I might be scheduled for, as I didn’t know when in the day it would arrive. The expectation was just that I had a functional computer the first day, so that made the process pretty relaxing. I really only verbally talked to one person (my buddy) for ~30 mins on my first day. As far as setup goes, there was a stack of stapled paper (~6 large print pages) indicating how to log in (I was verbally provided a password, but that’s as far as the verbal walkthrough went) and perform basic setup - installation and authentication to VPN (globalprotect), security/management software (DUO), video software (Vidyo), Slack, and urls for further references/setup (confluence, extended setup documentation via Google Docs, HR sites, benefits sites, etc). The setup was pretty straightforward, so in reality I spent most of the day configuring alacritty, tmux, vscode and documenting that for my own personal use next time I have to do this. However, this was mostly done while waiting for various people/teams to provide me access to the resources I’d need to do dev work specifically, like source control, and CI/CD, and all the associated necessary environments. My company starts new devs on 2 6-week rotations to begin with, so I asked my current team’s tech lead for arch diagrams, and _up to date_ docs on general things like story lifecycle, responsibilities of various people within the team, their git process, the team’s definition of done, valid contract definitions, and relationships/interactions with other teams. Once I got access to the codebase, I went through the local env setup, and my first PR was changes to the README based on that process. I generally try to take as best notes as I can to improve the process for the next person (also selfishly to save me time troubleshooting in the future). On my 2nd or 3rd day, I scheduled 4 meetings: * one with a tenured backend dev in a room with a whiteboard to go over architecture review * one with a sr frontend dev to go over inconsistencies within the codebase and where to look for the current best practices * one with a stakeholder to go over how they communicate requirements for the app, both initially and throughout the dev cycle, and any follow up stuff for after dev work is done * one with QA to go through their process (also revealed some more things I needed to request access to) what the interaction is with devs, and where their responsibilities lie within the story lifecycle Also it’s perhaps worth mentioning that I also prioritized asking the devs about how to test the codebase thoroughly. Not only is it how I like to explore a codebase initially, it also provides a good framework for what level of test coverage is expected, and what is required to be able to run them (ie. VPN, docker/AWS login, various states of local and remote servers running, any local config changes that make dev’s life easier that might not be explicit in any docs). It’s been very DIY tbh, and it’s been really nice. The documentation is 98% accurate and up to date, which has been amazing. My only real complaint is that here have been quite a few coincidental business-wise meetings in my first week, and I don’t have context for anything at all. Being in a video call with 200+ other people doesn’t lend itself well to asking questions, and it gets aggravating to ask “what is X?” “What is Y?” continuously. It’s something that’s much better done in person. |