Reflections After Three Months as a Frontend Engineer

Introduction

Although I've been working as a frontend engineer since May 11, 2020, it wasn't until last week, August 11, when I completed three full months on the job, that I considered my career transition to be truly successful.

sharing at Appworks School In July, I went back to AppWorks School to share my experience, when I hadn't quite reached the 3-month mark yet (sweating)

This is a fairly casual and authentic record of my career transition thoughts, focusing on the following points:

Push factors: why I wanted to leave my previous career
Pull factors: why I was drawn to this new career
After the transition, was there a gap between expectations and reality?
Advice list for those considering a career change
Conclusion

The content doesn't include "methods for successful career transition," but instead focuses on documenting the thought process behind "why change careers," "reflections on the results," and a summary of "advice for those considering a career change."

This article is suitable for those "considering whether to change careers" or "those who have just decided to change careers." For those who are certain about changing careers or have already started taking action, this might just be a story to listen to. If you're looking for methodologies for career transition, you can directly Google it as there's already plenty of information available.

Actually, I originally just wanted to document my career transition journey and reflect on whether I had achieved my initial expectations. As I was writing, I thought I might as well share it, as perhaps someone could benefit from the context.

Note: The content is based on personal experience and should always be considered as a reference point, not an absolute answer.

Overview

After finishing writing, I realized the content was quite extensive, so I decided to list the "Advice for Career Changers" conclusions first. If you read these and aren't interested, this article might not be for you:

Reflect on what exactly is unsatisfying about your current career. List all the push factors.
Will becoming a frontend engineer satisfy these needs? List the pull factors and see if they address the push factors.
Try coding for at least one month to ensure you don't dislike it and it's not just a passing interest.
Share your reasons for wanting to change careers and your strategy with friends or engineers, and let them challenge your thinking.
List the risks and ensure you can accept the worst-case scenario; be prepared to take responsibility for the outcome.
Set a clear timeline for the transition and expected salary. For example: within 6 months, annual salary of 600k+.
When you're in a good mental state, prepare strategies for dealing with major frustrations. Have a plan for what to do when frustration becomes overwhelming.
Enjoy the process of coding during the transition; you have a lot of time to write code with high autonomy.
You'll always need to keep learning, so learning how to learn is important. Find methods that work for you.
Keep in mind that transitioning careers is just the beginning; the road ahead is still long.

Now I'll discuss my personal experience, which serves as a personal example and context for the points listed above.

Why Did I Want to Change Careers?

The reasons for changing careers include both push and pull factors. Push factors are the unsatisfying aspects of my current career, while pull factors are the discoveries made through various attempts that could potentially fill these unsatisfying conditions.

Regarding the "push factors," there were mainly three points:

1. Not Perceiving My Value in the Position Itself

Before transitioning, I held a position in quality control for online course content. A large part of my job involved watching courses after they were produced and providing suggestions to the instructors. The instructors would review these suggestions and decide whether to modify or optimize their content, and if they decided not to make changes, they needed to provide reasons.

In the process at that time, I believed that the quality of a course largely depended on "the instructor's teaching ability" and "collaboration with the course content planner" (another position).

In most cases, I felt that even without my intervention, the courses wouldn't have significant issues, because I wasn't responsible for planning the course structure or creating the content itself. The suggestions I gave after watching the courses often only involved minor adjustments. There were indeed a few courses that were quite poor where my intervention had a greater impact, but most of my work time was actually spent making minor adjustments to courses, with relatively little influence.

The subject of the paragraph above is consistently "I" rather than "quality control" because these are very subjective feelings. From a more rigorous perspective, the position of course quality control has its value.

For example, if a bestselling course inadvertently included images or music with copyright issues that were later noticed by students, couldn't this potentially develop into significant damage? If an instructor promised that beginners could learn the material, but the content was incomprehensible to novice students, causing frustration, wouldn't students leave negative reviews?

Over time, this would not only make students distrust the instructor but could also affect the credibility of the online learning platform.

