I worked in the e-commerce industry for more than 10 years, starting from frontend development to leading teams. In the end, I have realized that instead of doing what I truly love- writing code that solves problems - I have spent my time on moderating meetings, filling sheets, and creating Jira tickets. When my friend told me that Docplanner was looking for a **software engineer**, I started seriously considering returning to hands-on programming. The position was interesting for me because I could: 1. Return to **hands-on development.** 2. Work on a fresh stack (.NET/C# instead of Node.js). 3. Solve problems in a completely new (for me) business domain — healthcare instead of e-commerce. I had nothing to lose. I made a new CV and sent it. The recruitment process was quite difficult for me, but I did it. I got a job offer and I accepted it. But, to prepare better for the new challenges, I decided to take a **month off** from finishing my previous collaboration with Alokai to start a new one with Docplanner. Press enter or click to view image in full size  ## Preparation I knew I needed to prepare. **It was hard for me to code at all,** even in well-known technologies that I worked with daily, like NodeJS/Vue. It’s truly shocking how out of practice you can get after 3–4 years of being a tech/team leader. So, I started to think — how to prepare best? For starters, I bought three books, but I actually didn’t read them — only one “Learn C# In One Day and Learn It Well”, but it was short. Also, I tried a Udemy course but dropped it in the middle, as it was incredibly dull. What worked like a charm? **I just wrote some code in C#**. That’s it. Also, I created a project in Claude that helped me understand C# features from a NodeJS perspective. Like this: My message: Press enter or click to view image in full size  AI assistant answer: Press enter or click to view image in full size  It also showed me implementation in JS: Press enter or click to view image in full size  Screenshots show a trivial example, but this assistant was helpful in learning. It helped me identify the gaps in my knowledge and adapt to the best practices. Or, at least, acceptable practices. ## Onboarding When I started at Docplanner, I was very warmly welcomed and received an impressive onboarding checklist. I had time to meet people and the team. Then I started learning about the company, products, technology and history. Actually, it was my first job in my whole career and **nobody expected that I would write code from the first day**. I had time for everything needed to onboard to the company. Also, I had a buddy who showed me a lot and answered all my questions. ## Observation After the first onboarding tasks, I felt I could start contributing. But, actually, I needed to hold my horses! I tried to understand the project, workflow and technology. To do so, I have reviewed others' code, pull requests. I did listen to daily standups and tried to understand what was going on. One of the biggest topics for me was understanding the approach to “how to code” in .NET projects. As a NodeJS programmer, I was not used to patterns like clean architecture and CQRS. Adapting to these and other patterns/principles was a little bit tricky because it required a **mental shift.** ## First contribution My first pull request was intentionally small. I added some improvements to the local Docker setup. After this, I started working on my first feature. My approach was to create a PR, even it was 100% wrong, and get feedback from others and iterate. It perfectly showed that **in the engineering world, a pull request is the easiest form of communication.** ## Total fun After approximately one month, I started to feel quite confident and guess what? The most experienced engineer on the team began a three-week holiday. At the same time. We kicked off a new project. The timing couldn’t have been more challenging. I found that I can use skills from my previous job as a tech leader. - Breaking big problems into **smaller ones** - Designing the tech aspects of a project - Finding the shortest way to **prototype**/MVP - **Explaining** to others how the solution will work It helped me to start work on the new project as a backend engineer and to cooperate with a frontend developer. I felt we had good progress and what we do makes sense. Press enter or click to view image in full size  ## Expected-unexpected benefits of a new role On one hand benefits I describe below are expected, but on the other hand, when I realized them, I felt something like “**AHA moment**.” I told to myself, “WOW, it’s nice and it's something that I looked for. Why did I not change the job earlier?” ### 1. Freedom from meetings Suddenly being an attendee rather than a facilitator was awesome. I hadn’t realized how much my mental energy moderating meetings had consumed. ### 2. Focus on depth rather than breadth As a tech leader, I developed broad but shallow knowledge across many areas. When I return to an **individual contributor** role I could develop deep expertise in specific areas again — something I had missed. ### 3. 100% technical independence I felt again that I have 100% influence on how to do something and how to solve the problem I am working on. I like this feeling when I know that solving the case is only **a matter of time** and **going deep enough into the details.** ## Challanges The first one was about feeling like a junior. Despite my experience, sometimes it was hard to understand the code, the architecture on a code level, etc. Especially when s**truggling with framework-specific issues**. I tried to prepare myself and learn some .NET and C# stuff, but the real learning starts when you have to write production-ready code under time pressure. ## What can I advise you on when you start a new job? (The order doesn’t matter; all tips are on the same level) ### - Build relationships Technology is important for engineers, but when you work in a team, **People are more important** (it’s not obvious for all of us, really). I got advice that I should take my time and meet people. Actually, it was hard for me, but I spent time talking with people and typically these talks were very interesting! Build relationships, this is how to onboard perfectly. ### - Prioritize code review I wanted to write some code. I thought I would be able to write code from the first day of work. I didn’t but I spent a lot of time **reading others’ code** and doing code review. I learned a lot. Prioritize code review, this is how to onboard perfectly. ### - Start small I wanted to build big things and show how good I am. Nice idea, but a better idea is to start easy. **Refactor** some code. **Improve** dev tooling. **Fix** bugs. From time to time, do more complex things and grow organically. Start small, this is how to onboard perfectly. ### - Be curious When I saw .Net code, I didn’t understand too much. When you look at something new, you can have the same feeling. You can like something and not like it. And you have two options: complain or be curious. **Ask “why?” Go deeper. Ask “why” again and again.** Be curious, this is how to onboard perfectly. ### - Be patient Patience is a useful virtue in both life and coding. People also says that Rush is a bad advisor. You can rush and scrap the production. You can be patient and be sure not to screw up. You can wait for the code review. You can tune in to someone and at least have time to meet. **Patience does make sense.** Be patient, this is how to onboard perfectly. ### - Be nice Last but not least (I hate this sentence. Actually, why do I use it here???) Be a nice person. **Nobody wants to work with jerks**. Be respectful, and think three times before you say something stupid. Listen more than talk. Be nice, this is how to onboard perfectly. ## Conclusion Onboarding into a new job and role can be demanding. Each of us goes through it individually and has our own needs and challenges. What is definitely important is our attitude. It is good to use this new beginning as an opportunity to meet new people, learn something different, and look at something familiar from a new perspective. **I hope that as you go through your onboarding, you use it in this way.** --- *Published: 03/27/2025* #blog #CareerTransitions #SoftwareEngineering #TechLeadership #ProfessionalDevelopment #OnboardingProcess