Starting your first developer position can be daunting. Even after a few years, switching companies can be stressful. Here are a few tips to make transitioning into a new team easier, especially focused on new developers.
1. Meet people outside the product/engineering team
You're going to be siloed for a lot of your job, working closely with designers, product managers, and other engineers. One of the best ways to feel integrated and understand the larger impact you are having on the team. Reach out to some salespeople or a support person. If you are in an engineering-dominated company (like a Google or Apple), reach out to someone on a separate engineering team (preferably not another engineer).
Ask that person to get coffee with you or if they want to eat lunch during your first week. Chat with them about what they like best about the company, what food places they like around the area, or where there favorite quite places are around the office.
2. Take some time to get your developer environment set up
A lot of the developers I know are pretty particular about their developer environment. Joining a new team and working on a new product is a great time to get your development environment set up the way you like it. You are already going to be less productive than normal, so take some time to try out that new tool or workflow you've been wanting to check out. Worst case, you hate it and it makes you a little less productive for your first week. No harm done!
If you are looking for some new tools, check out this community #discuss I put out a bit ago:
3. Write some code, make a commit
On every team I've ever joined, I've made it my goal to have committed code in the first week. It gives you a good win in your first week and something to share if your team has Friday retros or team shares. It doesn't have to be anything too big - maybe you fix a small UI bug or pick up a little performance improvement. A good engineering team will have a way of tracking new developer work. If yours doesn't, ask another engineer for some help finding something that meets the criteria of being small and doesn't require much knowledge of the app. Then you can suggest tracking those kinds of stories in the future for when new devs come on! Double win!
4. Leave on time
This is a hard one and a good team will make sure you do it. Don't stay late because you are the "newbie". That establishes bad habits. Unless you have a fun event to stay after for, I'd recommended leaving at the usual time. Even if there is another engineer that stays around much later, don't feel like you have to emulate that behavior. Establish a healthy balance between work and home. Make sure that working late is an exception, never the rule.
5. Work hard, but not too hard
This final suggestion ties directly into the last one. I've heard this recommended as working at about 60% effort your first week. Don't go all out. You have plenty of time to prove yourself and you definitely don't want to peak in your first week on a team. Slowly integrate yourself into the codebase, learn about the team dynamics, and spend some time just settling in. Then, once you are acquainted with the team, start ramping up your effort. It not only makes you look better, but it will help you and the team ease into you being involved.
This doesn't mean that you should produce low-quality work, but instead produce a lower quantity for your first week or so.
Hopefully these tips help! I'd love to hear your thoughts in the comments or on Twitter.
Top comments (4)
Also highly recommend becoming close with a Project Manager! They'll be able to help you navigate confusing flows, standards, or best practices - learning a new codebase is taxing enough, navigating office procedures shouldn't add to the stress.
Really love this post - the last 2 points are so important to hear as well as so many beginners feel liked they need to over-compensate by spending as many hours as possible.
It just sets an precedent that doesn’t work well long term and can set the dominos of burnout in motion.
If you're arriving at problems, and the company does not have a watertight solution for it, then do not take any responsibility for your failure to not deliver or pull request on time. If the problem persists, then consider leaving.
There is one more reason not to work too much hard during the trial period.
Usually we try to show our best during the trial period, and some of us work on the edge, trying to show > 100% of their productivity.
After the trial period ends - they "deflate like a ball", productivity falls and all the managers and colleagues are having questions.
So, do not overwhelm yourself!
Do your best but don't act like a fanatic.