I have changed my job recently, and like all newcomers, I met adaptation difficulties in a new place. Last five years I have been working in one company and have been taking new people into the team. And now I happened to be in their place.

In this article, I want to share my thoughts and feelings about the job change. And also provide you with several tricks to onboard not only newly minted intern but also experienced veteran more effectively. There is a short description of my background: in this company I went from junior python backend developer to tech lead of a team of ten developers.

It is not a secret, that the more you work in one place, the better you understand the company's processes. You accumulate knowledge about a subject domain, best approaches to communicate with neighbor teams, infrastructure interaction ruses and other concomitant features of work in a particular place with particular people. And when a new member joins a team there is a long-long road in front of them to construct a similar context. During this complicated period the main team's task is to eliminate all obstacles and facilitate as much as possible.

But how can we do it? An obvious answer is to provide the newbie with documentation. Here are our deployment templates. Here you can find an everyday developer guide. This repo contains all test cases for your service. And, of course, we have a separate well-structured page with an architecture description. Despite the fact I worked in different teams and with a wide variety of projects, I have never met such situation. In most cases docs are missing or outdated. If you are lucky and you got a project with readme, I am pretty sure you will not find higher-level docs about the interaction between it and other microservices.

How often did you hear the phrase "code is the best documentation"? Agree with it. Only your code defines the application behavior on production. But a newbie will not say "thank you" if you left him one-to-one with a git repo. A master branch can't tell when services or web pages call a particular view. A code does not contain the intent of algorithm implementation choice. And what is the client path in an ancient monolith or a new application without load? Collecting all this information is a newbie's biggest challenge for the next several months. And the team can only wish them strength and patience. Also, it is a good idea to carry out a ritual of scaring away foreign hr and former colleagues offering juicy vacancies, is not it? Or we can come up with a better idea? First of all, let's honestly confess that described situation with the lack of docs is not exceptional. If you remember some of your work projects, you will agree with me. And we should learn to deal with it.

I don't want to say that you should not write docs. Do it! Keep it actual. Urge your teammates who think, that "obvious" features do not need comments. Remember, that feature became obvious for developers after they spent a few days implementing it. And maybe before that PO spent a week more investigating and writing a user story.

Unfortunately, all this work does not guarantee that docs are comprehensive. So, how in this case new team members will find out everything they need? In ancient times oral speech was the major way of transferring knowledge. And in our days developers are sharing a lot of info during conversations. That is why one of the greatest approaches to immersion in context is linking an old team member to a newbie. I'll call this kind person "buddy". Buddy becomes the best friend of the newcomer for one or two months. Answering endless questions, showing hidden logical subject domain rules, revealing pipeline secrets - buddy was born for these things! Also, it would be very helpful not only to communicate via slack but also to have a 10-15 minutes daily call. This activity is aimed to give your newbie a safe and convenient space for asking questions. It is not necessary to choose the most experienced person for the buddy role. It is much more important to be nice.

Another important point is the atmosphere of trust. Asking questions is normal. Nobody has to know everything. It is not a shame to ask for help. Realization of these ideas is crucial for healthy relationships in a team. Any of the following actions can be very harmful: a snide reaction to a question, a peremptorily discarding a suggested idea, or an attack on the wrong judgement. Practicing in the described behavior can lead this team member to being sure that generating ideas is useless. And instead of asking ten-minutes help session newbie will spend two days figuring out how to solve an issue. So, some empathy is necessary for every team member.

I am pretty sure, that after reading the last paragraph somebody will say something like this "well, we do not want to work with such a sissy". But we all feel vulnerable sometimes. And I choose to spend my mental strengths on solving work issues instead of building mental shields against possible colleagues' jabs. Finally, the nontoxic atmosphere is profitable not only for the whole team, but also for the company in general. It's worth to note nontoxic != undemanding.

