Some advice I like to give to new team mates.
Take your time
Seriously. It helps the team a lot if you bring a tiny contribution to the table that is executed well and doesn’t need to be reworked heavily. If, on the other hand, you try to solve too many or too complex challenges you might end up with a lot of half-assed code that rather increases the workload of the more experienced devs because now they have to figure out your intentions and make decisions, what to keep and what to rewrite. Nobody expects you to solve all problems in no time, so really, take a breath and take some time.
Ask early and often, but try for yourself first
You shouldn’t have to solve all problems on your own, that’s why you’re working in a team, isn’t it? So by any means, ask you coworkers for some guidance. Not only when you’re stuck and lost, but also when you’re not sure about the best way to choose.
Of course, you don’t want to keep your coworkers from doing their own work. So don’t just show up behind their backs every time a questions comes across your mind. Always try to solve an issue for your self first. Note the steps you’ve taken and how they didn’t work out. It saves a lot of time and headache when you can provide this information to the person you’re asking for help. Also it shows you took some initiative and tried for yourself.
It’s good practice to give yourself a timeframe to work on a new challenge before actually starting to work. There’s no concrete time rule for this. Personally I make the time I invest in working through the unknown dependent on the progress I make. E.g. if after 15 minutes of trying I’m exactly where I was before I tend to ask for help. If I made at least some progress I admit myself another half an hour.
Don’t be afraid of saying „I don’t know“
Nobody expects you to know everything. Because nobody does. Don’t pretend you know stuff just out of fear when really you don’t. Not only is it bad for your own mental health but it makes it difficult for your team to know what level of tasks you’re capable of. There’s no shame in not knowing. You’ll find out quickly that you team mates are eager to share their knowledge with you.
Look out for a partner to do some pair programming. You can learn a lot by looking over the shoulders of a more advanced developer, watching, listening and asking questions. And it’s not only you who benefits – your partners will will improve their teaching and are more likely to find quirks and issue in their code while explaining it. After all, in order to teach a certain topic one needs to have a solid understanding about it.
A team that’s worth being called a team is happy to help one another and spread the word. But if you’re asking the same questions over and over, event the most relaxed colleague will eventually run out out of patience. So make it a habit to take notes. Write down even things that seem obvious in the moment. You’ll be happy later. Personally, I like to keep a Work Journal in Evernote (referral link). Not only does it help me to recall things I tend to forget, but it’s rewarding to look back and see what I did all week, especially in times when it feels like I didn’t accomplish anything.