What Quitting Taught Me

I’m entering my tenth year in software development, having worked at about five or six companies over that time. Looking back at each moment I decided to quit, I’ve never regretted it.

I’ve never encountered a work environment that perfectly matched my ideal vision.

Instead, thoughts like “there’s no point staying at this company” or “would another company be better?” popped up often. And during the job hunt after quitting, I’d frequently look back and wonder, “What if I had done things differently back then? Would it have changed anything?”

There is no undo button in life. Every resignation carries valuable lessons and helps you gradually uncover your strengths. But before you quit, have you truly thought it through? As a frontline developer, I want to share some raw, firsthand experiences—both as a compass for my future self and as guidance for anyone wrestling with whether to leave.

Everyone pursues a different path in their career. Some enjoy navigating workplace politics and find fulfillment within corporate structures; others prefer freelancing to maintain lifestyle flexibility; still others choose an entirely different route, like entrepreneurship.

No single path is fundamentally wrong.

When I left one particular company, a younger version of myself once posted a 10,000-word essay detailing my experiences there, expressing gratitude to colleagues, airing grievances about the company’s systems, and sharing what I observed along the way.

That post was widely shared, eventually catching the eye of the company’s legal counsel. He even commented below it, remarking that the company excelled at taking people who were already disappointed and making them even more disappointed after they left.

Youthful impulsiveness is rare and precious, but looking back at who I was then, it definitely lacked maturity.

When I was younger, I believed technical skill was everything.

Now, I realize that when you feel you can focus peacefully on development, it’s not because you’ve become a rockstar or significantly better—it’s because predecessors made sacrifices.

They worked hard to set up the environment and establish proper infrastructure. Your manager shielded you from nonsensical requirements or took a midnight tongue-lashing from the boss on your behalf. You might never notice any of this, thinking instead, “Wow, I’m such a badass!”

Until the day you become the one getting chewed out by the boss in the middle of the night.

Quitting Is Not a Cure-all

I’ll cover situations where quitting should be a priority later on, but before making that leap, ask yourself which scenario you fall into:

• You want to escape because there are things in the workplace you dislike (emotional friction, stress).
• You know exactly what you want, and staying here won’t get you there.

If quitting is merely an escape from an imperfect environment, you will often find yourself trapped in the same loop at your next job. Inequitable resource allocation, inefficient communication, and interpersonal friction exist in every organization. These constraints are actually great opportunities for growth.

If your reason for leaving is a “bad environment” (e.g., an overbearing manager or chaotic processes) without ever trying to optimize workflows within that environment, you will still lack coping mechanisms when you encounter similar personalities or disorder at your new company.

I was once promoted to Tech Lead on a project, back when I didn’t yet know how to drive a project forward.

Technically, I had a firmer grasp on the stack than most on the team and plenty of ideas. But my communication was poor. I nitpicked my teammates’ proposals, often coming across as overbearing and difficult to work with.

Later, a colleague gave me some harsh negative feedback, stating that my aggressiveness severely harmed team morale—writing frankly that my behavior “pissed off” them.

In a subsequent 1-on-1, my manager earnestly reminded me that in the workplace, exercising influence matters far more. Honestly, I dismissed the feedback at first, constantly wondering why people didn’t care about code quality and why I was the one getting penalized. But merely taking your complaints to your manager brings neither change nor growth.

That was a major turning point for me. I began paying attention to the people around me, thinking about how I could help the team produce better outcomes. I also started diving into books on management and interpersonal relationships.

Without that reminder from my manager and that brutally candid feedback from my peer, I might never have changed how I work.

Values Are a Double-Edged Sword

Working in an environment perfectly aligned with your values is extraordinarily rare. In any workplace, there will always be things that frustrate you:

• Managers who only bark orders
• Office politics

We once had a requirement where, after a user navigated away from a page, an API call had to automatically delete an image. Naturally, sendBeacon came to mind, but for various reasons, sendBeacon couldn’t be applied to that specific scenario. Another colleague simply used ajax, which offers a sync parameter that forces HTTP requests to be synchronous.

Seeing that solution infuriated me. My immediate instinct was that no professional developer should ever propose such a hack.

Reflecting on it years later, my attitude and mindset were flawed. I hadn’t clearly explained why synchronous Ajax was problematic. Furthermore, their solution genuinely solved the problem at hand.

