The Things Quitting Taught Me

It’s been about ten years since I entered software development, and over that time I’ve worked at five or six companies. Every time I decided to quit, I never regretted it.

I’ve never worked in a workplace that perfectly matched the environment I had imagined.

Instead, I often found myself thinking, “This company isn’t really worth staying at,” or “Would another company be better?” And after resigning and starting to job-hunt, I’d often look back and think, “If I had done things differently then, would things have turned out differently?”

There are no second chances in life. Every resignation teaches us plenty, and slowly helps us understand the strengths we can play to. But before you quit, have you really thought it through? In this post, I’ll share some hard-earned lessons from the front lines as a developer, as a guide for my future self and in the hope that it helps anyone who has ever felt torn about whether to leave.

Everyone has different career goals. Some people enjoy playing the workplace game inside a company and find greater fulfillment in corporate life; some prefer freelancing and keeping their lifestyle flexible; others choose a completely different path, like starting a business.

None of these paths is completely wrong.

When I left one company, I was still young and once wrote a 10,000-word article about my experience there, my gratitude toward my coworkers, my dissatisfaction with the company’s systems, and what I later came to see.

That article was shared many times, and even the company’s legal team saw it. One of them even came to comment under the post, saying that the company’s specialty was making people who were already disappointed with it become even more disappointed after they left.

The impulsiveness that belongs to youth is precious, but looking back at that version of myself, I seem rather immature.

When I was younger, I often thought technology was everything.

But what I feel now is that the reason you can focus on development with peace of mind is not because you’ve become more capable or better yourself, but because of the sacrifices made by those who came before you.

They worked hard to set up the environment and build the infrastructure. Your manager shielded you from meaningless requests, or got yelled at by the boss in the middle of the night. You may never notice any of that. You just think, “Wow, I’m amazing!”

Until you become the person getting yelled at by the boss in the middle of the night.

Quitting Is Not a Cure

I’ll mention situations later that should make quitting a priority, but before you resign, you can first think about which of these situations you’re in:

• There are things in the workplace you dislike (emotions, stress), and you want to escape
• You already know exactly what you want, and you feel staying here won’t get you there

If quitting is only about escaping the imperfections of your environment, you’ll often fall into the same cycle in your next job. Any organization will inevitably have uneven resource allocation, low communication efficiency, or friction. These limitations are actually good opportunities for growth.

If your reason for leaving is “the environment is bad” — for example, your manager is too domineering, or the process is chaotic — but you haven’t tried to improve the process in your current environment, then when you encounter a similarly controlling person or a similarly chaotic situation at a new company, you’ll still lack the tools to deal with it.

In one project, I was promoted to Tech Lead, and at the time I didn’t know how to drive project progress.

I understood the technical side better than most people on the team, and I also had more ideas. But my communication style was poor. I nitpicked my coworkers’ proposals and often made people feel that I was very domineering and difficult to work with.

Later, a coworker gave me an extremely harsh negative review, saying my aggressiveness would seriously damage team morale. He directly wrote that my behavior pissed him off.

After that, I had a 1-on-1 with my manager, who also seriously reminded me that in the workplace, influence matters more. To be honest, at first I dismissed this feedback. I often thought, why does everyone seem so unconcerned with code quality, yet I’m the one getting negative reviews? But if you only report your dissatisfaction to your manager, nothing will change and you won’t grow.

That was a major lesson and a big step in my growth. I started paying more attention to the people around me and thinking about what I could do to help the team produce more. I also began reading books related to management and interpersonal relationships.

If my manager hadn’t warned me, and if my coworker hadn’t given me such a heavy negative review, I might never have changed the way I worked.

Values Are a Double-Edged Sword

It’s hard to work in a workplace that perfectly matches your values. There are always a few things in the workplace that make you unhappy:

• Managers who only tell people what to do
• Office politics

Once, we had a requirement: after a user left a page, the system should automatically call an API to delete images. Naturally, we thought of using sendBeacon, but for some reason sendBeacon couldn’t be applied to that scenario. Another coworker directly used ajax, which provides a sync parameter that can force the HTTP request to be synchronous.

When I saw that solution, I was furious. Because instinctively I felt that this was absolutely not a solution a professional developer should propose.