However, even though I understood the importance of the position, and even though the job content included identifying problems, providing concrete suggestions, participating in user interviews, and exchanging ideas with colleagues, which improved my thinking in many ways, I still subjectively couldn't find satisfaction in the position itself.

After careful consideration, I think the key to career goals isn't just understanding the importance of a position and trying to fit into it. Rather, it's continuously reflecting on your expectations for work, understanding what kinds of contributions, achievements, and salary would satisfy you, and gradually finding the corresponding position through trial and error.

Moreover, the contributions, achievements, and actual salary that each person wants differ at various life stages, so career development is a dynamic process. Perhaps when I initially took this position, I had expectations and satisfaction, but in the current situation, it no longer satisfied me.

A career is a long journey that requires continuous iteration and optimization to gradually move toward what you desire, finding a good balance along the way.

After some reflection, I discovered that in my next position, I wanted:

Objective sense of contribution: To be able to measure more directly whether my work had immediate output and contribution, which would usually be reflected in the company's quantitative indicators (those numbers highlighted every quarter or even every day).
Subjective sense of achievement: To be able to create things with my own hands, where the success or failure of those things is highly related to me, and ideally to be able to believe from the bottom of my heart that "I play an important role in the quality of this product."

To clarify the terminology, a sense of achievement is more about "doing things I want to do, which gives me satisfaction and happiness"; a sense of contribution is more about "doing things that others need me to do, which can be measured by corresponding indicators."

At the same time, I realized that no matter how capable or interesting my colleagues were, or how free the company's system was, if I couldn't find satisfaction in the "position" itself, I would still want to resign.

2. Career Choices: If I Leave, Can I Take My Skills With Me?

Since I mentioned self-doubt about my position above, this led to the question: "If I leave, where should I go?" So I began to think about my current abilities and whether the skills I'd developed in my position could be taken with me and fully utilized at the next company.

My method of judging this was simple: I looked at job search platforms.

Usually, this involves both soft skills and hard skills. In terms of soft skills, I had indeed grown compared to before I started working, but in terms of hard skills, I always felt I didn't have any worth mentioning. Perhaps because of this, I always maintained a sense of anxiety in the workplace.

After gradually sorting through my thoughts, I realized:

The hard skills I wanted were those that would have sufficient value across multiple companies, even international ones. These hard skills would be laid out in job descriptions and were relatively easier to measure compared to soft skills. They wouldn't lose value when changing companies; on the contrary, they might become even more valuable.

Over time, this would give me more opportunities to choose companies, rather than just being chosen by companies.

3. Salary Level

In the past, I truly didn't care much about salary (how fearless and ignorant of youth). I was fortunate that after entering society, I didn't need to give money to my family, nor did they need to support me financially.

In my first job, I earned about 27-28k per month in Taoyuan, solving two meals a day with 50-60 yuan lunchboxes. When I first worked in Taipei and found I could earn 30-33k per month, I actually wondered if I could really earn this salary? Instead of focusing on whether I could enjoy financial pleasures or investments.

Because I lived simply, even renting in Taipei and being frugal, I could still save money. Even when traveling, completing a month in Southeast Asia for under 30k was entirely possible, and I could live quite well.

It wasn't until I saw my family members aging, struggling to climb stairs, and wanted to remodel the old house's staircase; or when I wanted to send a massage chair as a Father's Day gift; or when I was in a small room that couldn't get sunlight and absorbed cooking fumes, and then looked at my bank account, that I became increasingly aware of the importance of money.

Moreover, when considering changing careers, looking at the prices of bootcamps or any courses, and thinking about how much time I would spend without a salary while focusing on the transition, I realized: when life needs a major shift, money is a good bargaining chip and tool, giving you greater freedom of choice.

So, I wanted to gradually achieve higher-paying jobs as a stage goal.

Of course, by continuously working hard in the same position, there's always a chance to gradually increase your salary, perhaps to 4X k or so, but the issue is probability. For example, as a junior, the probability of finding jobs that pay over 40k is much higher for software/hardware engineers, pharmacists, etc., compared to other positions.

Are other positions less tiring or less valuable? I absolutely don't think so. But this is the reality of the job market.