Through that experience, I realized that sometimes it’s not a clash of values—it’s that you never intended to understand their perspective in the first place. Those are two fundamentally different things.

Articulating What Feels Obvious

As developers with enough miles under our belts, we instinctively know the potential pitfalls of writing code a certain way. We can spot bugs just by glancing at a function, and we can visualize the architecture the moment requirements are laid out.

Environment variables shouldn’t live in Git history; manage them with a Secrets Manager; keep databases off the public internet; hash passwords; use SSR (Server-Side Rendering) to boost SEO; normalize relational databases.

These are “common sense” to developers. But can you clearly articulate the reasoning behind them?

In the book Peak: Secrets from the New Science of Expertise, the author notes that after viewing a chessboard for just five seconds, chess masters can recall the positions and moves of more than twenty pieces.

However, if pieces are arranged completely at random, the master’s performance is virtually indistinguishable from a novice’s. Masters rely on a vast accumulation of experience, intuitively chunking and deducing the game’s flow to aid memory.

Unfortunately, software development isn’t chess. Once you reach a certain seniority, you have to explain the reasoning behind your decisions to people who are non-technical or completely detached from tech. This demands taking what you view as obvious common sense and translating it into something others can understand.

You’ll find that things or feelings you take for granted are sometimes remarkably hard to put into words—or that you’re actively avoiding articulating them. Because translating thoughts, experience, and intuition into words forces you to confront the flaws in your own logic.

Why Do You Want to Quit?

Let’s do an exercise: Why do you want to quit?

You might start with a few general reasons:

• My boss is a jerk
• The pay is too low
• Misaligned values

Let’s make them concrete:

• “My boss is a jerk” → What makes them a jerk?
  • In the last project, I flagged potential risks to my boss, who brushed them aside. But when those risks materialized, the blame fell entirely on me.
  • Over the past month, my boss assigned me tasks outside my scope—like buying coffee or cleaning the restroom—more than 10 times.
• “The pay is too low” → What is your target compensation?
  • My target compensation is 20% above my current salary.
• “Misaligned values” → What is the gap between your values and what you observe?
  • From what I’ve observed, the company rewards lone-wolf heroics. When someone ships a feature quickly, the boss showers them with praise. Yet when someone writes documentation, shares knowledge, or improves deployment speeds, the boss doesn’t bat an eye. I value cohesive teamwork.
  • The company offers no employee growth or evaluation framework, and my onboarding suggestions were dismissed. I conclude the company favors plug-and-play cogs over building a sustainable, long-term team.

Framing issues with specific examples like this gives you far more actionable clarity.

Have You Tried Changing Things?

So you have the urge to quit, and you’ve broken down the underlying causes.

Looking at those reasons: assuming every single one could be resolved, would you still want to stay? If the answer is “yes,” have you actually tried to change them?

Here are a few questions to ask yourself:

• If the challenges and obstacles I face were resolved, would I want to stay here?
• Have I genuinely tried to solve these problems? Is this the absolute best effort within my capabilities?
• Looking 3 to 5 years down the road, can this place help me reach my goals?

When facing problems, it’s natural to default to blaming the environment.

In The 7 Habits of Highly Effective People, the author illustrates two circles: the Circle of Concern and the Circle of Influence.

The Circle of Concern encompasses everything you care or worry about; the Circle of Influence covers things within that circle that you can directly affect through your actions.

If we want to take control of our lives, we must focus on our Circle of Influence—the changes we can directly enact through action—rather than lingering in the Circle of Concern.

For instance, if you feel underpaid, have you gathered your courage—despite the risk of rejection or awkwardness—to negotiate with your boss? Have you laid out a case for why the company should give you a raise? What have you accomplished, and what business outcomes did it drive?

Have you told your boss, “I’d prefer not to handle these miscellaneous chores so I can focus on high-impact deliverables”?

If values diverge, have you raised that with your manager?

If you find the codebase painful to maintain, have you proposed an actionable refactoring plan, advocated for improvements, and convinced your lead why it matters?

If you’ve done all of this and found that nothing changes—tried again and still hit a brick wall—then it’s time to consider quitting.

Focus on what is within your power to change.

The Umbrella of Big Tech

Many people feel they’ve accumulated a formidable skill set and delivered numerous projects at their current job. But stripped down, it might just be that senior engineers or the CTO laid all the groundwork for you; you were simply clearing quests along a paved path.

