A new city and job are hard to get used to—although, to be fair, I don’t think you ever get used to pressing the Reset button on these kinds of things. It’s totally normal to not know what you’re doing when you start a new job, even a few months in. I’m still learning about LDAP groups, SLAs , RFCs , and a whole host of acronyms that feel like a never-ending induction into a large tech company.
My first week at work involved setting up a local version of another team’s project. It went something like this:
git clone cd
npm run watch Scary npm error log
rm -rf node_modules "Okay this is it!” Crosses fingers Scary npm error log
After an hour of Stack Overflow-ing and meandering...Pings engineer on other team
"So um, how do I run this?"
Turns out, I had to npm link another repo that I didn’t know about!
This might have been obvious if it were in the documentation. But, life happens™. Deadlines sneak up on us and we have a lot on our plate. We build and build and often let the little things—like updating READMEs—go by the wayside.
But as a new engineer, those little things add up! I often felt frustrated and defeated after deciphering outdated documentation and navigating foreign files or functions.
After a bit, I realized I had a superpower as a new person: a fresh perspective.
As a New Person™, I was running through setup instructions that hadn’t been exercised in a while. Moreover, stand-ups gave me the opportunity to ask my teammates to ELI5 about their (often cryptic) daily updates—which doubled nicely as a vehicle for information sharing. I was well equipped to look at a project, scratch my head and say, “Hm, there might be a better, more up-to-date way to do this!” (Or, maybe there isn’t and then, I got to debate the merits of both approaches).
The best part about all of this? I get to ask as many questions as I want and without having to worry about appearing like a rookie, or whatever (internal) narrative it is that might stop me from asking questions. Maybe effective teams are the ones that foster this safety for all its members.
So, as a New Person who is starting to become a little less new, these are some of the things which helped me when I got started—and all are things I hope to continue:
Update documentation as you go. (Also known as the Person Scout Rule , as I recently learned) Prune codebases by getting rid of unused files and functions. Write tests to learn the functionality of the codebase and improve test coverage along the way! Ask my team to explain services from the ground up—what database are we using again? Why are we not using X library here? Pair program with more experienced coworkers.
Most of all: ask tons of questions and then a few more, no matter how small. We could all benefit from remembering that being a New Person is an advantage. They can iron out sticking points, gut check a team’s assumptions, and make life for the next New Person all that better.