Logs of a Software Engineer | EP.3: Five-Year Anniversary

Preface

This year marks my fifth year as a software engineer, and coincidentally, it's also the year I embark on a journey to seek employment abroad. While I'm uncertain about securing my ideal job in the UK, reflecting on the past five years, I've learned and experienced a great deal as a software engineer. This journey has been both miraculous and fortunate, perhaps worth documenting properly.

Five years is neither long nor short. Looking back at the Logs of a Software Engineer | EP.1: From Zero to One and Logs of a Software Engineer | EP.2: JKOPay I wrote back then, I feel that I grew very quickly when I first entered the workplace. Every day was filled with endless new technologies and knowledge, making life both fulfilling and challenging.

Stability Over Novelty

After two years at Jkopay, I joined an American company that aligned with my job-seeking goals at the time—good compensation, opportunities for international collaboration, and a great team culture. However, my pursuit of new technologies gradually faded over these three years.

Initially, I thought I had become lazy, leading to a dulling of excitement towards new technologies. To reignite that passion, I started writing a Frontend Newsletter in 2024, hoping to maintain my sensitivity to new technologies by organizing trends and knowledge. But I slowly realized that I hadn't lost my passion for software technology; instead, I began to value the stability of systems and frameworks more.

When I first joined this American company, I noticed the team wasn't using popular Meta Frameworks like Next.js or Remix, but a self-developed framework. At the time, I was somewhat disappointed, especially since Next.js was at its peak, full of buzz, and I had no hands-on experience with it.

But three years later, I gradually saw the value of this self-developed framework. Although it uses somewhat outdated technology and the development experience is nothing to boast about, it stably supports various needs across the company's service projects. Whether it's vertical scaling or further splitting into a micro-frontend architecture, it can handle it. This architectural flexibility gave me a new understanding of frontend engineering.

If you really want to learn new technologies, you might as well practice and explore by writing blogs or managing your own Side Projects, which was why I participated in the Ironman Contest and wrote the Newsletter. In work, what's often more important isn't using the newest technology but writing stable and efficient code. Unless a new technology or framework can clearly offer value beyond stability, hastily introducing it in team development might increase maintenance costs and risks.

Staying Open

Initially, I was very unfamiliar with backend development. I remember during every meeting when assigning tasks for the next Sprint, I would instinctively avoid backend tasks, preferring to choose frontend projects I was familiar with. Whenever I saw a task that involved backend work, a voice in my head would say, "I'm not qualified; I'll mess it up." These voices were actually my own self-doubt.

Not long after, the company underwent several reorganizations, leaving some teams with backend needs but insufficient backend engineers. That's when I started to actively engage in backend development. Some projects were really confusing at first, but as long as I dared to ask and spent time on them, I gradually became familiar with them. Even though I'm not a backend expert, at least I no longer avoid it like before, treating it merely as a problem to be solved.

Feature Delivery

At my previous company, I had never encountered A/B Testing. The development process was relatively straightforward; all features would go directly into development and launch as long as the project manager deemed them okay. It wasn't until I joined my current company that I truly understood the process and value of A/B Testing.

Since my team is responsible for consumer-facing products, the two most important things after feature delivery are usually: Error Monitoring and observing the performance of A/B Testing. The success of the latter is typically judged based on the Success Metrics defined by the project manager in the One Pager.

• If the feature's goal is to increase GMV, then we need to observe whether the Treatment group's revenue performance after the feature launch is better than the Control group's. If it's significantly higher, it means the feature's release is positive.
• If the feature is simply a service migration, A/B Testing can serve as a Feature Flag, where theoretically, the Treatment and Control groups' performances should be nearly identical. If one group's performance is abnormal and statistically significant, it indicates something's amiss, requiring further investigation.
• If the feature's goal is to increase the Click-Through Rate (CTR) of a certain block, it needs to be verified with other tracking tools, such as embedding event tracking in the code, querying the database, or observing click ratios and usage behaviors through third-party analytics platforms like Amplitude.

