[axegon_]

A few things off the top of my head, no particular order:

* Read the documentation. I can't stress enough on that.

* Don't over-engineer stuff. Keep it plain and simple. Remember - most of your co-workers will have a lot of experience and you won't be able to impress them with something revolutionary. Chances are, they've seen it and had it for breakfast a million times.

* Don't be afraid to ask, even if it seems like a stupid question. Especially if you get wrapped up in a big and complex project. Most people are aware that during the first 5-6 months, new developers are often a net loss to the company, regardless of their skills and knowledge - there is always and adaptation period. Use that to your advantage.

* Be __brutally__ strict about the working processes and don't try to re-invent the wheel. Application structure, naming conventions, pull requests, code review - stick to it no matter what(unless there is a very specific situation and you are instructed to do otherwise). I.e. if everyone on the team makes short commit messages, that explain the change and link it to the relevant jira, github, gitlab(or whatever tracking system they use) ticket, do the same. No need to write a 50 line commit message describing the change in all files. And vice-versa - if they do write 50 line commit messages, explaining every line of code they've changed, do the same.

* Pay close attention to the most experienced people and try to understand their thought process and mentally train yourself to be able to think like them. Their thought process might not be the most efficient in general and it might be something completely different in your next job some day, but if it's proven to work for that team/company, stick to it.

* When you are given a task, check or ask if something similar exists. If it does, go over it, see if there is something you can re-use or at least understand it's mechanics and keep it close to that.

* You won't be in a position to say no, but everyone is in a position to require further details if needed. Which is not to say you should freely jump over to a senior developer every 3 minutes. Rather spend several hours trying to clearly understand what needs to be achieved, organize your questions in relevant clusters. That may help you answer many of them yourself. Whatever is remaining, ask someone if they have 10 minutes, go have a coffee with them if needed. If your questions/concerns are valid and relevant and what you are expected to do makes no sense, they can step up for you or tell you who you should talk to.

Good luck!

[fsloth]

"Read the documentation. I can't stress enough on that."

There are lot's of production codebases with very little or no documentation, though.

"Don't over-engineer stuff. Keep it plain and simple."

This in an excellent advice.

"Pay close attention to the most experienced people and try to understand their thought process and mentally train yourself to be able to think like them"

Yes, this is similar apprenticeship. Just being able to work with talented people is an outstanding thing to have. On the other hand, if you are a junior contributor, but can't find the obvious master programmer around, that is a huge red flag that the organization is filled with mediocrity through and through and it probably would be best to work somewhere else.

If you actually feel you are the most talented programmer, and are confident of your skills, that is an important datapoint. If your organization does not value your skills in couple of years you should definetly move on.

[axegon_]

> There are lot's of production codebases with very little or no documentation, though.

Indeed. But the advise is equally as valid for libraries or frameworks used in a project, which as a junior developer, chances are you have very little experience with. Read those :)

> On the other hand, if you are a junior contributor, but can't find the obvious master programmer around, that is a huge red flag that the organization is filled with mediocrity through and through and it probably would be best to work somewhere else.

Also correct. That said, you can go through the history of the project you are working on and see who's done the heavy lifting, granted they are still around.

[_l8xu]

> * Read the documentation. I cannot stress this enough. Always something to read. But also important to compare the different functions to get the best result for something.

> * 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.

[axegon_]

> Tips on not be annoying but still have a good amount of messages and discussion with them?

This point refers to being observant. I.E. open up a ticket about a feature that's already been implemented, and go through the implementation, how did the developer go about implementing everything. Preferably a more recent one, as old ones might be something that was rushed through at an earlier stage of the development or simply legacy code.

> 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".

Double edged sword. Prototypes are a great thing when you are 100% sure you have plenty of time ahead of you. Otherwise they just become a "working" solution that sneaks into the codebase and goes to production with a "TODO: refactor" somewhere. Sooner, rather than later that bites back.

> So better collect for a bulk of questions and try to solve them in the meantime.

Bingo. And by grouping them together, some questions will answer some of the others. My advice - open up a text editor and write them down.