Reason
On May 31, the product manager at our company sent a message in an internal group about hiring. After a friendly discussion, we reached an agreement: I began to take on some product responsibilities, partially switching roles without fully moving. I’m recording this reflection for friends who feel lost, and as a log for myself. If you’re short on time, feel free to skip to the key points at the end.
Career Development Review
0. Blind Exploration
In my first year of university, I did many non-technical things. Then I decided to choose a high-level programming language as my main focus. After extensive research between Java and C#, I chose C#. The reason was simply that C# had better Chinese support (Microsoft documentation, Visual Studio, and IntelliSense were all in Chinese). Moreover, C# is more expressive in code about what you want to do, whereas Java felt more verbose (for example, converting a date object to a string in Java 8 – anyone familiar knows how tedious that is).
Regardless, looking at the external environment at the time, choosing Java would have been a better option. But I had a strong sixth sense that made me feel resistant to Java, so I chose the more comfortable C#. I believe that only when you feel comfortable doing something can you sustain long-term commitment to it.
The next challenge was resource availability – the university had no C# courses; all classes were Java! Only a handful of teachers knew C#. Looking back, I don’t know how I persisted alone. After half a year of learning, I still couldn’t create even a small program… However, during this period of blind exploration, I discovered some non-syntactic aspects of programming (like a deeper understanding of object-oriented concepts). Later, I signed up for an online training program at Xikétáng (a Chinese training platform) and truly started getting started.
1. University Project Team
The early part of Xikétáng’s C# training focused on fundamentals, including not only syntax but also engineering experience (e.g., how to analyze a task, where to start thinking). By the last two years before graduation, I could independently build a "Student Management System". Around that time, I heard from a friend that there was a project team at school where I could skip classes – a chance to get involved in real development. But they had enough developers; they needed testers. After an intensive summer of studying testing knowledge and Selenium, I passed the interview and joined the testing team.
Testing work was relatively relaxed, but it gave me a rare opportunity to view the project from another angle, and I still had time to polish my skills. One proud moment: I found a bug during testing, investigated it in the browser, identified that a regular expression was wrong, then wrote the correct regex and sent it to the developer to replace directly in the code. Veterans might recognize this as "test development" – understanding both testing and development.
During this time, I also attended the VS 20th anniversary meetup. A guy from a company was recruiting, and I interviewed but failed because I didn’t know web development. After returning, I started transitioning from C/S to B/S. Within two months, I launched a personal blog with both frontend and admin backend, deployed it on a public cloud, registered my own domain, filed for ICP, and used HTTPS, CDN, and some other technologies. By then, I had a full pipeline from development to deployment.
My key takeaway from this stage: Don’t limit yourself to development. Through these experiences, I never truly participated in project development at school, but I unexpectedly came into contact with many non-technical things.
2. Internship at Newegg China
Later, as if by chance, I started an internship at Newegg. At that time, two big events happened: the release of .NET Core 2.0 and the rise of microservices. I was stuck with an old Pentium 4 CPU for my internship machine, so slow that I had to code using Notepad + the command line. Because it was a new framework, the intern team and I built a simple three-tier architecture from scratch, and I managed to understand the basic .NET Core web framework (middleware, HTTP pipeline). Then I joined the MKPL team, which was exploring .NET Core at the time. My work there included building Core SDKs and project frameworks, researching UT, doing deployments, and other miscellaneous tasks.
My key takeaway from this stage: Open source.
Later, when I left Newegg and was asked in an interview what the biggest difference between .NET Framework and .NET Core was, I answered: In the Framework era, low-level libraries were black boxes; in the Core era, the philosophy shifted from closed to open. Previously, development resources (like SDK libraries) were mostly provided by Microsoft; non-Microsoft ones required long consideration before adoption. After Core, we trusted the community more and actively participated in it.
Back to Newegg: Another important thing was strengthening fundamental skills. Here’s why:
- Newegg is a company with over 20 years of history; our team’s projects were all over 10 years old… You can imagine how many pitfalls existed.
- MKPL was responsible for the seller platform, which needed to interface with other teams (like orders, returns). Problems from other teams often surfaced in our project.
- The overall atmosphere at Newegg was that members needed to proactively drive project progress, rather than waiting for managers to assign tasks. For example, if I was responsible for a certain API in the project, I had to negotiate field definitions, interaction logic, test logic, write dev docs… In short, I was the direct owner of that API, not my PM.
During this time, I not only improved my technical knowledge but also accumulated essential professional soft skills. For instance, my bug count went from among the worst as an intern to around 7th or 8th place, despite having much more development work than before.
My key takeaway from this stage: Professional fundamentals. Newegg was small but complete, covering everything from workflow management to internet architecture at a macro level, and basic employee skills at a micro level. It was far more comprehensive than other companies, which made me feel very comfortable when I later moved to smaller companies.
3. Two Short-Lived Jobs
I left Newegg in 2019, because within a team of fewer than 20 people, there were already two architect-level positions, leaving very limited room for career growth. The next two companies each lasted only 3–4 months.
First company: The product concept was good, and the boss had money. But the boss didn’t understand software! This led to major changes at the end of each project cycle, without realizing the magnitude of such changes. Eventually, the boss complained that the software department had no output for over a year. The result was that within two months of my resignation, all the old-timers had left—basically everyone related to software was gone. On the day I resigned, I found out my department manager and product manager were also resigning… What?!
Second company: It did government projects, essentially taking one codebase and adapting it for various regional departments. They focused only on team building and making sure the project worked when clients needed it… but if it crashed after a few days, nobody seemed to care. After a while, I felt this place needed more slick veterans rather than someone like me.
My key takeaway from this stage: Too protected by Newegg’s good atmosphere. At the first company, my main role was coordination? Internal team coordination, inter-department coordination. I wrote less code in 2–3 months but dealt with lots of interpersonal matters… The second company was a total pitfall. However, the experience wasn’t wasted: I gained a lot of skills in workplace communication beyond pure technology.
4. Senior Handyman
Then I came to my current company. To make a long story short: I am responsible for promoting new technologies, building project frameworks, maintaining common libraries, internal server maintenance, communicating with the product team, and occasionally coordinating work among colleagues…
Technically, it’s roughly: 35% C# code, 55% JavaScript code, 10% shell scripts or other configuration. Before this company, I refused to write JavaScript. When setting up CI/CD for the department, image names and tags had to follow management requirements. I wrote a small C# tool and put it in the CI/CD pipeline (whereas most CI/CD in the industry uses shell scripts and YML configuration).
The turning point came here: Our testers only knew basic click-and-point, developers only cared about development, and the product people didn’t understand technology. I often acted as a bridge. The experiences from stages 2 and 3 helped me understand what testers are thinking and what product people are thinking, and then translate those into terms developers could understand or vice versa. The internal relationships in the company are very good, but people from different roles have different thinking habits developed over years. When work gets busy, they often forget to "translate into a language the other party understands." After all, we are all building one product together; if the product generates revenue, we all survive better (with benefits and bonuses). This situation also enabled me to smoothly take on some product responsibilities while others switched roles entirely.
My key takeaway from this stage: Success is not accidental. Actually, I wanted to take on product work as a backup plan for myself. The fact that I could negotiate this difficult dual role (managing dual roles has higher management overhead; the company has over 800 employees) was based on my past accumulation.
5. Summary
While writing this article, I reviewed my career development. The main point is that I didn’t waste energy. I may have done inefficient things (like choosing C# in college with little output for half a year), but those experiences accumulated and later played a role at another time. By a twist of fate, I now know a bit about networking, a bit about software development and engineering, a bit about the software project lifecycle from start to end, with some accumulation in various areas, while still keeping my main skill—back-end development—strong.
Future
It’s said that age 35 is a big sword hanging over us. I am uncertain, but not anxious. If things go south, I can still transition to product. The medical software industry is also heavily experience-based (that’s why the product department hasn’t been able to hire externally and needs internal recruitment). In the future, maybe other opportunities will arise. Moving forward step by step, though my pace may be slower than others, it won’t go backwards or crash. On the other hand, I can leverage product experience to break through my current mid-level developer bottleneck and move toward the "senior" level I aspire to.
Advice for You
Everyone’s needs and situations are different. You can invest in multiple directions; don’t fixate on just one thing. Besides IT, I also go to pen-and-paper RPG groups on weekends—that’s a whole different domain.
- If your current job or situation isn’t satisfying, don’t rush to jump. Calm down, think about what you really want, then plan for the next 3–5 years and don’t give up easily. Even if that plan leads to failure, failure is also experience, right? Life is long.
- If your current job or situation is okay, don’t be too complacent; there’s no absolute stability. Similarly, you can prepare or accumulate for your own plan in case of unforeseen events.
- Do things that are right but time-consuming.
Regarding point 3: For example, contributing to open source. Many people start with enthusiasm but gradually give up when they see no return. But if you love technology and are willing to share it, the moment you share brings you joy—that already puts you in an unbeatable position. Any additional gain is just a bonus. This way, even without external rewards, you’ll have the intrinsic motivation to keep investing. Like it, pay for it. Otherwise, you will become a slave to life.