Reflections After Two and a Half Years of Career Change: Thoughts on What I Overestimated and Underestimated

Introduction

This article records some career-related changes in thinking and context, not limited to career transitions.

mountain climbing Roma Traverse, view from Mawuteyeguanshan. Unexpected change from forest mountain to a vast wilderness after forest fire

Looking at the actual time I've spent working since transitioning to my first job as a frontend engineer, it's been about two and a half years. A few days ago, while walking home at night, I suddenly wanted to record some thoughts. I was reminded of a Podcast episode from Financial Dog where they would give interviewees a term and ask whether they thought society generally overestimated or underestimated it (I've somewhat forgotten the exact format). So I'm applying the concepts of overestimation and underestimation to record thoughts from my recent career path, especially in the years since my career transition, noting which ideas I believe I once overestimated or underestimated.

I'm recording these thoughts not only for my future self to review but also to share them publicly. Besides forcing myself to organize them more thoroughly, perhaps they can bring different perspectives for readers to consider.

Before starting the main content, let me define what I mean by overestimation and underestimation:

Overestimation doesn't mean something has been abandoned or is completely unimportant, but rather: I once considered it highly valuable, but now I think it's just okay.
Underestimation doesn't mean something should be treated as a golden rule or highest standard, but rather: I once thought it wasn't important, but now I think it's quite significant.

In simple terms, overestimation or underestimation refers to the result compared to my past thinking—it represents shifts in my mindset. These are relative rather than absolute meanings, and many of these viewpoints include considerable personal experience that can't be directly applied to others. They're only meant to provide additional perspectives and context for consideration.

Things I Think I Overestimated

Successful People Will Continue to Succeed

Perhaps influenced by stories of serial software entrepreneurs and consistently successful individuals, I hadn't particularly been aware of the survivorship bias fallacy. Additionally, since interviews often emphasize past project successes, I implicitly held the belief that "past success indicates a high probability of future success."

But by consuming information more broadly, I discovered that many previously successful people fail in their next challenges—these stories just aren't necessarily widely publicized. For example: companies trying to change or reinvent themselves hire CEOs/CTOs/COOs with successful track records in specific fields to fill key positions, but often fail. I've also personally experienced being led by so-called previously successful technical people, only to find this wasn't the case.

It's not that successful experiences can't lead to future success, but I believe replicating success has prerequisites: "When facing similar problems with similar resources and environments, then the probability of replicating success is high."

But reality is usually different.

The problems might be similar, but the people, systems, or resources differ; or the environment might be similar, but the problems and domains differ significantly. These factors make it difficult to replicate success experiences, and can even be harmful, as many successful people tend to apply the same methodologies to achieve the same success, ignoring that the context and environment are fundamentally different, ultimately failing.

Extended discussion and action plan: Now when interviewing others (whether peers or superiors), having success experience isn't most important. I would want to verify:

When facing problems or challenges, what is their thinking process and solution approach?
When pushing forward an initiative and encountering disagreement, how do they handle it?
When implementing solutions and encountering obstacles or unexpected issues, how do they adapt?
For each question above, ask for concrete examples, appropriately probe for details, and confirm their role, actual actions, and impact (especially what they did, which is much more important than what they said)
Ideally, get evaluations from multiple people who have worked closely with them

Rather than success experience, I believe the thought process during execution, value choices, execution ability, adaptability, learning ability, etc., are the key points for potential collaboration.

Changing Environments is Just Avoiding Problems, Not Solving Them

Perhaps influenced by a common saying: "If you encounter certain insurmountable problems at one company, you'll encounter the same problems at another company—you're just avoiding them."

Since my personality tends toward self-criticism, in the past I would easily think: when facing what I consider an unsolvable XX problem, if I choose to change environments, am I just a useless person avoiding problems?

After reflecting on my career in recent years, especially comparing company environments before and after my career transition, I believe this thinking overestimates myself while underestimating the influence of environment.

Moreover, "choosing a new environment" itself can be a way to solve personal problems.

Using myself as an example:

Before my career change, I had an opportunity to become a small team leader, but ultimately couldn't succeed for various reasons. One major reason was insufficient professional or mindset ability in leadership/management, and I couldn't prove I could overcome these problems in the short term. By the end of my time in that company environment, I still couldn't solve this problem.

After experiencing different companies and teams, and experiencing the leadership of more managers or senior engineers, I gained a more practical understanding that leadership approaches are very diverse with no correct answer—only what's suitable or not. If I wanted to try leading, I could explore my own approach.

Until I joined a small team environment and became the most senior frontend developer (mainly because senior members left after I joined, when I had only been a frontend developer for a little over a year), I had opportunities to lead more junior engineers. Through their feedback and observations from PMs and others, I gained a clearer understanding of my leadership strengths and weaknesses, achieving good progress.

Looking back, I believe that even if my personal problems remain the same, switching to a new environment means encountering new people, new resources, new opportunities... These influences and stimuli from the new environment can potentially provide more experiences and help, enabling you to find more methods or energy to solve your problems.

Now I believe that as long as you continue to reflect and act, it's perfectly okay to decide to leave your current company/environment if you face insurmountable obstacles and problems. What's important is: knowing why you're making the decision to change environments, and trying to continue thinking and taking action regardless of which environment you're in.

The Risk of Attempting Change is Very High and Requires Extreme Caution

This topic is a bit broad to discuss in terms of risk, but I couldn't think of a better title!

My main experiences come from several attempts:

Trying to change careers: tracing back, my transitions were roughly: agricultural worker, fruit and vegetable quality control clerk, online course content quality control, frontend engineer
Trying to switch companies: currently changing about every 1-2 years, with experiences of great expectation gaps, including leaving one company after just 1 week
Trying to improve poor frontend environments: unreasonable code review mechanisms, no release system, lack of proper version control, inefficient collaboration mechanisms, lack of good ESLint and testing environments, poor web performance, etc.

As I've tried more to change my own state or small surrounding environment, I've increasingly realized that I previously exaggerated the risks of attempting change.

In the past, I was particularly afraid of work-related changes, or rather, very afraid of the potential failure that transitions might bring. But risks can be assessed more "rationally" without relying too much on "feelings" of discomfort and fear about change, which can lead to overestimating risks.

If you can list the pros and cons of changing versus not changing, then find trustworthy people with good thinking to evaluate the reasonability (avoiding blind spots when alone), you might even discover that "in the long run, the risk of not changing now is actually much greater compared to changing."

In this regard, my thinking is now simpler: as long as you can accept the worst-case scenario and still live well, you shouldn't be too afraid of the risk of failure. (Honestly, I still have to continuously fight against my self-doubt about fear of failure, but my win rate has definitely improved, and can get even better.)

Technical Legacy Should Not Exist and Must Be Fixed Immediately

Before changing careers, my first project that could be called a web work was my final individual project at school, where I learned and applied the newest frontend technologies at that time. After changing careers, coincidentally, the first few projects I was deeply involved in were all built within the previous year, so there wasn't much serious legacy code.

So later when I encountered projects over 3-4 years old, full of chaotic legacy (including many technical and business logic problems), I initially suffered and enthusiastically wanted to overhaul everything at once.

But gradually I discovered: even with that chaotic legacy existing, the product could still run, users could still use it, and they couldn't even feel the impact of the legacy code.

Instead, if you forcibly change things "without understanding the legacy context," you can sometimes create even bigger problems.

Later, I came to believe that rather than "immediately fixing existing legacy," it's more important to first try to "prevent more new legacy." Legacy is mostly related to development planning and timelines, development team collaboration methods, development technical concepts, etc. For example:

Earlier or more actively communicating with PO/UIUX about development needs and items, whether problems can be solved in technically preferable ways, or whether releases can be divided to make timelines more reasonable
Discussing and establishing code review mechanisms, development processes, release processes, team collaboration
Establishing ESLint, testing, etc., and implementing CI/CD to automatically make code more robust

Of course, the most difficult thing is always optimizing everything when "time is limited but requirements are unlimited." But doing something is better than nothing—at least trying slowly, bit by bit, to avoid more legacy creation is good. You can't completely avoid it, but you can reduce the amount generated.

Then, if there's an opportunity to correct past legacy, you should first "inventory items," categorizing by priority and scope of impact: priority determines what's more important and urgent to fix first; impact scope determines how large the impact of changes will be and how extensive testing needs to be.

After inventorying items, "communication" is key—communicating with technical leads or teams to ensure consistent understanding, with PO requirement teams to see if more time can be allocated for handling legacy... In short, there are many things to do, depending on your team's operational model and stakeholders.

Honestly, my initial thought upon seeing scary legacy code was to run away! But products that have lived long enough will always have legacy. Better to try facing it, which can lead to deeper understanding. Living with it day by day, you'll understand that even if legacy isn't beautiful, it ultimately supports the entire product's operation, bringing value to certain users/companies.

Legacy can be gradually improved, not completely overhauled, but incrementally corrected. My current thinking:

First understand the product, understand the business logic, understand the code
Rather than immediately fixing past legacy, can any mechanisms or methods prevent new, more serious legacy from quickly developing?
If improving legacy, first inventory it and list priorities, impact scope, resources needed for improvement, etc.
After inventorying legacy, try discussing it with various stakeholders—besides potentially scheduling more time and manpower to handle it, you might also receive new ideas and solutions

Incorrect Features or Displays Must Be Fixed Quickly

I think most frontend engineers care about details, so when seeing small inaccuracies or problematic features, we've all had times when we couldn't stand it and wanted to fix it immediately. This thinking is easier to implement when "the product scale is still small," such as personal projects or newly created products.

But if a product is large and has existed for a long time, it's actually difficult to take care of everything—or honestly, unnecessary to take care of everything, because time and resources are always limited, and you need to focus on important items.

So what's important is "priority"—using functionality or business logic to prioritize broken items: P0 handle immediately, P1 handle within a day, etc. If a page has fewer than 10 users in a month, is it really necessary to fix issues now? If a feature will be sunset next quarter, does it need fixing? If a problem has existed for half a year without complaints, is it important?

Therefore, I now pay a lot of attention to the impact range and severity of features or displays, and prioritize them (usually PO has decision-making power, while designers, engineers, etc., can participate in discussions with data to support). Only high-priority items need quick, immediate fixes.

Things I Think I Underestimated

Time Needed to Recover Good Health

I've often heard about the importance of health, always being encouraged to exercise more, eat properly, sleep well, etc. But perhaps because I've heard it so much and hadn't experienced health setbacks, I never truly cared about it deep down. Especially during my career transition period and early in my first job, I pushed myself harder. Under conditions of considerable stress, irregular eating and sleeping, no exercise, and other terrible habits, the result was that my body developed problems first—gastrointestinal inflammation, ulcers, severe bloating, difficulty sleeping—which then further affected my mental state, leading to a period of depression. And poor physical and mental states further led to decreased work efficiency, reduced thinking ability, lower quality of life, etc., creating more stress and a negative cycle.

From the above, you can already see that I underestimated the importance of health, but there's something else I want to emphasize that I overlooked: "the time needed to recover from poor health to good health."

Overall, it took me about half a year to a year to ruin my health, and more than two years to finally restore it to a level I consider good. The time needed for health recovery was more than twice the time it took to damage it. Although the time cost was high, I was still fortunate, because many people's health can never be fully restored.

After trying to adjust work hours and routines, I did observe that, on average, when I approached work with a healthier physical and mental state, I could complete work items more efficiently, communicate with others more smoothly, and also have a better life state. Overall, it was a great gain.

A career is a marathon, not a sprint. The importance of health is now more deeply engraved in my mind.

The Influence of Toxic People on the Environment

Basically, I've understood "the influence of environment on people" since two and a half years ago. At that time, I believed that having the opportunity to join AppWorks School—an environment with a selection system and peer motivation—was probably a more efficient approach for me. Regarding environmental influence, I think this article Why You Should Try Your Best to Get Into a Good Environment summarizes it well, so I won't elaborate further.

However, what I think I underestimated was "the influence of toxic people on the environment." For example, if you let people with characteristics like non-reflection, non-learning, gossiping, reducing others' efficiency, making statements without improvement, etc., join the environment, and these people still do fine without being promptly and directly corrected or effectively eliminated, then the originally good people in this environment will gradually become dissatisfied and exhausted, causing efficiency to decrease, and eventually they will either leave or sink into complacency.

This is something I hadn't thought of before, because I believed that since bad environments are difficult to change, wouldn't the reverse be true as well? But based on current experience, my feeling is: one bad apple really can spoil the whole bunch.

Regarding this issue, my new thoughts on creating a good environment are:

Good environments usually first examine systems and processes when problems arise, rather than targeting individuals
But after experiencing several problems and finding that people don't fit, an elimination mechanism must be effectively implemented to ask unsuitable people to leave, otherwise the environment will gradually deteriorate and eventually become unsalvageable

The Impact of Salary Level on Career Changers

Perhaps influenced by my pre-career-change salary levels: past salaries included net incomes of around 27k, 30k, 35k TWD, and I could still live in northern Taiwan (not necessarily well, but survive).

Initially, after about half a year of training (Appworks School's training method, if interested, you can look it up—at least 70 hours per week, intensive), I was thinking of asking for 450k/year, 500k/year or something similar, because from my past experience, I could never validate how much salary I was worth, plus I didn't have much confidence, thinking that as long as I could survive, that would be fine.

Although one reason for changing careers was to have more choices, including "assets, salary" amounts, I was thinking more long-term that it would increase, so I didn't expect to be much higher than before in the first few positions.

Fortunately, after objective discussions with peers and friends, I eventually asked for at least 600k-700k+ (I've somewhat forgotten, it might have been 650k-750k/700k-800k or something similar).

Based on subsequent personal experience, the benefits of higher salary:

Paying off loans earlier, reducing psychological pressure, starting to accumulate positive assets
Improving living conditions faster, especially not having to live in crowded, dark, greasy studio apartments
More medical resources to choose from—having more money really helps when adjusting physical and mental conditions
More leverage when changing jobs, accumulating sufficient assets faster to try finding more suitable companies, or taking breaks to replenish energy if needed
Higher baseline when negotiating the next salary—some companies really like to compare with your previous salary (if you want to avoid this, you can withhold or skillfully provide salary ranges)

There's also something more implicit: sometimes salary serves as a judgment criterion to filter out some companies in poor condition, whether due to "not making enough money because of business model problems," "making money but giving extremely little, not valuing talent," "not giving much money because the department/team is not valued," etc. Is it possible to have a company with low salary but a great company and team? Possibly, but the probability is relatively low.

I'm not saying to only pursue high salaries, but salary should be viewed as an important consideration. It shouldn't be a case of "as a career changer, finding a job is most important, salary is secondary," but rather, "as a career changer, you should confidently pursue a reasonable and sufficient salary for your abilities and personal needs."

Whether it's sufficient depends on your own situation; whether it's reasonable depends on whether the job requirements match, checking salary platforms, and interviewing to see what's possible.

The Help Technical Sharing Provides to Others

As an engineer, having a technical blog is quite reasonable. I think the technical blog articles I write are quite long, and probably few people want to read them completely. They're not entirely unique content or topics, as I often reference others' knowledge first—searching online, there are other articles on similar topics. So I didn't particularly think they were beneficial to others, and mainly wrote them to help clarify my own thoughts at the time, for my future self to review, and because they're public, I write more seriously.

But actually, friends and strangers have mentioned to me that my articles have helped them substantially. Although not many people said this, it somewhat surprised me. Later, I felt more that any organized content can be shared—perhaps it will inadvertently help someone.

However... I really haven't written many articles, compared to many others I'm quite unproductive, and sometimes late at night I feel an inexplicable shame about it. I've always wanted to make consistently outputting articles a goal to achieve, but still haven't found a good implementation method (or strong motivation?). In any case, I'm still trying and exploring, hoping future update frequency can be higher, giving more people the opportunity to gain something by reading my writing or other forms of sharing.

Besides technical blogs, I've also noticed the value of sharing in spontaneous company presentations. For example, I once shared Web Performance optimization experiences. Before sharing, I kept doubting if it was something people could learn just by searching, whether it was deep enough, if it really needed to be shared, or if it would waste participants' time.

But finally thinking I'd already prepared, I organized thoroughly, clearly announced the outline, topics, and what participants might learn, letting them decide whether to spend time listening. After the presentation, I specifically chatted with several participants and indeed found that some hadn't done this before. Although they could have figured it out themselves, having heard this presentation and having reference slides still improved their efficiency in getting started.

In summary, I've already learned techniques or thinking from many people's articles and lectures in the past, BUT I still strongly doubted whether my sharing could bring value to others, and worried about misleading them. After experiencing several instances of actual feedback, I genuinely felt that my sharing could somewhat help others.

Although I still doubt somewhat, I've become increasingly willing to share my reflections and learning about career, life, and technology publicly in any form. I think even if there are errors in the content, strong people will point them out. Besides, perhaps it can really help someone.

The Benefits of Regular Contact with Like-Minded Professionals

In connecting with past collaborators and acquaintances from work, I've more often been passive. Fortunately, some former colleagues and classmates don't mind and have kept in touch with me, with some even forming regular sharing meetings.

When working in a team where most people share similar work values, it's not easy to recognize the importance of this. But when working where most people have different work values, it becomes very important. Because regularly discussing with people who have similar values, similar goals, and want to continuously improve, not only can your thinking be stimulated, but you can also be reminded of your principles, even replenishing indescribable energy, allowing you to continue facing many troublesome things in reality. You always know that some people can understand you and support you when you might be falling down—this is a wonderful thing and makes me feel like a fortunate person.

All in all, maintaining regular contact with people whose values align with yours and who have good thinking abilities is much more important than I thought, and I consider it worth listing among the things I underestimated.

Conclusion

The thoughts above are the mental shifts that currently come to mind most vividly. There would be more if I thought deeper, but I won't elaborate further, also to avoid rambling too much.

I believe many ideas have no endpoint and will continuously be reconsidered and adjusted based on circumstances, possibly evolving differently at different career or life stages.

Perhaps after a while, there will be more mental shifts worth recording here that I'll add, or maybe after a year or so, I'll write another article recording new perspectives.