DeveloperBlogs

Why Comfort Zones Stall Growth: A Developer’s Case For Change

Comfort can quietly temper growth. Here’s what happened when I left behind a familiar environment, and why I’m better for it. 

As a software engineer, change is a key part of our everyday experience. We grow and thrive in a changing environment. However as individuals, we often find that we favour comfort over change. During my first three years as a software engineer at a hyper-growth startup, roles shifted weekly, priorities pivoted overnight, and architecture evolved faster than I could keep up; yet personally, I clung to familiarity - familiar tools, people and patterns - afraid to ask ‘stupid’ questions, of getting things wrong. The fear of the unknown which I felt was keeping me safe was actually cutting me off from the greatest opportunities for growth. 

It’s a paradox: we build software for change, yet resist changing ourselves. This resistance isn’t just about staying at a company, it’s avoiding hard questions, sticking to the same patterns, or deferring to senior engineers instead of owning decisions. 

Since joining Codeweavers 3 months ago, I have seen first-hand that changing environments accelerates growth in ways that staying put cannot. 

The Fear That Holds Us Back 

My biggest concern with moving on from my first role wasn’t just leaving behind familiar faces and friends – it was confronting the technical unknown. After three years developing in a specific tech stack and domain, the thought of starting fresh with new languages, frameworks, and architectural patterns felt daunting. 

I worried about stepping into a codebase where I couldn’t immediately contribute. What if they used technologies I'd never seen before (spoiler: of course they do)? What if their coding standards and practices were completely different from what I’d learned? This fear of appearing technically incompetent and not being useful was paralysing. 

There was also the concern about domain expertise evaporating. I’d spent years building up knowledge about specific business logic and operating with entirely different systems. 

This comfortable expertise I’d built felt fragile when faced with an entirely new technical system. But here’s the reality: each fear, when confronted, had a flip side that turned me into a better engineer. 

Adapting to a New Domain 

As I entered this new environment and domain, it felt easy to be overwhelmed by the amount of new information I was expected to absorb. But it’s important to remember: that knowledge isn’t lost, it’s repurposed. Many of your skills like debugging, communication, and architectural thinking, retain and even gain value in a new setting. You’re bringing approaches and perspectives from an environment which is different to that of your new team; your diverse experience lets you see their challenges through a fresh lens, often uncovering new opportunities. 

You're not starting from zero. You're bringing insights and approaches from a different world. That cross-pollination, when done respectfully, can add significant value to your new team. 

Knowledge Shared Amongst Great People 

Passionate, smart and friendly people are everywhere. When I met my team in the first week, it was clear that I was going to learn a lot from them. Our early conversations surfaced fresh perspectives on code quality, design trade-offs, and system reliability - many of which challenged ideas I hadn’t realized I was holding on to. 

Coming from a lower-risk engineering environment where we could iterate quickly and recover from issues without major customer impact, I was accustomed to a certain level of acceptable risk in deployments. My new colleagues showed me how different the stakes were when working on critical infrastructure where downtime directly affects key customer operations. Testing and monitoring became crucial, rather than a nice-to-have or an afterthought. 

Similarly, my experience with systems that could afford some experimentation brought a different perspective to their more cautious approach. The combination of agile problem-solving with production-critical reliability created a richer toolkit than either approach alone. 

I learned how to interact and form bonds with new engineers, and reconcile their opinions and skills with my own - not by choosing one approach over another, but by understanding when each perspective adds the most value. 

Building Trust Before Technical Debate

Before you can jump into deep technical discussions or start suggesting changes, it's crucial to build trust with your new team. That means getting to know your colleagues, not just their roles, but their communication styles, values, and boundaries, all essential in a team of software engineers. Strong professional relationships create a safe space for the kind of healthy, challenging debate that helps teams grow. 

Early on, we got into a heated discussion over nullables vs. default values. I was too eager to argue that nullables were clearly the better option and should always be used, which caused some friction with my new teammates. In hindsight, I hadn’t taken the time to understand the reasoning behind the team’s preference for defaults - especially in systems where predictable behaviour under load is critical. Challenging and debating are great skills for an engineer to have, but I missed the mark on balancing them with relationship building. 

That conversation taught me the value of observing over trying to be useful in the early stages of a new role. Rather than leading with “what if?” it’s often better to start with “why?” Asking that builds both understanding and trust, and ultimately makes your contributions more thoughtful and impactful. 

Creating a New Knowledge Bank 

In my time at Codeweavers, I've learned to balance hyper-growth agility with enterprise stability. New practices, technologies, and systems are exciting, but integrating them into a critical space isn’t always simple. Balancing these two facets of Software Engineering is a welcome challenge - in my first project we were able to implement some newer concepts and enhance the existing implementation without detracting from the customer experience or timeline. The success in proving to myself that I can adapt and contribute in a new environment has helped me battle the imposter syndrome that comes with entering an unknown environment. 

I now see Software Engineering as less of a playground for implementing new technology and paradigms (which themselves are constantly changing), and more as a customer-focused practice which must balance staying up-to-date with prioritising user needs. 

Stepping Beyond the Edge 

Leaving a comfortable role wasn’t easy, it never is. But growth rarely happens within the boundaries we draw to feel safe. What I’ve learned is that change doesn’t diminish what you already know; it sharpens it, challenges it, and ultimately expands it. 

In stepping into the unknown, I didn’t just become a better engineer - I became a better teammate, a better learner, and a more confident contributor. The fears I had were real, but they were also temporary. What’s lasting is the sense of progress that comes from choosing growth over comfort. 

Author: Adam Hulme

Backend Software Engineer

Codeweavers

Read more by Codeweavers