Newly hired software engineer, are you doing these six things?

📣 Newly hired software engineers!

Congratulations! 🎉

You’ve worked hard to get the job on a large team, so kudos to you! But, now the work begins. I'm working on an amazing team and have been learning so much. I've only been working within an enterprise-level company for a short time, but I've learned these six things so far as a new hire as I've gleaned things from team members and mentors outside of work.

Take it easy on yourself 😅

Typically, it takes at least six months before a new hire is fully acclimated and ramped up to become a contributor. Sometimes it could take a whole year. Don’t be too hard on yourself when you don't understand something. That's normal. Just utilize the time you have, and don’t feel like you're expected to know it all.

Ask for help from Senior Engineers 🙏

When you're blocked for 30-60 minutes after all your Googling and understanding have been exhausted, it’s time to ask for help from another newly hired person and/or a friendly senior team member. Go ahead and admit that you don't know and need help. Someone on the team is smarter than you at that moment. There’s no shame in not understanding as a new hire. If you're the smartest person in the room as the new hire (or at any point for that matter), then you're probably in the wrong room. Maybe you needed to ask one person, who led you to another person, and another person, but in the end be kind, yet persistent in tracking down the answer.

Identify ”bus” people 🚌

You might be wondering what is a "bus" person? What if one of the most knowledgeable people in your company was hit by a bus, would business as usual come to a halt until that person returned or a replacement was trained or found? That person was a "bus" person. Know who the most knowledgeable people are on your team. Before too long, you will know exactly who they are anyhow because they seemingly answer all the questions and your team members each say, "Go ask so and so".

Seek additional time ⏳

After noting your team’s ”bus” people, then collect your questions and seek an available time to meet with them, specifically. Aim to pair program with them where you're stuck and give them the chance to help you. Alternately, bring a list of questions and allow them to review the shortlist and provide feedback. Seek to develop a friendly relationship. If you have value to offer them, then seek to reciprocate. Get to know them. Get to know what has helped them succeed. Learn from them and if inside the scope of your work, aim to become an unofficial understudy. Learning from this person can alleviate the "bus" factor of that person.

Taking it a step even further, seek 1:1's with every member of your team and the ancillary team members. Take notes and listen. Find out the holes in the onboarding process and learn as much as you can. Everyone on the team has a super power and something to offer—even the most junior and/or non-technical people teammates.

Review your company's docs 📄

Maybe you learn best by reading before reaching out to others, well, either way, it’s a really good idea to read your company’s docs before and after asking for help. I’ll provide two reasons why.

First of all, you’re reading the knowledge straight from the source of creators and maintainers that have gone before you. They’ve struggled with these technologies and have oftentimes mastered them.

Secondly, you're gaining technical sophistication, as well, through getting comfortable with documentation. Going to the docs is sometimes a little like reading between the lines. Sometimes, it's usually fairly logical and structured, but other times the writer is assuming a baseline of knowledge. Something you might begin to notice is that specific documentation is outdated or has gaps. This leads me to my next point.

Enhance the docs yourself ✍️

Find these outdated or gap places and improve them—reference your notes from 1:1's and training. Contact the creator of the documentation and let them know about your question regarding the docs. They might have the willingness to give you credit for your contribution, or they might even give you the right to edit the document directly. In an opportune situation, they might ask you to help re-write the section or all the documentation leaving your stamp in the company docs. Not only would this bring value to you, but it could also reduce the headaches for your entire team and new hires in the future. You could gain a positive reputation as a contributor to the company docs.

As a review, don't be hard on yourself, ask for help, find the experts, seek time with them, and go to the docs enhancing them where you can.

Thanks for reading my post, but many of these words are not my own and are paraphrases of my seniors that are kind to share their knowledge with me. Thank you specifically to Adam Fisher, Alex Wright, Rich Smith, Taylor Desseyn, Dan DiGangi, and Conner Bush for sharing your insights.

If you know of other wisdom, then please drop those in the comments below.