A few years later, I reflected on it, and realized my attitude and mindset at the time were bad. Why hadn’t I quickly brought up why using Ajax with sync was a problem? And in fact, the solution that developer proposed really did solve the immediate issue.

Through this case, I realized that sometimes it’s not about incompatible values at all — it’s that from the beginning, you never really wanted to understand the other person’s thinking. Those are very different things.

Putting the Obvious into Words

As developers, after doing this for long enough, we usually know what potential problems come with writing code a certain way. We can look at the implementation of a function and tell where a bug might be. We can hear a requirement and roughly picture what the architecture will look like.

Environment variables shouldn’t be committed to Git history, use Secrets Manager to manage them, don’t expose the database to the public internet, passwords should be hashed, use SSR (Server-Side Rendering) to improve SEO, normalize the database.

Can you explain the reasons behind these developer “common sense” principles that come so naturally to us?

In Deep Work, there’s a mention that chess masters can remember over 20 pieces or moves five seconds after seeing a board position.

But if the pieces are placed completely at random, there’s no significant difference between masters and beginners. That’s because experts have accumulated so much experience that they can rely entirely on intuition to infer the flow of the game, which helps memory.

Unfortunately, development isn’t chess. Once your position reaches a certain level, you may need to explain to people who aren’t technical, or don’t understand technology at all, why you do things a certain way. That requires turning what you take for granted into something others can understand.

You’ll discover that sometimes the things or feelings you take for granted simply can’t be put into words. Or perhaps you’re avoiding putting them into words. Because turning your thoughts, experience, and common sense into text 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 can start by listing a few reasons:

• The boss is too difficult
• The salary is too low
• The values are different

If we make those more concrete:

• The boss is too difficult → What does “difficult” mean?
  • In the last project, I reported possible risks to the boss, but he didn’t take them seriously. When those risks actually happened, he blamed me for them.
  • In the past month, the boss assigned me tasks outside my role, such as buying coffee and cleaning the bathroom, as many as 10 times
• The salary is too low → What is your ideal salary?
  • My ideal salary is 20% higher than my current salary
• The values are different → What’s the gap between your values and the values you’ve observed?
  • Based on what I’ve observed so far, the company tends to encourage individual heroics. When someone quickly finishes a feature, the boss gives that person a lot of praise; but when someone writes documentation to share knowledge or improves deployment speed, the boss doesn’t react at all. I prefer a cohesive team with clear division of labor
  • The company hasn’t set up growth or evaluation plans for employees, and when I proposed onboarding suggestions, they were rejected. So I think the company tends to value people who can contribute immediately rather than teams that can work together long-term

Organizing things with real examples like this gives you much more to think about.

Have You Tried to Change Things?

You’ve had the thought of quitting, and you’ve analyzed the reasons.

Within those reasons, ask yourself: if those issues were all solved, would you still want to stay here? If the answer is yes, have you tried to change things?

Here are a few questions to ask yourself first:

• If the difficulties and challenges I’m facing were solved, would I want to stay here?
• Have I tried to solve these problems? Is this the best I can do within my能力?
• Thinking about my goals three or five years from now, can this place help me achieve them?

When problems arise, it’s easy to blame the environment. That’s completely normal.

In The 7 Habits of Highly Effective People, Stephen Covey talks about two circles: the Circle of Concern and the Circle of Influence.

The Circle of Concern refers to everything you care about or worry about; the Circle of Influence refers to the things within that circle that you can directly change through action.

If you want to take control of your life, you should pay more attention to the Circle of Influence — the changes you can directly create through action — rather than the Circle of Concern.

For example, if you feel your salary is too low, have you been willing to talk to your boss even if you might be rejected or feel uncomfortable? Have you tried to present evidence for why the company should give you a raise? What have you done, and what results have those actions brought?

Have you told your boss, “I don’t want to do these miscellaneous tasks because I want to focus more on my output”?

If the values are different, have you brought it up with your manager?

If the code is too hard to maintain, have you tried proposing a solution, pushing for refactoring or improvements, and persuading your manager why it matters?

If you’ve done all that and still can’t change things, and even after trying several more times it still doesn’t change, then you can consider quitting.

Focus on the things you can change.

The Protective Umbrella of Big Companies