Compared to my peers, I don't think I stand out particularly. So in terms of salary, I tend to choose positions that have a higher probability of paying more, even if they're at a similar level.

After mentioning the three main push factors above, I'll now move on to the pull factors that led me to transition.

The push factors are important because they allow me to continuously reflect on whether there's a better career direction and what I don't want.

As for choosing to transition to "frontend engineer," it was due to a combination of the following two "pull factors":

1. Subjective Measurement: Having a Sense of Achievement

As an employee at an online course platform, I was naturally curious about how other companies created learning-oriented products. So I bought courses from other online course platforms to experience them, including participating in Alpha Camp's introductory Bootcamp.

At that time, I discovered that there were only three things I could continue doing until 4:00 am without stopping: coding, reading manga, and editing photos, with coding being one of them.

This was mainly because it satisfied two requirements that gave me a sense of achievement and made me want to keep doing it:

When coding, there's immediate results and feedback that stimulate me, giving me the motivation to continuously optimize.
After completing the code, there's a complete result that I can demo to others, giving me a sense of achievement. Regardless of whether it's good or bad, I'm involved in a large part of the output.

One important thing to note is that to avoid it being just a passing interest, I continued doing it for at least a month and found that these feelings didn't fade away, which made me believe there was potential.

2. Objective Measurement: Skills, Salary, Success Rate

Can skills be taken with you?

Looking at job search platforms, the abilities required for a junior frontend engineer are broadly similar, even across different companies: JavaScript / CSS / inline CSS / React or Vue or Angular / State Management... Even if companies have different domains, the skill trees don't differ much.

Is the salary enough?

Looking at job search platforms, or Googling the salaries of people who have successfully transitioned, at worst it's around 3X k, with some reaching 4X k, and a few reaching 5X k. Given that my salary was only 3X k at the time, the cost was very low. I also found that if you're willing to continuously improve, the salary growth rate is high. With more than a year of experience after transitioning and continuous learning, when jumping to the next company, you could potentially get an increase of over 10k.

What is the success rate of career transition?

I'm a relatively cautious person, so I certainly Googled the approximate success rate of career transitions, including statistics from AppWorks School / Huli Bootcamp / Hexschool and others. On average, the cases of successful career transitions are numerous. As long as you can persist in learning until the end, the probability of finding a job is quite high. The difference lies in the salary level. As mentioned above, my pre-transition salary was 3X k, so the cost was low.

Is there enough information to assist in the career transition?

Yes, if you Google "transitioning to frontend engineer," you'll find various methods telling you how to learn, giving you the opportunity to transition to a frontend engineer.

Combining the push and pull factors above, I pretty much determined to make the transition. However, all of this was limited to my own reasoning and information from the internet. One more crucial point is: "Talk to friends around you, preferably frontend engineers."

This is important. Take your own understanding and share it with relevant people around you. Let them ask questions, even challenge your logic, because there are definitely viewpoints you haven't considered.

The point isn't to decide not to transition after being questioned about risks you hadn't thought of or logical errors, but rather:

Even after being questioned, you can still accept all the risks and say from the bottom of your heart: "I want to make this transition; this is my decision, and I will bear the consequences."

And preferably, talk to a "frontend engineer."

Fortunately, whether it was close friends or colleagues and supervisors from my previous company, they were all willing to listen to my sharing and provide me with valuable advice.

The Final Question to Myself

After continuous reflection on why I was unsatisfied with my current job, actually trying to learn programming, and talking with software engineers or friends, I asked myself one last question:

If I choose not to try now, will I regret it three years later? The answer is: Yes, I would regret it.

This was the final push that drove me toward the path of career transition.

After the Transition, Was There a Gap Between Expectations and Reality?

In terms of the key conclusion: I like my current position. The job after the transition indeed satisfies many of the aspects I was previously dissatisfied with.

I'll share this from two perspectives. One is the more positive feedback, including parts where the transition met my expectations. The other is more negative feedback, including sacrifices made during the transition and challenges that still need to be faced after starting work.

1. Positive Feedback After the Transition