At an established or publicly traded company, roles and boundaries are typically clearly delineated.

Need servers provisioned? The SRE team takes care of networking, permissions, and environments. They write automated deployment scripts and handle orchestration with Ansible and Terraform.

Feature development wrapped up? A dedicated QA team crafts test suites, executes them, and files tickets.

Sounds idyllic, doesn’t it?

The downside is that you become hyper-focused solely within your lane. When you move to a resource-strapped environment where you have to build everything from scratch, you stall out.

Suddenly, you feel overwhelmed by “busywork.” But it isn’t an excess of busywork; it’s that you’ve been living under a protective umbrella without ever trying to step outside it.

If you can’t point to something specific and say, “Because I drove this initiative, X change occurred,” you were essentially just a guest being catered to. Carry that tourist mindset into a new environment that demands true trailblazing, and you will suffer painful setbacks.

Climbing the Ladder: You Can’t Escape People and Organizations

Many developers view tech as the only thing that matters, dismissing politics as dirty and unethical. Yet the moment your desired impact exceeds your personal output capacity, you must achieve your goals through collaboration.

Wanting to write “clean code” or build “great architecture” won’t persuade people on its own. Demanding that others accept your proposals purely on the grounds of logical correctness is remarkably arrogant.

Interpersonal relationships and organizational dynamics are not distracting noise in your work; they are core parameters of the job itself. Dodging these challenges means forfeiting the opportunity to scale your impact.

I know developers have personal preferences, principles, and values they cling to. It’s difficult to lean entirely to one extreme, but what we can do is strike a dynamic equilibrium we can live with.

In Japan, there is a term called nemawashi (根回し), which refers to laying the groundwork before a meeting or formal decision—quietly consulting key stakeholders individually, gathering input, and aligning expectations.

By the time you present the proposal formally, building consensus is much smoother. As your projects expand in scope, you’ll need to develop an eye for these non-technical nuances.

Once, we had a project that required building a server-side rendering (SSR) setup from scratch.

Because our internal tooling had limited support and we needed dynamic data fetching, I proposed a new architectural pattern.

This architecture required cross-departmental coordination: SRE needed to provision and configure servers; product managers wanted to know the business benefits; developers needed to understand the technical blueprint. The actual coding wasn’t difficult—just deploying a Next.js server.

However, to align these cross-functional teams, I prepared extensive documentation tailored to each audience. With limited headcount, I had to simultaneously drive stakeholder alignment and implement the architecture myself.

Thanks to my manager’s support, completing that project earned me a substantial raise.

Employment = A Capitalist Game

Never quit with the mindset that “this company can’t survive without me.” That thinking is toxic.

Under capitalism, no one is irreplaceable to a company. In the open market, a replacement can always be found.

At its core, employment is an equivalent exchange of labor for capital, not a vessel for emotional attachment. In an organizational hierarchy, anyone’s function can be modularized and substituted—this is the inevitable result of capitalism’s pursuit of stability.

For yourself, however, joining a company represents a choice of values. The skills, trust, and network you build there are genuinely irreplaceable assets.

I once asked a founder whether he saw his employees as partners. Looking back, that question was naive—even if viewed as partners, the employer-employee relationship remains.

Because it is an employment relationship, a company’s survival boils down to two things: profitability and operational health. Teams do not exist to be each other’s buddies; they exist to achieve specific objectives.

Back then, I also asked: if an employee is sick or struggling, would you brush them off with corporate platitudes or genuinely care? I knew both approaches might produce the same external outcome, but deep down, I hoped a boss would genuinely care. That mindset was fundamentally mistaken.

The workplace was never meant to be a forum for exchanging heartfelt authenticity. A boss’s job is to keep the company afloat and deliver results, not to serve as an employee’s therapist or confidant. When a leader uses tactful communication to make employees feel respected and maintain morale without letting personal feelings compromise business decisions, that is professionalism.

Genuine affection sounds lovely, but it carries a price tag. When a boss gets overly emotionally attached to an employee, they hesitate during layoffs, pull punches during performance reviews, and show favoritism in resource allocation. That hesitation and favoritism ultimately harm the entire team—and even the company.

I shouldn’t have projected my own romantic ideals while ignoring the nature of employment: employees provide time and capability, the company provides compensation and a platform. When both sides execute their responsibilities well, that is the highest form of respect. What the workplace demands is not heartfelt sincerity, but getting things done.