Many people feel they’ve accumulated a lot of skills and completed many projects in their current job, but to put it bluntly, that may just mean a senior mentor or CTO set up the environment for you, and you were simply solving tasks along the path someone else paved.

In a sizable company, or even a publicly listed one, your responsibilities are usually divided very clearly.

If a project needs server setup, you can ask the SRE team to help. They’ll set up the network, permissions, and environment for you, and even write the auto-deployment scripts, using Ansible and Terraform for deployment.

Once the feature is developed, a professional QA team will write the test plan for you, then run the tests and file tickets.

It all sounds ideal, doesn’t it?

The downside is that you’ll only focus on your own responsibilities. When you later end up in a resource-constrained environment where you have to set everything up from scratch yourself, you may get stuck.

At that point, you’ll think, why are there so many trivial tasks? But it’s not that there are too many trivial tasks — it’s that all your previous workplaces were living under a protective umbrella, and you never tried to step outside it.

If you can’t clearly say, “Because I pushed this forward, this change happened,” then you were really just a customer being served. If you jump ship with that kind of passerby mentality, and then enter an environment where you truly need to carve out territory yourself, you’ll definitely suffer.

If You Want to Climb Higher, You Can’t Escape the Problem of People and Organizations

Many developers think technology is everything, and that things like politics are dirty and unethical. But when your need for influence exceeds your personal output limit, you must rely on collaboration to achieve your goals.

Writing great code or designing a great architecture doesn’t necessarily convince people. Demanding that others accept your logic wholesale is a rather arrogant thing to do.

Interpersonal relationships and organizational structure are no longer noise obstructing your work — they are core parameters of the work itself. Avoiding these issues means rejecting the chance to scale yourself.

I know that as a developer, you’ll definitely have your own preferences, convictions, and values you want to hold on to. It’s hard to fully align with one side or the other, but what we can do is find a dynamic balance we ourselves can accept.

In Japan, there’s a saying called “nemawashi” (根回し), which means that before a meeting, or before a formal decision-making meeting, you separately talk in private with the influential people involved to ask for their thoughts and coordinate with them.

Then, when you formally raise the topic in the meeting, it’s easier to gain support. When the project you’re facing is larger in scope, you’ll need to start paying attention to things beyond technology.

Once at a company, there was a project that required building a server from scratch for server-side rendering.

Because the internal tools we were using at the time had limited support, and because there was a requirement for dynamically fetching data, I proposed a new architecture to implement it.

This architecture required cooperation from multiple departments: SRE needed to prepare and set up the server, planning might want to know what benefits this feature could bring them later, and the development team would want to know roughly how the architecture was designed. The code implementation itself wasn’t difficult — it was just deploying a Next.js server.

But in order to convince people across departments, I prepared a lot of documents and adjusted my writing style for different teams. At the time, we were also short-staffed, so I had to push forward cross-department communication while also implementing the architecture myself.

Fortunately, with my manager’s support, after finishing the project I received a very substantial raise.

Employment Is a Capital Game

Never resign with the idea that “this company can’t survive without me” — that mindset is extremely unhealthy.

Under capitalism, no one is irreplaceable to a company. In the capital market, there will always be someone who can replace you.

The essence of an employment relationship is an equivalent exchange of labor for capital, not emotional attachment. In an organization, anyone’s function can be modularly replaced — that’s the inevitable result of capitalism’s pursuit of stability.

But for yourself, joining a company means choosing a set of values. The skills, trust, and network you gain there are irreplaceable assets.

I once asked a founder whether he saw employees as partners. Looking back, that was a rather naive question — even if they really are treated as partners, the employment relationship still exists.

Since it is an employment relationship, there are only two core things a company must do to survive: make money and keep operations running smoothly. The team doesn’t exist to be each other’s partners, but to achieve each goal.

Back then, I also asked another question: if an employee gets sick or runs into trouble, would you, as the boss, use a smooth line to handle it, or would you truly care? I knew the results of those two approaches might be the same, but deep down I still hoped the boss would genuinely care about employees. That mindset was completely wrong.

The workplace is never a place for exchanging sincerity. A boss’s duty is to keep the company alive and the team productive, not to be an employee’s life coach or best friend. If a boss can use tactful language to make employees feel respected, maintain morale, and avoid letting personal emotions interfere with decisions, that is professionalism.