Full of positive energy, I'll mention a few parts that actually achieved my goals:

1. Satisfaction with the Position Itself

I really like the sense of contribution and achievement that comes with my current position as a frontend engineer. For example:

Within three months, I redesigned several external official website pages, moving them from Wordpress hosting to AWS S3, improving performance and optimizing the RWD experience. In addition, I needed to connect the content of these pages to the Contentful CMS platform, allowing the data on these pages to be modified directly by the MKT team through a GUI interface. During each deployment, using CI/CD, scripts were run to fetch and create the latest JSON content data files, which were then packaged into static pages and uploaded to S3.

These pages are highly related to the company's customer acquisition, allowing me to truly feel a sense of contribution. At the same time, I somewhat owned this project and challenged myself with technologies I hadn't worked with before, giving me a very sufficient sense of achievement.

2. Can Skills Be Taken With Me?

Currently, at work, I use JavaScript / TypeScript / React Hook / React Context / styled-component / webpack / Git / Gitlab CICD...

To be honest, there are still many areas where my skills need improvement (I'm a novice, Orz), but at least after improving these technologies, if I want to jump to another company, there's a very good chance I can continue to use them. In other words, skills can be taken with me when changing jobs, and continuous improvement will give me greater rights to choose companies.

3. Salary Growth

Companies usually sign confidentiality agreements, but generally speaking, compared to before the transition, it has increased by about 1.5 times. Whether improving at the same company or jumping ship, in the current environment, it should theoretically get better and better. (Of course, jumping ship leads to faster increases)

2. Negative Feedback After the Transition

Most career transition articles online mention the good results, but I also want to mention some of the not-so-good aspects, as there are always pros and cons. Providing only positive information doesn't seem reasonable.

However, I also emphasize that there are many reasons for negative situations, such as: whether one's personality is prone to anxiety, whether one's physical health was good to begin with, the length of time set for the transition, etc.

1. Deteriorating Health

Health deterioration was somewhat expected; I had anticipated that it might worsen. However, it became worse than I had imagined. My career transition journey was roughly like this:

Before November 2019, I sporadically invested 100+ hours
November 2019, invested 40-50 hours per week in learning and projects
December 2019 - April 2020, invested 60-70 hours per week in learning and projects
April 2020 - May 2020, spent 40 hours per week practicing interview questions and job hunting
May 2020, started working as a frontend engineer

A rough estimate would be about 1300-1500 hours spent, and many times I was still coding late at night in the early morning hours. This period was filled with anxiety.

There were mainly two reasons: one was self-doubt about whether I could succeed, and the other was that I borrowed around 100,000 to transition, which added more pressure (I neither encourage nor discourage this; just think it through. The main reason was that I believed time was more important than money, and the time cost of saving enough before transitioning didn't seem worthwhile).

Even when I first became a frontend engineer, I didn't break the habit of continuous work and irregular schedules. Moreover, because the team I was in happened to be busy, there was no honeymoon period and we went straight into sprints. The end result was recent gastroesophageal reflux, gastritis, and severe bloating. To be honest, my body has been quite painful.

Of course, not everyone will end up like this, and many people maintain good health.

However, if you're someone who easily doubts yourself, constantly pushes yourself at work, and has casual living habits without simultaneously planning how to maintain your health, then you might face similar consequences.

2. Communication Costs Remain High

Why mention this? Because sometimes I hear the incorrect view that engineers don't need to communicate much.

I believe it "really depends on the company and team," as the role of engineers differs in each team. Some may be well-protected and focus on coding, while others may face many meetings.

But no matter what, it's impossible not to communicate. At the very least, you need to be able to communicate requirements and API specifications.

So, the moment when you can most focus on coding and writing projects you like is actually during the transition period, because you can decide any feature you want to write, or even the technology, and create the projects you want to write. There's not much need for communication with others at that time.

In actual work, things don't operate that way. The time spent on communication and meetings often takes up 30-50% of the day, leaving only 4-6 hours of development time, with some people having even less. Not to mention preparing slides for Sprint Demos and such, which also takes time. And usually, the more senior you are, the stronger your communication skills need to be.

By the way, it's actually quite reasonable for software engineers to be able to communicate because:

Software engineers are people who solve problems through coding, not just people who write code. And to solve problems, you need to be able to explore the nature of the problem through inquiry and communication.

Engineers who can explore the nature of problems or communicate technology well while being technically strong are truly impressive.

3. Pressure as a Transition Novice

The transition is just the beginning! It's like just leaving the starting village in a game. The road ahead is still very long, and you'll discover there are many monsters to fight and many people stronger than you. The pressure won't be less. You might even encounter a poor work environment as a beginner and need to hang in there for a while before having the experience to bargain for a better job.

Just out of the starting village, because you're so inexperienced, you can probably grow in almost any environment and continuously encounter fresh technologies or features that keep you learning and growing. There's always information from experts online to read, so you probably won't feel bored or like there's nothing new to play with.

But at the same time, being a beginner means your thinking isn't deep or meticulous enough. Sometimes, when you propose technical ideas in discussions, you might be met with skeptical looks, which of course doesn't necessarily indicate malice. However, you'll need to practice expressing your ideas under distrustful gazes (some people might not trust you simply because you don't have a formal background in the field).

For example, you can try:

Actually setting a time frame for when you want to change companies, which can be long or short. The key is that it doesn't matter so much how others see me because I'll be leaving. What I've learned and can take with me is the most important thing.

In addition, how to maintain your own learning pace while requirements keep coming in is also a significant challenge. I haven't found a balance yet.

Overall, there are very few cases where someone successfully transitions and then has a smooth sailing ending. In most cases: challenges don't stop, learning doesn't cease, anxiety is always present, and life goes on.

Overall, Advice for Those Considering a Career Change

I've condensed and extended the context above to compile the following list of career transition advice:

Reflect on what exactly is unsatisfying about your current career. List all the push factors.
Will becoming a frontend engineer satisfy these needs? List the pull factors and see if they address the push factors.
Try coding for at least one month to ensure you don't dislike it and it's not just a passing interest.
Share your reasons for wanting to change careers and your strategy with friends or engineers, and let them challenge your thinking.
List the risks and ensure you can accept the worst-case scenario; be prepared to take responsibility for the outcome.
Set a clear timeline for the transition and expected salary. For example: within 6 months, annual salary of 600k+.
When you're in a good mental state, prepare strategies for dealing with major frustrations. Have a plan for what to do when frustration becomes overwhelming.
Enjoy the process of coding during the transition; you have a lot of time to write code with high autonomy.
You'll always need to keep learning, so learning how to learn is important. Find methods that work for you.
Keep in mind that transitioning careers is just the beginning; the road ahead is still long.

I'd like to add details to three points: point 6, point 7, and point 9.

Regarding "6. Set a clear timeline for the transition and expected salary. For example: within 6 months, annual salary of 600k+"

This is because having an annual salary target makes it easier to decide what to learn; having a timeline allows you to work backward for time planning. Combining the two makes it easier to plan the transition process.

For example: Once you've established your desired annual salary, go directly to look at job openings, pick a few companies that meet your salary expectations, identify the common required skills, and that's roughly what you need to be proficient in before job hunting.

Then with six months of time, working backward from the end goal: if you want to transition in six months, the last month will be for preparing for interviews, submitting resumes, and job hunting; the second-to-last month will be for creating portfolio projects, and so on. This makes planning easier.

If you're looking for suitable transition courses or platforms, I also recommend doing this first. This helps avoid situations where you complete an entire bootcamp but only learn jQuery, while the companies you want to join are all using React/Vue.

Regarding "7. When you're in a good mental state, prepare strategies for dealing with major frustrations. Have a plan for what to do when frustration becomes overwhelming"

Simply put, when you're in a poor mental state with great frustration, it's hard to have the mental energy to formulate how to relax or relieve stress, because willpower is limited. When frustration is high, willpower is usually depleted.

Therefore, it's best to write down methods for relieving pressure or restoring energy when you're in a good state, for those times when frustration is great and you're about to give up. When things get really tough, just take it out and follow it mindlessly, and you'll have a better chance of recovering more quickly.

In other words, it's actually the concept of "if XXX then XXX" in programming. You can list several options; you might not be able to do all of them, but having them listed gives you a chance.

Regarding "9. You'll always need to keep learning, so learning how to learn is important. Find methods that work for you"

Continuous learning is simply the hallmark of being a software engineer; there's not much more to say about that. But how to learn truly differs for each person. It's best to take advantage of the transition period to develop your own method. The method doesn't have to be very certain or super detailed; at least having one to start with and gradually correcting it later is good.

Using myself as an example: I lean toward problem-solving or goal-oriented learning. It's nearly impossible for me to just read through a document without a specific purpose. I once saw a friend who would regularly arrive at the company from 9-10 am and read the styled-component documentation. I thought it was great and wanted to learn from that, but I gave up after two days.

What I prefer is to learn something when I actually encounter a problem in a project and need to solve it. For example: Recently in a project, I needed to make multiple fetches and needed all these fetches to be done simultaneously, so I looked into Promise.all. I learned it and took notes.

The advantage of this approach is that you apply what you learn immediately, making the learning deep because you've actually encountered a problem and solved it. The disadvantage is that it's difficult to learn systematically; learning becomes very fragmented.

I don't have a good solution for this yet. I'm thinking perhaps writing systematic technical blogs or creating purpose-built projects specifically for learning outside of work might help.

That's my learning method and the reflection process along the way.

Conclusion

I didn't mention my personal background in the article, not because it's unimportant, but because exploring your own "why" takes priority. Before understanding yourself, looking at others' backgrounds might create a bias: "We're alike, so I'm also suitable for transitioning and will succeed/fail as well."

I believe the correct order is: first explore your own goals, then find people with similar backgrounds who have implemented these goals. This would be more meaningful. This article primarily discusses my own goals.

So the most important thing is:

Truly think about what problems a career transition will solve for your career path, and after weighing the risks, make what you believe is the best answer for yourself. Finally, whether the answer is to transition or not, whether to transition to an engineer or another position, be responsible for the results that follow.

The general methodological reminders are in the list above. If you've done all of those, at least you have a basic understanding.

Lastly, if I were to personally recommend transition platforms, I highly recommend AppWorks School and Lidemy Bootcamp! Without intensive peer discussion, collaboration, or comparison, I think it's super easy to slack off. These two platforms both meet my needs and match the current frontend skill requirements.

In the end, I successfully transitioned through AppWorks School, which operates with a well-planned "goal-oriented" learning approach. Its core isn't hand-holding course teaching but a "work-oriented" self-learning model. For example: Every morning you're given a task requirement, and you figure out how to implement it through internet resources, peer exchange, etc., write code to fulfill the requirement, and then push it to GitHub. It's very similar to a real work model. I think it's great because this is truly learning how to work, not how to take classes.

Finally, I'd like to mention something quite important, which is that successful career transition has an outcome that's very important to me personally:

Regaining career autonomy, or confidence in my career.

Before transitioning, the company I worked for was a startup with transparency and high autonomy, meaning that regardless of your position, theoretically, you could propose ideas, and if the company had resources, there was a chance to implement them.

You should theoretically be able to create your own stage. But I couldn't create anything; I didn't have any good ideas, and I didn't have any particularly outstanding work abilities. It's not like I wasn't trying or wasn't serious? What should I do?

In short, I was in a state of high self-doubt regarding my career.

The outcome of this transition is something I achieved after careful consideration and reflection, multi-faceted assessment and consultation, taking a certain level of risk, making a decision, and actually executing it to completion.

This process helped me regain some career confidence because it was through my own choices and efforts that I turned around my career situation. It also made me believe that within certain levels, through providing appropriate educational resources and a good learning environment, there is an opportunity to promote horizontal level mobility.

Of course, the transition process included a lot of assistance and encouragement from many people. Whenever I reflect on all of this in the quiet of night, I still deeply feel that I am a fortunate person.