So, buddy can help to facilitate newbie’s life for the first time. But probation remains to be a great stress for the employee. The next trick seems to be very effective. There is no need to do something new for its usage. Just plan new member sprint parts according to the following idea. And to understand it, please answer the next questions. What keeps you at your current job? Why don't you look elsewhere? Why have I been working at a single place for five years? It was interesting. Every stage of my journey was exciting: from my first microservice deployment to the tech lead position in the team which owns about one hundred microservices. I never got bored during the whole sprint. There were routine tasks, of course, but every two weeks I learned something new. Developer work brings pleasure in solving complex tasks. In my opinion, it is the coolest side of our work. And most people can feel interested for a long period of time if work goes well. Just remember what lessons you liked in school more than others. What games do you like to play now? I bet, you chose the ones that you do better than others.

Here is a little side story for you. Among all chores I prefer washing dishes. Why? My mom taught me it and praised me every time when I did it well. Tricky move, is not it? Praise became positive reinforcement which helped me try enough to master it. And when you are good at something it is a delight. And even now dozens of years later I still enjoy washing dishes so much.

And there is good news, you can use the same trick with your newcomers. Create for them bounded and clear context. Such conditions allow them quickly become useful. And team leaders will get a real occasion to praise the developer. In other words, you should find an opportunity for your newbie to succeed.

I tried to meet new developers with a little bit of everything. It was a bad decision leading to frustration and excessive fatigue. A small area of new knowledge looks much better. A newcomer can use it as a bridgehead for discovering neighbor projects and areas of the subject domain. One area of responsibility brings an easier way of mastering work duties. And after a well-done task you feel satisfaction. Exactly these conditions are necessary for a developer's comfortable environment.

Beware of entrusting the newcomer to develop a new project from scratch alone. It is a good way of creating the separate context, which I was writing about previously. But there is a problem. The new developer does not know a company's common guidelines and approaches, is unfamiliar with infrastructure characteristics, already created services and their needs. That is why the created solution could be torn off from other surroundings. And you will have to waste time fixing and fitting the new service to conditions of reality.

Here is specific advice to implement my recommendation. Find a project or its area which collected a backlog of several feature requests. And give these improvement or optimization tasks to your newbie. But be careful. You should not pick for this role any dead project. Because doing such work for the sake of work is very harmful to employee morale.

Several months ago I thought that all my tips are suitable only for the adaptation of a greenhorn. Seriously, does a mature veteran need all this stuff about buddy and special first sprints content? Give him any task and do not forget to ask about made architecture improvements after sprint, right? Well, my probation helped me to realize, that I was wrong. Adaptation to a new place was very complicated after five years in one company. And there is no opportunity to get rid of the greatest challenge. Nobody can dive into a new subject domain within a couple of sprints. Sometimes I just do not know what is right and what is wrong. I cannot predict what solution I should choose in this particular case. As a result, I can create a nice and robust solution with illogical behavior. And I have an extra portion of stress. In my previous job I was familiar with the work algorithms of all my team applications. Furthermore, I knew pretty well the global processes of the whole company. I could suggest a couple of alternative solutions for any new problem. And what now?

Please don't think that described tips are suitable only for people who adapt new employees. You can use them by yourself if you are switching jobs. Take the initiative! There is no buddy role in your company? Communicate with experienced colleagues. Taking a person into a team is not easy sometimes. But communication and knowledge sharing can lead to a better mood among team members. You can't deliver complex tasks yet and you feel unsatisfied because of this? Notice areas of technical improvements in projects, suggest and implement them. Create a wiki page with a feature description after understanding new piece of logic. Or even improve it to self-documented code. The whole team will say "thank you" and adoption will be more pleasant.

I hope the reading was interesting for you. I understand, that my tips are situational. But all of them go from a real-world experience. I can express the main idea of this article in one sentence. Job switching is complicated for a person with any background, and having difficulties is normal, but I am sure you can succeed with a little help from a new team.