Genuine concern sounds beautiful, but it also has a cost. When a boss invests too much emotion in a particular employee, they hesitate when it’s time to lay people off, go soft during performance reviews, or show favoritism when allocating resources. In the end, that hesitation and bias hurt the whole team, and even the company itself.

I shouldn’t have forced my own ideals onto the situation and ignored the essence of employment: employees give their time and ability, the company gives compensation and a stage, and both sides do their part well. That is the greatest respect. What the workplace needs is not sincerity, but getting things done.

Growth Comes from Pain

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

Of course, people may join the workplace for different reasons and have different career goals. Maybe it’s to have a job that pays the bills while looking for the path they truly want to take.

NVIDIA CEO Jensen Huang once said he hopes everyone goes through hardship, especially people who were born with enough resources, a good education, and a supportive family environment. You’re given very high expectations, and you’re able to pay expensive tuition to enter a better education system. He said people like that usually have less resilience.

He believes truly great things are not necessarily made by very smart people, but by people who have suffered. At first I didn’t really understand that statement, but now I think I’m beginning to.

When I was in college, I didn’t have many resources, so I couldn’t really afford clothes or pants or much in the way of what I wore, and I couldn’t buy better equipment. I even couldn’t afford my phone bill.

But because my financial situation was poor, I had stronger motivation. I wanted to learn well, learn some skill quickly, and then get an internship as soon as possible.

That gave me the opportunity to accumulate software development experience while I was still in college, and later in my career it gave me more chances to pursue companies with higher technical requirements and better compensation.

Later, I had the opportunity in the workplace to serve as a Tech Lead, leading the team in making decisions, communicating with other departments, and so on. These are things you do at the beginning without necessarily knowing the details. You may have to do them in an environment full of uncertainty, where you know almost nothing.

After moving into management, you again face people and other team members, and you can no longer work with the old mindset of “as long as my code is good enough and I produce output, I’ll get a good result.” You have to find a way to make the whole team better.

At each stage, things aren’t necessarily happy in the moment. They’re often painful, because they usually mean changing the way you work and even reshaping your values.

But as you make more decisions, solve more problems, collaborate with more people, communicate more with your boss, and see more projects, you keep trying to find solutions in relatively unfamiliar environments and push projects forward. The process is painful, but the growth it brings is enormous.

You start to realize that the current project may be something you’ve encountered before; you roughly know what the architecture and technology stack should look like. To make the project go smoothly, technology may no longer be the most important part.

How do you communicate with stakeholders? How do you persuade them that your solution is viable? How do you approach things from their perspective? You slowly come to understand that these details you used to overlook are actually the most important factors in getting a project moving.

So I believe growth inevitably comes with pain.

When you feel pain in the workplace, ask yourself whether that pain can bring you growth. If it can, then maybe you shouldn’t avoid it.

Pain can be divided into two kinds: pain that helps you grow, and pain that is just self-consuming.

I recently started running, though I don’t actually like running that much. I have to wake up early, run when it’s freezing outside, keep running when my heart feels like it’s about to explode, and keep running when my legs are giving out.

All of that is painful. But I know that building mileage will make me healthier and improve my cardiovascular capacity.

Every run is painful in the moment, but I’ve never regretted it. What I do regret is lazing around at home.

Pain that doesn’t lead to growth isn’t very good.

It’s like wanting to play volleyball, but finding out the rules of the game are baseball. If you try to play baseball using volleyball rules, you’ll never win.

The difficulty is that, in the moment, you can’t tell the difference. You don’t know whether the game is baseball or volleyball.

Once, halfway through a project, the company suddenly announced that the service would be shut down, and my performance completely disappeared. Half a year of effort was wiped out.

That said, if you want to grow, it’s like running — you have to keep accumulating pain. At first, running a 9-minute mile feels like agony, but later 8-minute pace won’t leave you breathless. Only after you make it through do you realize the growth pain brings.

Reflections on the Workplace from FDE

Recently I’ve often seen a role called Forward Deployed Engineer (taking OpenAI as an example). This kind of role is neither a typical Software Engineer nor a consultant. It requires enough technical depth to deploy a prototype into production and turn it into a 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.