After three years of this baptism, I've realized that the real difficulty in developing new features often isn't the development itself but how to effectively monitor and verify after feature delivery.

When monitoring results don't meet expectations, how do we find the problem and make improvements? This work is no longer a solo effort by engineers but requires close collaboration with the team's data analysts and project managers to find clues from the data, observe users' behaviors with the new feature, and even rethink and redesign the feature. The entire verification and adjustment process can sometimes take several times longer than the development itself, but it's also what determines whether the product can create value for the company.

Scrum Master

The role of Scrum Master was something I only learned about after joining this company. The core task of this role is to assist the team in smoothly executing the agile development process. After a year with the company, I had the opportunity to take on this role, which also allowed me to have more exchanges and collaborations with project managers and supervisors.

From planning the backlog for each Sprint, understanding each team member's Bandwidth, discussing the next phase's task details and required resources with supervisors and product managers, to assigning tasks to team members, and even the retrospective and adjustments after the Sprint, these became part of my daily routine outside of development.

At the same time, ensuring that the project's Stakeholders are clearly aware of the team's current progress and how to reasonably insert urgent tasks into the Sprint requires thoughtful design and communication.

For example, I would encourage project owners to synchronize their current progress with the relevant project group weekly, keeping supervisors or project managers on the same page. And when there's an emergency task, first list all potential items for insertion, clarify which are truly "urgent and important," and then, after coordinating with supervisors and product managers, carefully insert them into the current Sprint.

Through such mechanisms, we can meet business needs while maintaining the stability of the team's development rhythm, avoiding situations where "insertions get out of control" during Sprint retrospectives.

However, for me, the real challenge isn't these processes and planning but the human aspect. More difficult than assigning tasks is: How to ensure each team member clearly knows the projects they'll be responsible for next? And how to discuss with supervisors whether any members, based on career development considerations, wish to try different types of projects?

Taking "letting members know what the next project is" as an example, the challenge often comes from information opacity. Most of the time, project managers may not be able to provide the demand planning for the next Sprint in advance. Apart from divining from the quarterly roadmap, I usually adopt two strategies:

1. Increase demand forecasting: Proactively coordinate with project managers to provide slightly more tasks than the current Sprint requires, giving the team leeway to predict future directions.
2. Proactively create tasks: Discuss with supervisors about internal processes or technical debts that the team can improve. When members finish their projects, they can optimize the team's system while waiting for the next task.

In short, the role of Scrum Master is quite interesting and can also enhance one's communication skills. During this time, I've learned a lot through this position.

Other Thoughts

• Ownership at Work:

  Over the years, I've gained a deeper understanding of "work ownership." Regardless of rank, becoming the Go-to Person for a certain project or system is the best way to increase one's influence within the team.

• Helping Others Solve Problems:

  This process itself is also a learning opportunity. Often, while clarifying others' problems, I gain a deeper understanding of certain knowledge points. It's not just collaboration but mutual growth.

• Deliberately Challenging Oneself, Doing What Feels Difficult:

  Growth often comes from stepping out of one's comfort zone. When you start exploring unfamiliar areas, what you learn often exceeds expectations. Making oneself a Yes Man who says, "I can try," can accelerate learning speed and reduce fear of the unknown, replacing it with curiosity.

• Treating Projects Like One's Own Children:

  Whenever responsible for a new feature or project, try to treat it like caring for a child. Besides self-testing, also add Feature Flags so that if something goes wrong, you can respond immediately. After the feature goes live, conduct real-time monitoring to ensure everything works as expected.

Conclusion

Writing down these fragmented thoughts is also a way to organize the journey of these three years. If there are any new insights in the future, I'll add them gradually!

Looking at the rapid progress of AI, sometimes I wonder if the profession of software engineer will become like the textile workers during the Industrial Revolution. After all, the current top LLM models can write code several times faster than the average person, with quality that's not bad or even better, and the top models we use now will surely be the worst in the future 😂. If this hypothesis holds, I hope this article isn't the last episode of 《Logs of a Software Engineer》. Even if roles change in the future, I still look forward to using AI to create a product I can truly be proud of in the AI era.