Growth Comes from Pain

I wish upon you ample doses of pain and suffering. — Jensen Huang

Of course, everyone enters the workforce with their own motives and career ambitions—perhaps simply to earn a living while searching for their true calling.

NVIDIA CEO Jensen Huang once mentioned that he wishes pain and suffering upon people, especially those who grew up with abundant resources, great education, and supportive families—people burdened with sky-high expectations who could afford elite schooling. He noted that such individuals often lack resilience.

He believes truly great things aren’t necessarily achieved by the brilliant, but by those who have endured suffering. At first, I didn’t quite grasp this, but over time, it started making sense.

During college, I had very few resources. I couldn’t afford new clothes, had no budget for decent gear, and sometimes couldn’t even pay my phone bill.

Yet that financial hardship drove me. I wanted to master a skill, learn it fast, and land an internship as soon as possible.

That push allowed me to rack up software development experience while still in school, paving the way to pursue more technically demanding roles with much better compensation later in my career.

Later, when I stepped into Tech Lead roles, I was responsible for guiding teams, making decisions, and interfacing across departments. When you tackle these things for the first time, you don’t know all the nuances; you have to operate in high uncertainty with no playbook.

Moving into management introduces another dimension—whether dealing with people or team dynamics, you can no longer operate on the assumption that “as long as my code is solid and my output is high, good things will follow.” You have to figure out how to elevate the entire team.

None of these phases are inherently pleasant in the moment; they are often painful because they force you to change how you work and even reshape your values.

Yet as you make more decisions, solve more problems, collaborate with more people, communicate more with leadership, and see more projects through, navigating unfamiliar territory and pushing projects forward—though painful—yields tremendous growth.

You start recognizing project patterns you’ve seen before; you know how the architecture and stack should look. And to keep the project on track, you realize raw tech is no longer the most critical component.

How do you communicate with stakeholders? How do you convince them your plan is viable? How do you view things from their perspective? You gradually grasp that these once-overlooked subtleties are, in fact, the decisive factors that move projects across the finish line.

Growth is inevitably accompanied by pain.

When you feel pain in the workplace, ask yourself: Can this pain bring me growth? If it can, maybe you shouldn’t run away from it.

Pain falls into two categories: the kind that fuels growth, and the kind that is pure, unproductive friction.

I recently started running. Not because I love it—waking up early, running in freezing cold, pushing through when my heart feels like bursting and my legs are giving out.

It’s all painful. But I know logging those miles improves my health and cardiovascular endurance.

Every run is agonizing while it’s happening, yet I’ve never once regretted doing it. What I do regret is lounging on the couch doing nothing.

Pain that brings zero growth, however, is toxic.

It’s like showing up to play volleyball, only to discover the rules are baseball. Playing baseball by volleyball rules means you can never win.

The hard part is that in the moment, it’s hard to tell the difference. You have no idea whether the game is baseball or volleyball.

I once had a project abruptly shut down mid-development; my performance metrics evaporated overnight. Six months of hard work vanished into thin air.

Even so, if you want to grow, it’s just like running: you have to continuously accumulate discomfort. What used to leave you gasping for breath at a 9:00/km pace becomes an easy jog at 8:00/km. Only after you push through do you recognize the growth born from that pain.

Reflecting on the Workplace Through the FDE Role

Recently, I’ve seen the role of Forward Deployed Engineer popping up frequently (take OpenAI as an example). This isn’t a traditional Software Engineer or consultant; it requires deep technical chops to take a prototype, deploy it into production environments, and turn it into a real-world solution.

Here is the Job Description:

In this role, you will:

• Embed deeply with strategic customers to understand their business challenges and technical requirements in detail.
• Design, architect, and develop full-stack solutions using an experiment-driven, iterative approach.
• Prepare detailed scopes of work and project plans for both proof-of-concept prototypes and full production deployments.
• Work hands-on with customers’ technical teams as a technical expert and trusted advisor, coding side-by-side to drive projects to completion on their infrastructure.
• Collaborate with Product, Research and Applied teams to ensure seamless customer experiences, project success and actionable product feedback
• Contribute to internal knowledge bases, codifying best practices and sharing insights gained from customer engagements to scale the Forward Deployed Engineering function.

You’ll thrive in this role if you:

• 7+ years of professional full stack engineering experience (excluding internships) in relevant roles at tech and product-driven companies - customer-facing experience is highly desirable
• Former founder, or early engineer at a startup who has built a product from scratch is a plus
• Experience with relational databases like Postgres/MySQL
• Have a bias for action and willingness to work iteratively with your customers to deliver the right solution that solves their problem.

A typical Software Engineer’s role on a team is receiving requirements that have already been refined by PMs and designers, then implementing them.

A Forward Deployed Engineer works directly in front of the customer, observing their live operations, formulating solutions on the fly, building them, and driving them all the way to production.

This demands the ability to translate ambiguous needs into actionable execution, alongside building deep trust with clients.

You can imagine how much communication this entails: managing stakeholders, convincing them of your solution’s viability, and delivering the optimal approach under constrained resources and tight timelines.

It rarely fits neatly into your comfort zone or familiar habits.

You Don’t Have to Play the Corporate Game

Some might still disagree with this perspective.

Why should I exhaust myself trying to convince a department, manager, or executive whose values are completely alien to mine? It’s just too exhausting.

Closing cognitive gaps is exhausting, painful, and draining. If you want to move things forward at work but can’t persuade others, it simply means your communication and influence aren’t there yet. Cognitive gaps aren’t an excuse; there’s nothing to defend. That said, once you step outside the workplace playbook, feel free to speak your mind on things you genuinely disagree with.

You have every right not to play this game. You can look down on it, reject it. You can say: This is too exhausting; I want to be myself, focus purely on tech and code, and prove that technology will always win.

You can absolutely do that.

But once you choose that path, climbing the conventional corporate ladder will be tough. You will likely spend far more time searching for that rare company where leadership understands tech, respects engineers, has top-tier development chops themselves, and can pay well.

However, there is an essential caveat: opting out of the game is a valid choice, but refusing to play while simultaneously complaining about the outcome is another story entirely.

You cannot refuse to learn the rules of the workplace and then lament, “I’m a thoroughbred; why doesn’t anyone recognize my talent?”

That’s not being an unrecognized genius; that’s choosing not to step onto the track where you can be seen. There are no right or wrong choices, but every choice carries a price.

Signs You Should Quit Immediately

While I recommend thinking things through before resigning, here are a few indicators that warrant considering an immediate exit:

Severe Mental or Physical Toll

This might manifest physically as hormonal imbalances, insomnia, or loss of appetite; mentally, as chronic anxiety, depression, or an inability to muster energy for anything.

Once these warning signs appear, don’t tough it out—just leave. Physical and mental damage can be irreversible.

Mismatch Between Authority and Responsibility

You’re assigned a task where your manager demands you follow instructions to the letter without giving you room to maneuver, yet when results fall short of expectations, you bear the blame and scrutiny.

Broken Evaluation Systems

The company’s performance appraisal framework clashes fundamentally with your values.

For example, handing opportunities to inner-circle favorites rather than fostering growth, or lacking any evaluation mechanism whatsoever—leaving you with no idea what constitutes success or what the company expects from you. Even when you bring this up with your manager, you’re met only with vague platitudes.

Destructive Office Politics

Cliques where advancement hinges on personal closeness, nepotism, or family ties rather than merit, or environments paralyzed by overt inter-departmental warfare.

Workplace Harassment or Sexual Harassment

Pervasive harassment, bullying, or leadership that treats talent with indifference—ignoring employee feedback or acknowledging issues without ever taking corrective action.

Sometimes, an environment is simply broken. Structural flaws can rarely be fixed by an individual.

Conclusion

I’ve shared a lot of thoughts above, but there’s another way to look at it: knowing clearly what you want.

To some, a career is just a job—a paycheck that affords the space and resources to focus on what they genuinely care about outside of work.

Everyone envisions career success differently; you don’t have to chase endless promotions or relentless growth. Prioritizing stability and peace of mind is an equally valid choice.

So when reflecting on your career, start by asking yourself: What does work mean to you? What did you join this company to achieve?

The employer-employee relationship remains, at its core, a capitalist game. In this game, the individual starts at a disadvantage—you are always replaceable. But the skills, experience, relationships, and judgment you accumulate along the way are assets that cannot be taken from you.

Understanding this clearly matters far more than deciding whether to stay or go.

Whether you ultimately choose to stay or move on, I hope you make the decision that serves you best. And I hope this post offered some clarity along the way!