In a typical Software Engineer role, the team receives requirements that have already been refined by PMs and planners, and the development team implements them.

A Forward Deployed Engineer works directly in front of the customer, observes what’s happening on-site, proposes solutions, creates those solutions, and drives the project through to launch.

That requires the ability to turn vague requirements into something actionable, and the ability to build trust with customers.

You can imagine that in this kind of work, there will be plenty of communication involved. Communicating with stakeholders, persuading them that your solution is feasible, and giving the most suitable solution within limited resources and time.

It may not be your comfort zone, or the kind of thing you’re used to.

You Don’t Have to Play the Workplace Game

At this point, some people may still disagree.

Why should I spend so much effort persuading a department, manager, or even boss whose values are so different from mine? That’s just too exhausting.

Bridging the gap in understanding is tiring, painful, and frustrating. In the workplace, if you want to move things forward but can’t convince the other side, it only means your communication isn’t enough, your influence isn’t enough. A gap in understanding is not an excuse; there’s nothing to argue about. But once you step outside the rules of the workplace game, there’s nothing wrong with honestly saying that some things you truly don’t agree with are just not for you.

You absolutely do not have to play this game. You can look down on it. You can reject it. You can say: I think this is too tiring, I want to be myself, I want to focus on technology and development, I want to prove that technology will always win.

Absolutely.

But once you choose that path, it may become very hard to rise in a typical workplace. You may need to spend much more time than others finding a company that truly fits you — a boss who understands technology, respects engineers, maybe is even an excellent developer themselves, and can pay well too.

However, there is an important premise here: choosing not to play the game is one thing, but choosing not to play while complaining about the game’s outcome is something else entirely.

You can’t refuse to learn how the workplace operates and then lament, “I’m clearly a great talent, so why can’t I find a patron who recognizes me?”

This isn’t “being unrecognized despite your talent.” It’s you choosing not to enter the track where you would be seen. There’s no right or wrong in the choice itself, but every choice has a cost.

Signs You Must Quit Immediately

Although I recommend thinking carefully before quitting, here are several signs that you should consider leaving immediately:

Severe Impact on Body, Mind, and Spirit

This may show up as hormonal imbalance, poor sleep at night, loss of appetite, or no appetite at all. On the mental side, you may often feel anxious, depressed, or unable to feel motivated to do anything.

Once these signals appear, I’d recommend not forcing yourself to endure it — just resign. Damage to your body, mind, and spirit may not be reversible.

Mismatch Between Authority and Responsibility

You’re given a task, and your manager demands that you follow his instructions without room to发挥 your own judgment. But when the result or outcome isn’t as expected, you’re held accountable and questioned.

Broken Evaluation System

The company’s evaluation system doesn’t align with your own values.

For example, the company may prefer assigning work to people they’re close to rather than giving growth opportunities, or there may be no evaluation mechanism at all. You don’t know what will be properly recognized, and you don’t know what the company expects from you. Even if you talk to your manager, the answers remain vague.

Office Politics

For example, some people have better relationships, are closer to the manager, or even have family ties, which means certain positions are not promoted based on results; or there may be obvious conflict between departments.

Abuse of Power, Sexual Harassment

The workplace frequently sees abuse of power, sexual harassment, or the boss taking a dismissive attitude toward talent, not taking employees seriously, or showing some reaction without any real improvement.

Sometimes it’s simply like this: the environment is not a fit, and structural problems are hard for any individual to change.

Conclusion

I’ve shared a lot above, but there’s actually another way to think about this: you already know exactly what you want.

For some people, a career may just be a job — a way to earn a salary so they have more freedom to focus on the things they truly want to do.

Everyone has different ideas and goals for their career, and you don’t necessarily have to pursue promotion or constant growth. Some people want a stable life, and that is also a choice.

So when thinking about your career, you might first ask yourself: what does work mean to you? What do you want to achieve by joining this company?

The essence of employment is still a capital game. In a capital game, individuals are at a disadvantage — you can be replaced at any time. But the skills, experience, network, and judgment you accumulate are assets that cannot be replaced.

Thinking this through is more important than deciding whether to quit.

No matter whether you ultimately choose to stay or leave, I hope you can make the decision that is most beneficial to you. And I hope this article has been helpful to you!…