We’ve probably all been there – coming home from work exhausted, maybe even a bit cranky, without an ounce of energy to do anything other than just crash and tune out for a while. After a rough day, that’s completely normal. But if you’re feeling this way even after relatively quiet days at the office, it might be a warning sign that something is off.
I started noticing this about myself last summer. Whether it was a good day or a bad day at work, I always came home feeling down and drained. I had been on the same project for three years, and with few exceptions, we were solving more or less the same software issues across different devices, so the work was getting pretty routine. On top of that, we were working with outdated tech.
The only thing that ever changed was the atmosphere on the client’s side — and unfortunately, not for the better. You could feel the growing uncertainty surrounding today's challenges, along with the tendency of certain corporates to make impulsive decisions — well-intentioned, sure, but lacking proper risk analysis.
All of these factors led to my decision to ask for a project transfer. I knew it wouldn’t happen overnight, but just having that light at the end of the tunnel made those final weeks and months on the project much more bearable.
Riding Two Chairs Laptops at Once
Time flew by, and anticipation quickly turned into reality. Excitement was mixed with nerves and a fear of the unknown, because I was leaving my familiar comfort zone.
So, while I was wrapping up and handing over my final tasks from the old project on one laptop, I was setting up my development environment on the second one — installing clients for Git, Docker, and Node, adding all my Visual Studio extensions, and repeatedly assuring Microsoft Authenticator that yes, it really was me trying to log into the device.
Of course, this also came with the usual "info-dumps" about the new project. Jumping onto a moving train is never easy, but I have to give credit to the new team — basically everything was written down and documented somewhere, which made the transition so much smoother. Even though I occasionally struggled to find my bearings because the materials were scattered across GitHub, Loop, and Teams, there was always someone ready to point me in the right direction.
Developing in a devcontainer was also a massive help (and a first for me), as it automatically handled a lot of the initial setup headaches and dependencies. With that out of the way, I could confidently dive into my very first assigned ticket.
A Complete Shift
This meant finally getting to work with the modern technologies I had been looking forward to so much. Suddenly, I was working in the latest .NET 10 instead of the ancient .NET Framework 4.8. I also get to level up my frontend skills, refreshing my experience with Angular and deepening my knowledge of another tech stack.
Another novelty for me is working on a project with actually functioning processes. On my previous project, code reviews were minimal and pull requests were nonexistent. It was basically: "If it runs somehow, just merge it." Naturally, that breeds insecurity and triggers a massive case of impostor syndrome. You start asking yourself: Is my code actually good enough? Did I bring over bad habits from my old project? Are my skills up to par? Am I just going to hold the team back?
The truth is, you won’t find the answers to these questions until you open that first pull request. Of course, it came back with feedback — whether it was about sticking to the architecture, project structuring in the repository, or just method naming conventions. No one likes being told they did something wrong. But it’s crucial to remember that this isn't a critique of your work; it’s a guide on how to make the final product as high-quality, clean, and readable as possible.
Stand-ups and grooming sessions were also completely different. At stand-ups, people didn't just talk for the sake of talking; we addressed specific issues. Similarly, grooming was always highly focused on what actually needed to be done, rather than just hearing: "Here’s the backlog, grab whatever you want."
Suddenly, what used to be boring bureaucracy turned into productive meetings that actually made sense. We could easily coordinate on things like who was going to rebase onto whom or follow up with someone if a Teams message had gone unanswered.
For the first week or two, I mostly just listened in meetings to absorb as much information about the application as possible. This helped me contextualize the incoming pull requests, which I used to study the team's coding style — especially on the frontend, where I didn't have much prior experience.
On top of that, the timing of my move perfectly coincided with the massive boom of Claude AI language models. Claude became my go-to partner, not just for coding, but initially for explaining logic, dependencies, and handling all those "dumb questions" you don't want to constantly bother your colleagues with. Not that I stopped asking them about things that were maybe obvious to them, but the copilot definitely cut the number of questions down significantly.
Lessons Learned
Even though it wasn’t always a walk in the park, I was thrilled about the change. Most of all, having a normal, functional team completely turned my mood around—both during work and after work, wiping out the feelings of burnout I’d been dealing with.
However, this new project had a hard deadline which, by the time this article is published, has long since passed. So, in the near future, I’ll be going through this whole process all over again. But I don’t regret my decision for a second, and I’d do it again in a heartbeat!
I got to experience collaborating with new colleagues, working with different technologies, and dealing with a slightly different style of project management. Most importantly, I feel (subjectively, at least) that I’ve grown more in terms of knowledge over these few months than I did during my entire last year on the old project, where I had perhaps become a bit too comfortable. I’ve gained invaluable experience that I can leverage on future projects, meaning I won't be nearly as anxious about fitting in next time.
Now I know that pretty much every developer feels like a fraud when they start a new project. Onboarding simply takes time, and nobody hits their full feature-delivery speed in the first few weeks compared to where they’ll be two months down the line. Change isn’t something to be feared. On the contrary, it’s exactly what opens the door to a wealth of new experiences.
