avatar
Published

Retrospective on My First Three Years as a Software Engineer

Retrospective on My First Three Years as a Software Engineer
็›ฎ้Œ„

Note: This post is translated by AI. If you find any unnatural phrasing or errors, please feel free to contact me via email or other channels. Your feedback is appreciated!

I have been writing and editing this article for about a month. Actually, later on, I just added a little bit when I thought of something. It is a bit long, and most of it is written for myself. If you are interested in the thoughts of a non-CS liberal arts graduate transitioning to a software engineer for three years, feel free to take a look.

(Hope to be more regular later, reviewing once a year won't be this long haha)

Why review? Actually, it is to summarize what I have been doing in these three years. As a software engineer (or modern person), knowledge anxiety is a very common thing. But reviewing what you have done regularly, knowing how far you have come, what areas are unsatisfactory, what the next step is and how to adjust, will greatly reduce anxiety about the present. The Importance of Summarizing | by Denny

What I Did Before Becoming a Software Engineer

I studied Philosophy at NCCU. From freshman to senior year, I took courses in Business Management, Psychology, Sociology, and Information Management. In my junior year, I worked as an insurance sales agent at Fubon for a year and a half. Working as a salesperson let me know that I like contacting people, but I don't want to contact people when working.

After leaving the insurance industry, I actively engaged in sociological research. In the second semester of my senior year, I submitted a college student research project to the Ministry of Science and Technology. After the project was approved in the first semester of my fifth year, I wrote a cultural study thesis analyzing IG. During this period, I understood the difficulty of pursuing academia and decided not to pursue it.

Software Career Review

TL;DR

  • In university, the first benefactor: My opportunity to write code
  • At work, the second benefactor: I started to understand what "writing code" is about
  • Before leaving, the third benefactor: Gently mentored me, progressively led me to develop some cool stuff, and also helped me build confidence.
  • Current status: Will talk about it below.

2018.10 Joined a study group organized by a friend, becoming the starting point of my software career

  • When working as a salesperson, a client who was a software engineer sparked my curiosity about the software industry. Then it just happened that a friend I met through dancing wanted to start a web frontend study group. I joined without thinking too much at that time. My friend originally thought I would quit myself if I couldn't learn it, however - my software career started by accident like this.
  • Thinking back to the level at this time, it was probably having never heard of HTML, CSS, JS. Just knowing the basic concepts that "HTML is the skeleton of the website, CSS is the style of the website, and JS writes interaction logic" took me a long time.

2019.04 Started Internship

  • Actually, this internship also came very suddenly.
  • At that time, I thought I couldn't make a living by coding yet (in fact, it was true), so I first interviewed for a Dcard community marketing intern. After not getting in, I was thinking about whether to work part-time at a cafe.
  • But the company of that friend who organized the study group happened to be recruiting inexperienced interns, and then I became a web development intern without knowing how to write JS.
  • During the internship, it was actually very painful. My friend thought I should solidify my basic skills before coming in, and I agreed very much after coming in, but at the same time, I am very grateful for this honing that allowed me to step into the software industry faster.
  • In summary, I feel that this time was like a period of "wanting to fly before knowing how to walk". When I couldn't write JS, I had to start writing React, and things written would directly enter the product.

2020.02 Converted to Full-time

  • Before converting to full-time, I went around the island for a week and a half, went to Japan for a week, and then prepared to formally start my software career.
  • After converting to full-time, except for formally becoming an office worker and having a little more salary, the overall feeling was about the same as the previous stage.
  • I was still struggling, even my ability to debug myself was very insufficient. Often just writing a few lines of web pages would crash, opening the console found a sea of red, and then I looked to the colleague next to me for help.
  • Around July, a very senior frontend engineer joined our company. He was very strong and willing to share. I benefited a lot from listening to his sharing in the company's internal study group at that time, so I started to cling to him to ask questions, and later also started to write projects with him โ€” Taking this as a dividing point, I started to understand what "writing code" is about.
  • He is the second big benefactor in my career. (The first is that friend who started the study group)

2020.09 Military Service

2021.09 Resignation

  • Internship plus full-time for two and a half years, I left the first company I worked for because of "salary, growth, and wanting to make products".
  • First, that senior engineer mentioned above left, and that benefactor friend who brought me in also left. Although another senior engineer came in between, he was the third benefactor in my career. He mentored me in a very gentle way (the one who left taught very well, but often made me feel like I was a retard), but he also left within less than a year, so I judged that the growth of continuing to stay here would be very limited.
  • Secondly, this company is an outsourcing company, so many things are thrown out after development. It is actually difficult to touch subsequent maintenance and integration. And during development, it was often stuck due to customers' weird requirements and schedules. Development processes like Scrum also couldn't run well. I want to know more practically how a SaaS (Software as a Service) runs in the market, rather than packaging and selling to customers after developing something that works.
  • Finally, it's the salary. The numbers are clear, so there is nothing much to say.

2021.10.18 Entered Current Company

  • Rested for 18 days after resignation, I entered the current company, which will be mentioned in the current status section below.

Why Choose This Time Point to Review? Why Three Years?

Three years, is the time I got rid of the imposter, and became the real deal.

I started to understand what writing code means after writing code for about a year, and only recently truly identified myself as a software engineer. I finally feel that I am qualified. When calling myself a "software engineer", I no longer feel a little guilty. So, I dare to post this article.

I finally walked out of "Imposter Syndrome".

Why Did It Take Three Years to Affirm Myself?

Besides being a person lacking self-confidence myself, there are three other reasons.

  1. Possibility

    In these three years, I have always been exploring possibilities, whether it is the possibility of other career developments or my own possibility in software engineering. In short, I have always been unsure if I have that ability, and didn't know if I wanted to be a software engineer.

  2. Escaping is not shameful, but I always chose to escape

    My mindset was not strong enough. Facing anxiety and discomfort of not being able to write, I often chose to escape instead of solving the problem. But actually, this can also be said that I didn't believe in myself enough, and was too anxious to force myself to write it out. Finally, after finding that I was too used to escaping, I forced myself to face it. Later I found that in software development, as long as you are willing to spend time and actively look for methods, you can definitely solve the problem. Because almost everything you want to do has been done by someone, Google can definitely find the answer. And sometimes it's just that you were assigned a problem that exceeded your ability too much or was too weird to handle.

  3. Successfully found the second job as a software engineer

    Actually, I have always been afraid that my software engineer career was just a flash in the pan. After all, before joining the study group, I had nothing to do with writing code. I was not familiar with computers, and my math was not good (failed Math Yi so couldn't get into business school). And my image in the first company was also somewhat set. The boss didn't have much expectation for me, nor would he assign any important work to me. But after two or three months of intensive preparation, making up for many classic JS interview questions, and starting to grind Leetcode, then interviewed with a few companies, finally got two Offers, and after rejecting one of them, I even got retained by the supervisor, and the salary also went up a level. This greatly enhanced my confidence.

Below I will elaborate on some methodologies of how I affirm myself.

How Did I Affirm Myself?

This will start from the problems I encountered when I was a rookie

  1. Don't know if I am asking stupid questions
  2. Don't know how to measure my progress, whether the direction of my effort is correct
  3. Don't know if I am qualified enough

Don't Know If I Am Asking Stupid Questions

  • As long as you ask questions correctly, there are no stupid questions
  • How to ask correctly: "At least verify information first, sort out logic, describe the problem as carefully as possible, and confirm with the other party if there is any misunderstanding that caused the Bug."
  • In short, don't be a free-rider.
  • Recommended reading: Precise Questioning Technique You Should Learn on the First Day of Work

Don't Know How to Measure My Progress, Whether the Direction of My Effort Is Correct

  • The simplest and most brutal way is "Go for interviews". After all, learning so much is to apply it, to fight in actual work. So if you are not sure about your current level or if you learned well, the Senior of the other party will let you know during the interview.
  • Otherwise, judge from the following ways:
    1. Target company's JD, see if there are any Technology Stacks you don't know yet.
    2. If you know all Stacks, then directly search "XXX Interview", you will see many questions. Of course, there will be some filler questions, but I think the general direction can be grasped like this.
      • ex: React Interview
    3. If you want to be solid, follow Developers Roadmap to learn, but for the choice of some tools, it is still recommended to see what the company you want to go to uses.

Don't Know If I Am Qualified Enough

When I only stayed in the first company, I was always worried that I wouldn't find a job if I left there.

We fear because of the unknown.

After I started interviewing, I slowly stopped worrying about this, because I started to understand how the interview process runs. At first, I would definitely fail a few companies, but reviewing from these wrong experiences, I would know that interview questions are much the same (at least for Junior Level, those serve as classic questions). After that, it is constantly in the cycle of "Interview, Review, Supplement Knowledge".

And after entering the current company, I found that my speed of getting started is actually not slow (according to colleagues). In projects using different frameworks (Vue), I can quickly help Debug and contribute value. This greatly improved my self-confidence.

Next is the slightly clichรฉ part. I will talk about before the interview, that is, when I deeply felt that I was not ready yet, how I felt that I was ready.

First, work very hard. Learning programming fits "Plateau Phenomenon" very well, please see the picture directly.

Plateau Phenomenon

Next is Learn, Practice, Balance

Learn

  • Learning, whether absorbing knowledge from seniors, friends, videos or articles.
  • And constantly iterate your learning method during the learning process. Accustomed to learning by doing? Doing after learning? Watching videos? Reading articles? Take notes or not? How to take notes? Whether to output notes into blog to train expression? etc.

Practice

  • "Learning without thought is labor lost; thought without learning is perilous" (Although I dislike Confucianism, I have to say this sentence is really good)
  • After learning, the next step is to "do it". Always talking on paper actually feels very ungrounded.
  • And on the road of web development, there are thousands of ways to have problems, like local settings, code versions, package versions, browsers etc., even missing a punctuation mark or typing a wrong word will cause errors.
  • So things learned have a very very very high possibility of not being applicable to your current project.
  • At this time, if you have done it once before, at least it will be much more grounded, knowing that this method is indeed feasible. It's just that to coordinate with the environment of the current project, some more settings need to be done. Thus, the scope of the problem can be initially reduced, not completely clueless.
  • And being completely clueless is very easy to happen when learning for the first time. You completely don't know where to start with an Error.
  • The best thing about software engineering is that you can build your own world between 0 and 1 just by typing on the keyboard.

Balance

  • Life cannot only have writing code.

Burnout 101 source

  • Software engineers generally have serious knowledge anxiety, and actually many industries in contemporary times have similar problems.
  • Realizing the need for balance was after I started fitness and learning Japanese.
    • Fitness made me feel that my physical strength and body shape are moving in a good direction. Dopamine produced by exercise also makes me less prone to anxiety. After physical strength improved and eating healthily, I rarely feel drowsy during the day, and sleep better.
    • Japanese is because I like Japan very much. Being closer to the culture I like makes me feel very happy. And language is much simpler compared to programming. You get it if you memorize and practice. This simple and brutal feedback also makes me more confident in myself, and this confidence can also extend to myself writing code.

Fitness makes me feel that my physical strength and body shape are moving in a good direction. Dopamine produced by exercise also makes me less prone to anxiety. After physical strength improved and eating healthily, I rarely feel drowsy during the day, and sleep better.

Japanese is because I like Japan very much. Being closer to the culture I like makes me feel very happy. And language is much simpler compared to programming. You get it if you memorize and practice. This simple and brutal feedback also makes me more confident in myself, and this confidence can also extend to myself writing code.

Finally, talk more with people & scroll Twitter & grind Leetcode thoughts

These three things made me understand that I have no problem. The frustration I face in writing code is a universal experience. Just like a comment area of [Leetcode - Coin Change] solution

leetcode comment

  • It turns out that I am not the only one who breaks down in front of the computer because I can't solve it, and then still don't understand after reading the solution!

  • Not being able to write is not one's own problem, but just like ordinary people, need to go through the process from not knowing to knowing.

  • Some difficult things are just difficult. It is possible to learn for several days, several weeks or even half a year or a year. And everyone walks through step by step like this. Then seeing my CS major friend not much more relaxed than me when grinding Leetcode, made me realize that everyone has gone through the same stage as me!

  • After breaking down, after emotion passes, should start learning.

  • Process: "Look at Code directly -> Google finding articles, solutions -> Youtube watching videos detailed explanation frame by frame -> Ask people directly."

  • If can't understand Code, read text. Directly google the question to see if anyone explains it. If interpretation is still not understood, watch video. Actually a bunch of people on yt are filming detailed explanations. Explaining line by line and attaching flowcharts. Pausing while watching taking longer time will definitely understand.

  • I consider myself not a very smart person, but following this process, willing to spend time, I almost haven't encountered things I really can't learn. Just might need to spend a lot of time, supplement a lot of edge knowledge, but definitely can happen.

My Current Status

Career

I am now in a startup company. There are only me and my supervisor as engineers. Need to handle two frontends (about to integrate into one), one backend admin, one unified backend, and an advertising backend developed for a partner company. The salary in the third year is already about double that of the first year, but compared to many people around, it is still just ordinary.

Originally expected to be full-stack when coming here, but because still didn't have much concept of backend, only occasionally can help open API, mainly still responsible for frontend part. Also because the company is too small and experienced some changes, actually many times couldn't concentrate on writing Code. Been here for almost a year, feeling of marking time is majority. Recently stabilized and started to be more fulfilling, preparing to write all frontend by myself, and there will be two senior full-stacks helping Code Review, hope to have some growth!

Technical Stack

Currently mine is not much, have a certain level but not too solid. But have more methods on what to learn, what want to learn and how to learn things solidly.

Basically I can make basic requirements related to frontend, but making it is just the first step. Continuous integration optimization, system design etc. still have a lot needs to be strengthened.

Projects I participated in

  1. Theater Venue ERP (Original paper process fully online)
  2. Theater Venue Official Website
  3. Gym ERP (Including employee, course scheduling, contract, product etc. management screens)
  4. Custom React UI Library (Open Source)
  5. Landing Page of a product
  6. ERP for enterprise and influencer discussing business matching
  7. Blog advertising platform (Side Project shouted for a long time but didn't start work)

The more challenging one inside should be React UI Library. Experiences of other ERPs are much the same. Mainly also structured by a senior, I just went in to implement.

Next Step?

Career

Engineer's career development is divided into Engineer Manager and Individual Contributor. In the future, would like to develop towards Engineer Manager, but this also requires jumping to a company with that kind of system and scale first! Recommended reading: Cultivation and Growth of Software Engineers , Podcast

Technical Stack

Pay off technical debt, organize technology of projects handled, problems dealt with, and things didn't understand when writing at first. Ensure won't be stumped by questions related to projects during interview. Next is "Go Deep" and "Go Wide".

Go Deep

  • Mainly JS, TS and React / Vue need to be more familiar. React is still the majority after all, and Vue is the main development framework of current company.

Go Wide

  • Basic functions of various roles in Web life cycle (FE, BE, SRE, DevOps, DBA) should at least be known. After all, will touch a little when going to the back. Actually it's like concept that Google's SRE definitely writes Frontend better than me. But strictly speaking it's just basic. Probably just do some Side Projects to go through everything once.
  • Internet
  • Security
  • If possible, touch other languages more, Rust, Golang, Java / Kotlin etc.

Besides depth and width, Leetcode, data structures and various algorithms are also continuously accumulating. Now is writing at least one question every day, write more if have time, and finish grinding basic question types [Blind 75] first.

Although these things are all listed, none of them is a small topic. Just learn slowly at a pace that won't crush myself, see how much I can learn when reviewing next year!

Conclusion

Review my original intention of being a software engineer:

Yearning for "Craftsmanship Spirit", free working mode and possibilities contained in software industry. Always worshipped that kind of craftsman who sharpens a sword for ten years in my heart, and writing software can exactly build various cool web pages or systems. (But discovering didn't do any Side Projects after writing for three years, really need to not forget original intention hey)

If I could chat with me three years ago, I would tell him:

  1. About early stage of career change, laying good foundation and choosing right company is very important. In best case, can find relatively complete system, have mentor or at least someone who can guide you. I feel my career choices stumbled so far. If do it again, I will definitely enter a company with some scale first. But actually there were also trade-offs of many realistic factors at the beginning.
  2. Software engineer is a profession that can't be without love. Without love, you will be very painful. Because things we need to learn are too many. If you don't like software, I can hardly imagine you can invest so much time and energy in this.
  3. Engineer is indeed a quite comfortable profession. Not too many rules, free commuting, can work remotely, can work anywhere as long as there is computer. Salary generally has medium-high level. Although ceiling of software in Taiwan is relatively low, going abroad or in foreign companies can still have very good development. (Same, choice is more important than effort, choose company carefully.)
  4. Career change from non-related major is really not easy. Behind successful cases you see are more people who jumped ship halfway. (Survivorship Bias) Jumping ship is not necessarily insufficient ability, might just purely be no interest. Career change requires effort and opportunity (for ordinary people). That kind of very smart people will succeed in whatever they do. Like I am not. There were really too many luck components along the way. But I am very grateful to myself who was willing to try that year, and benefactors met along the way.
  5. Possibility won't be shrunk because you work hard in software industry I am actually quite sure that thing I want to do most is not writing software. But speaking of "job", my best choice now is writing software. Go to cultivate more in field interested in if have spare energy. Try to balance dream and reality. (What I want to do most is creation or sharing probably. Possible directions are writer, blogger or lecturer etc. But no matter which one I still can't use to make a living, so just seize time to enrich myself while taking good care of main job!)

Throughout article actually seems no key points, just recording a little mental journey. Mostly talking to myself. Thank you and hard work to readers who read up to here!

โ€”

Finally, thank benefactors met in these three years: Xiaobai, Steven, Bob, Jay Chen, Jay Chou, Boogie Yan, Kyle Mo.

Every one of you gave me motivation and direction to continue moving forward, so that I wouldn't jump ship halfway. Now, I have sailed to the Grand Line, ready to continue to venture in the New World.