Experienced Devs

Tip 1: Assuming you are starting work at a company that has a healthy culture, do not be afraid to ask for help! There's a lot to learn and it's going to take time to get up to speed. Don't freak out because you aren't slinging PRs like the rest of the team after a week.

However when asking for help, you should open with what you've done already to help yourself. It's important to respect your peer's time, so trying to optimize for efficiency and help them help you as much as possible.

Part of this is also not spinning your wheels and struggling for so long that they need to spend a ton of time helping digging you out of the hole you dug for yourself.

Tip 2: Next is it's important to pay it forward. Docs are super outdated and you got more current knowledge from a braindump from a more experienced engineer? UPDATE THE DOCS!

Tip 3: Once you find your footing, and ship some projects and get a feel for things, it's important to find your voice. If your most Senior engineer on the team proposes something, don't just follow it blindly. If you see a blind spot in the approach, please raise it! Ask questions!

Truly great senior engineers hate it when the team just rolls over and blindly accepts their proposals/architecture. They want feedback! No one is perfect or sees everything. They want the team's help to stress test the approach.

Tip 4: Make sure you keep an open dialog about expectations with your manager. Never assume your manager knows how you spend your time every moment of every day. Ensure you give your manager visibility into your "invisible work".

Examples of invisible work would be taking time to help a new hire. Having conversations with people on another team you depend on or who depends on you to come to consensus on an approach that is beneficial to both teams. Or something like updating documentation or spending time in meetings to review engineering designs, collaborating with product and designers, etc etc etc

Tip 5: Don't be a dick. Avoid being super defensive and assuming others are out to get you, embarrass you, or generally are operating in bad faith until they prove otherwise.

Tip 6: Respect what came before. You'll surely come across some seriously jank code, or a ton of tech debt, or poor approaches. Due to business needs of the time, crunch time, lack of resources, etc are often reasons people did what they did. They very likely know certain things are bad. Calling out bad code or architecture isn't impressing anyone. They know.

When identifying these things, start by asking for context. Come with solutions that are attainable. Calling out things without fresh ideas on how to solve these known problems is not helpful and a waste of everyone's time. Focus on approaches for how to fit fixing the problems into your team's resourcing.

Tip 7: Learn to communicate in a way that resonates with your audience. Try to understand their motivations and what matters to them. Saying that something sucks and we should rebuild in your preferred tech is not an argument. What's the value? How long would it take? What are the trade offs? How does doing this work achieve the businesses' goals?