> * Don't overdevelop things. Keep it simple. Remember - most of your employees will have a lot of experience and you won't be able to impress them with anything revolutionary. Chances are that they saw it and ate it millions of times for breakfast. But also important to not use a package for every little thing. I personally experienced many that e.g. in the NodeJS ecosystem, use huge packages to use a minimal set of functions or someone can easily copy from Stackoverflow which just makes the project more overcomplicated. Just a single package not updating can fck everything up.
> * Don't be afraid to ask, even if it seems like a silly question. Especially if you are involved in a large and complex project. Most people are aware that new developers are often a net loss for the company in the first 5 to 6 months regardless of their skills and knowledge - there is always an adjustment phase. Use that to your advantage. Above all is asking questions in the first weeks starting a new job. Else it is just stumbling around through the project.
> * Be __brutally__ strict about work processes and don't try to reinvent the wheel. Application structure, naming conventions, pull requirements, code review - stick with it unless (there is a specific situation and you are instructed to do something else). That is, if everyone on the team creates short commit messages that explain the change and link it to the appropriate Jira, Github, Gitlab ticket (or the tracking system they use), they do the same. There is no need to write a 50-line commit message that describes the change in all files. And vice versa: if you write 50 line commit messages and explain each line of code you changed, do the same. It is important to expect at least some knwoledge from the developers not to explain everything, because good naming already makes the code so easy to read, like a book. But, Magic lines need to be explained often with more than one line.
> * Pay close attention to the most experienced people and try to understand their thinking process and train yourself mentally to be able to think like this. Your thought process may not be the most efficient in general, and it could be something completely different for your next job someday, but if it turns out to work for this team / company, stick with it. Tips on not be annoying but still have a good amount of messages and discussion with them?
> * When you receive a task, check or ask if there is anything similar. If it does, go through it, check for anything you can reuse, or at least understand the mechanics, and keep it close. And always automate if something takes longer or is a recurring thing. Whats your opinions on prototypes? In terms of how functional they should be. Personally I build prototypes just to work and show the general concept, but could not be used by clients for "production".
> * You won't be able to say no, but everyone will be able to ask for more details if needed. That doesn't mean you should switch to an experienced developer every 3 minutes. Rather spend several hours understanding clearly what needs to be achieved and organize your questions in relevant clusters. This can help you answer many of them yourself. Whatever is left over, ask someone if they have 10 minutes and have a coffee with them if necessary. If your questions / concerns are valid and relevant and what is expected of you makes no sense, they can stand up for you or tell you who to talk to.
So better collect for a bulk of questions and try to solve them in the meantime.