The Programmer's Journey

July 2014, graduated from university. July 2017, 3 years of work. It’s time to record, reflect on the past, present, and future. Sorting through everything I’ve done before gives me some closure.

Thanks to good memory, I can clearly trace back every job I’ve done since starting work. Since it involves commercial information, it’s better to use code names. I understand them perfectly myself, while others can just get a general idea, haha.

2014

Early Year

In the first few months (February-April), I did data collection, mainly writing regular expressions based on webpage source structure for matching and scraping. The tool used was LocoySpider. These seemingly tedious months actually brought several gains:

• Regular Expressions

These were learned in university programming courses, but learning and using are two different things. In practical application, I have to admire the authors of regular expressions for designing such beautiful things. When a novice user uses text search in Word or Windows system search, how would they know that regular expression concepts are behind it? One could say that text search is fundamentally based on regex concepts.

• Web Crawling, Data Collection

This experience gave me initial understanding of data collection and crawling, providing solid foundational knowledge of HTTP protocol, webpage source code, website structure, etc. Although I didn’t go deep into it, these had a big impact on me. I’ve always believed that technologies influence and interconnect with each other. Understanding leads to benefits, it’s just a matter of when those benefits come.

July-August

I started joining a project team for web development. This project was called A, and the development cycle spanned until Chinese New Year 2015. The web framework used was Grails (which of course was based on Java’s SpringMVC). This was my first real web development project. I remember I was only responsible for one module initially, but as development progressed, my curious and thoughtful nature meant I didn’t just understand my own part but the entire system. Over time during development, both my coding skills and understanding of the entire platform reached a certain level.

During this period, a colleague Fu* resigned, citing stress as the reason. Since they couldn’t be replaced quickly, I took over his development work. Since our two areas had overlap, it wasn’t too problematic. Later, I became responsible for the main modules of the entire project. By this time, I basically controlled the development of the entire web platform, except for the personal center section. In early 2015, the web platform successfully launched. For me, after half a year of training, I felt the joy of development for the first time. Reflecting, I gained several things:

• fusioncharts, pd4ml, solrj, etc. In actual development, different requirements called for different solutions. For example, fusioncharts for visualization charts, pd4ml for PDF generation (like HTML to PDF), solrj as the Java interface package for the search tool Solr, etc. These technologies aren’t directly related, but they can all be called “wheels” (ready-made solutions). Through continuous development and using these, I learned to leverage mature solutions and use official APIs. In interesting terms: use existing wheels, do your part well, and solve problems with available tools.
• Java The project framework was built by my leader Li*. As I kept developing, I increasingly appreciated how well the framework was built. I remember actively telling the CEO how good it was - concise, standardized code. My leader responded: “Yes, that’s what an architect does. He has rich experience, so no matter how you develop, you can’t escape his framework.” I agreed and also realized the importance of continuously absorbing others’ technology, experience, even coding style.

I’ve always believed that one should keep learning constantly, absorbing characteristics from anyone better than you. This process should be like a sponge - throw it in water and it quickly absorbs moisture.

I remember when the leader needed to build several internal systems, he used A as the framework. They were basically the same with minor modifications. Since I was most familiar with this system, I used SVN branching to create 4 similar systems.

2015

Early Year

In early 2015, due to business needs, the company needed to develop internal systems. Since I personally enjoy challenges and work, I was assigned the most important part - the task management module. The real difficulty wasn’t in development but in architecture. I remember drawing flowcharts repeatedly, discarding and redrawing them using Microsoft Visio. I communicated with my leader multiple times during this period - after all, he had rich experience. Eventually, I conquered this toughest challenge.

• Flowcharts This project’s biggest impact on me was flowcharts, i.e., design. Because design affects the entire development process, post-launch maintenance, and future uncertain feature additions - essentially scalability.
• Communication Li* was the most excellent person in our company, and I think the smartest too (boss, if you see this, don’t be angry - I’m limiting “smart” to coding and architecture here, hehe). When I couldn’t figure something out or wasn’t sure about my design, I often talked with him. I realized that thorough consideration and scientific system design reduce future costs. Learning from others’ experience is crucial. Indeed, through communication, I discovered deficiencies in my thinking. With his guidance, I improved my design shortcomings. Development went very smoothly, and even today, I think that design was good.

Mid-Year

In mid-2015, I started participating in a website project B, still using the Grails framework. This project was more complex than 2014’s A. In actual development, there were many small issues because the previous system was internal and didn’t have large-scale user feedback, while this one served a substantial user base, revealing many detailed problems. This project’s development gave me several gains:

• Collaboration Previous projects had collaboration too, but this project belonged to another department. Although the company wasn’t large, there were organizational structures. This project’s development gave me deep understanding of colleagues from unfamiliar departments and insight into their work.

• Refactoring During development, I worked on a module called Alert, originally done by a colleague Zhang*. When I looked at it, I found it was overly complex for a simple function. But directly overturning someone else’s work wasn’t feasible, so optimization and refactoring were needed.

  So I organized the original logic, drew flowcharts for what the function should actually do, and adjusted the logic to achieve the same functionality. I remember after my refactoring, code volume reduced by 40%. Due to time constraints, I didn’t complete the full refactoring, but I was happy with the results - I truly simplified complexity and improved maintainability.

  I remember a theory from a Java book by Daniel and his father: the larger the code volume, the higher the maintenance cost. I completely agree.

Other

In the second half of 2015, besides B’s development, I also participated in maintenance for some government client projects, including PHP project maintenance, APP maintenance, and some platform assistance. Overall, these projects involved less technical support and more client communication and coordination. This experience gave me several insights:

• Clients as Friends Through continuous client communication, I truly realized that relationships significantly impact efficiency and results. Usually we technicians just follow requirements from above, but there are problems in this process. Physics talks about energy loss - even when a client makes a product request to the company, there’s loss when it’s communicated down through layers. Because I constantly communicated with clients and built good relationships, clients often gave flexibility based on actual circumstances.

I remember once our service crashed abnormally. For security reasons, there was no remote desktop access, meaning I had to go on-site. The round trip would take over 2 hours, but actually being there would only take 1 minute to restart the service. The client told me: “How about you remotely operate my computer as a jump server to connect to the target server?” I was thrilled and thanked them profusely. This saved over 2 hours - significant cost savings for both the company and myself.

Emergency Response

September 2015 was the 70th Anniversary of the Anti-Japanese War Victory - unforgettable for the world, our country, and also unforgettable and tough for me. On the eve of the anniversary, I spent the night in the client’s server room. The reason was security concerns - to prevent server hacking and negative impacts. Multiple levels required guaranteed security, with immediate response if problems occurred. Considering that staying home might lead to inadequate response time, I volunteered to guard overnight. Actually, only two companies ended up doing overnight duty - the other was the client’s primary service provider. The night passed without incident.

Thinking about service providers - so many, yet only two were willing to do night duty. I still built a good image for our company - at least we were one of those two. I remember a joke by Zhou Libo: “Even Lei Feng wrote diaries about his good deeds, afraid people wouldn’t know.”

At such critical moments, ensuring full protection is the service provider’s responsibility - no excuses.

2016

Early Year

Early in the year, company business wasn’t tight, giving me ample time to learn. A long-term client needed a content APP, and the company gave me this opportunity to develop. I remember spending 2-3 months on APP development, covering both frontend and backend. Frontend used ionic1, backend used phpcms2008. I faced various obstacles - my thinking wasn’t adjusted from previous Java development, plus PHP was challenging. It was tough - constantly reading materials, researching. Finally, the APP launched around April.

This app build was genuinely tough. I remember the boss urging me repeatedly about why it still wasn’t done—he figured an experienced person could finish both frontend and backend in about a month. I kept answering that I wanted to do it properly and be satisfied with the result first.

Technically, this project wasn’t difficult, but for me, it was comprehensive training - thorough. Key points:

• Frequent client communication for requirement analysis and understanding
• PS work for APP mockups, icons, and other UI tasks
• PHPCMS deployment and content management system setup, learning PHP, customized development based on CMS
• Creating API interfaces following REST standards
• APP development with ionic1+angularjs
• Message push implementation with JPUSH
• APP version control
• Android packaging, certificate signing
• iOS packaging and review
• CMS platform production environment deployment

And many other scattered issues. When it finally launched, that moment when I could search for my own developed APP in the store - even though the author showed the company name, not mine - I was joyful because I knew I developed it.

The APP had a registration function. I wrote a feature where new user registrations would email the editors, plus me as technical support. Even now, whenever I receive registration emails, I’m happy because I know there are new users.

This APP hasn’t been updated since 2016 development. I regret this because it was like my own child, but the client’s focus wasn’t there, so no funding to maintain it. However, its significance to me is great because it gave me my first experience of full project ownership. I knew I would soon appreciate this experience, and I believe my dedication will be rewarded.

Main Theme

After completing the 3-month APP development, the company assigned me to a project team for a major project development called C.

Actually, I didn’t expect this project development to be so rugged, so painful, yet so fulfilling and exciting. It could be said to have trained me to the maximum extent and depth.

About technology selection, we struggled for a long time. SpringMVC is a very stable and mature framework, which should be the most efficient and time-saving. Plus, our team was most familiar with Java. But technology keeps advancing, and considering architectural drawbacks from previous projects and the need to update the company’s tech stack, we ultimately chose Angular2 as our frontend framework, expressJS as backend framework, and jersey as service framework. Abstractly, it would be 3 layers. Actually, this architecture is similar to Alibaba’s architecture. Angular2+expressJS can be collectively called “big frontend” - a term I really like. After technology selection was settled, we started design and development, but it wasn’t actually smooth. Main reasons were two points:

1. The ng+expressJS platform architecture requires frontend development expertise, which our company lacked in terms of strong talent pool
2. ng2 itself was very new - when the project started, ng2 had just released RC version According to company staffing arrangements, this big frontend part would be done by me and a colleague. ng2 frontend development itself had 3 language choices:
   • TypeScript
   • JavaScript
   • Dart

But the official recommendation was TypeScript. This was my first time hearing about this language. What should we choose? I was conflicted. However, since official recommendation was TypeScript, I thought we should consider it first. I checked the language syntax - it’s actually object-oriented. If you’ve learned JAVA, it’s not that difficult. Both my colleague and I are people who aren’t afraid of difficulties and have open learning attitudes, so we finally decided on it. So development work began. The other colleague, being more skilled at UI work, handled the page display part. I, with relatively solid JAVA foundation and accumulated implementation experience, plus being very familiar with the business, handled the main framework, logic, and functionality.

Actually, the development difficulties were worse than imagined. ng2 itself was still RC, documentation wasn’t in Chinese. Fortunately, English is one of my strengths, so I wasn’t afraid. But the massive reading was still a significant challenge. I spent almost every day dealing with English documentation. Plus, many detailed technical points - since the company lacked talent in this area, I had to find answers myself.

Google and GitHub became my most frequently visited sites during this stretch.

During this time, I joined a QQ group with some real experts. I always had piles of questions, and several people consistently answered enthusiastically, giving me significant help. One called K had really high frontend skills. Through this, I constantly received both criticism and guidance from him, continuously improving. He pushed me to do many things I lacked courage for, like ng2 components - initially I didn’t know how to design them well, he said “look at material source code.” I knew he was right because material is the official ng component library - theoretically its design must be worth referencing. But reading source code was still challenging for me. Sometimes it’s just that little bit of courage missing.

Finally, I broke through my psychological barriers and started reading source code. Over time, it didn’t seem so difficult anymore, and I learned many practical techniques from these excellent codes.

During continuous development, time kept moving forward, but we encountered several fatal problems that made me somewhat discouraged - one was compatibility, the other was performance.

• ng2’s official compatibility list was IE10+. To support IE9, you needed to add compatibility packages, but in practice, even IE11 had problems. I became less confident - if IE11 wasn’t supported, the project would directly fail
• The web built with ng2, after frontend packaging, had very large volume, making first-screen loading extremely slow. This would definitely be unacceptable for production-level applications.

The project faced the risk of being killed. I remember that night the company held a meeting to discuss what to do. Facing everyone’s technical doubts about the project, I really had nothing to say and felt guilty - was I too aggressive? Also, if the project failed, it would be the company’s failure and mine too, since for such relatively large projects, I was already in the architect role. Later we discussed a solution: if compatibility really didn’t work, we’d prompt users with older browsers to use the old site.

Once that was done, browser issues at least weren’t so severe. Next was performance. ng2 provided lazy loading and AOT compilation solutions, but since the technology was new, actually implementing them wasn’t smooth - various errors, various problems. I remember one day when the project faced reporting - if performance couldn’t be solved, it would directly be declared a failure. I really wasn’t willing to accept this. At that time, it was really just a little bit left for me. I took pen and paper to analyze.

I remember late at night, it was really solved. After AOT succeeded, the entire volume reduced by half. Later adding lazy loading made performance much better. Finally alive! I remember being so excited I couldn’t sleep all night, and immediately notified the company leaders.

Later gzip pre-compression, CDN, TSC upgrades, etc. - detailed points. This project constantly faced risks and challenges. I was constantly on the path of discovering problems and solving them. Over time, I actually became an active member of the angular2 expert group, becoming half an expert myself. This group had 1500 people, and reaching that level with ng2 should put me in the top few. Through frequent questioning and communication, several active members became friends, and we separately established another group called angular2 source code analysis group.

This project was delayed repeatedly until the end of 2016. Of course by then I already had confidence, knowing launch was certain. Everyone was making final development efforts.

But before this, there was actually a time I planned to give up. I remember texting the CEO saying I’d really tried my best, seemed impossible to achieve. But the leader comforted me, saying if you try your best and fail, that’s fine, but giving up is wrong. I reflected on what the leader said - yes, I’d persisted for a year, so I rallied and continued.

Facts proved that persistence increases chances of success, while abandonment guarantees failure.

Side Story

Throughout 2016, almost all time was spent exploring and developing the C project, but I also did a small project in between. If B was the main theme of 2015, then this small project was a side story.

I remember it was a Wednesday. The leader directly called me over and said a client called asking for such a job - make a display APP, needed quickly. The leader asked how long it would take. I said if we hurry, we could do it in a week. The leader said no - if we start now, can it be done this week? Hearing it needed to be done this week surprised me, but after thinking, I responsibly said yes, we can work overtime to complete it. I could answer with such confidence because of two points:

1. I was young, physically I could handle it
2. The previous 3 months of comprehensive training had laid the foundation. Simple display APP development didn’t need to start from scratch - there was some foundation. Plus this development didn’t need backend work - essentially it could be understood as data visualization display

Based on these two points, I thought it was achievable, so I agreed with the leader. I didn’t want to refuse the leader because I wanted to work - it gave me great satisfaction. The leader gave me the client contact’s number, saying their backend part and APP requirements would be provided quickly. Just do it.

So on Wednesday afternoon, I quickly set up the APP framework, then began continuous communication with the client and continuous development. I remember initially working at the company, but due to client data sensitivity and communication inconvenience, I eventually went directly to work at the client’s site. Friday, Saturday, Sunday - all three days I slept very late. But seeing partners also working hard, I didn’t feel tired. Simultaneously, I realized when we’re resting, we rarely think about others constantly working hard. Sooner or later, how could we not be surpassed by others? So around 11 PM Sunday, I finally delivered a version the client was satisfied with, then late at night, everyone took taxis back to sleep.

Later this project still had multiple small fixes and modifications, but overall it stabilized. Later the leader told me the client called expressing satisfaction with my work. I was happy to hear this, feeling somewhat proud.

Actually, the smoothness behind this 3.5-day challenge was mainly because of previous similar APPs having ample time for practice, so there were no major issues with existing technology. This gave me the deepest realization: doing things you’re already experienced with and good at brings surprisingly high efficiency.

No Annual Leave

In 2016, I didn’t take a single day of annual leave, nor had time to take it. To be precise, many weekends weren’t complete - all used for C’s development. But now thinking about it, this experience was actually quite good - cultivation. This training is unforgettable, and even in the future, such opportunities aren’t common.

2017

APP

The 2016 C project was huge both technically and in task volume, so it was constantly in development. I remember on January 16th, suddenly the leader called me over saying to go with him to a client to discuss a small project, so I went with the leader.

Turns out this client came to us because that previous APP was done well - client A recommended us. Seems this is word-of-mouth reputation.

At the client’s side, this was my first time going with the leader to discuss a project face-to-face with a client. Occasionally the client would ask about technical solutions and some details. Due to previous extensive development experience, I was quite comfortable in communication. Finally it was confirmed doable, but being an emergency project, time was still tight. For me, the additional challenge was that B project also needed continuation - this was essentially extra. Facing this project I was already very skilled at, I really didn't want to give up. On the way back I told the leader the project was doable, half laughing at myself as I admitted that after a year of grinding away on project B I had finally started to relax—I’d even booked a ticket home for the 17th (the next day). Clearly I wouldn’t be going anywhere; the coming week had to be dedicated to finishing this app.

What made this APP different from previous ones was that the backend also needed to be done by us. Of course, since this backend only provided APP data interface services, the difficulty wasn’t too great. With previous APP development experience, plus B project’s large project architecture and dev experience, Facing this, I actually had absolute confidence internally.

The previous app used Ionic 1, and a quick look at the official site showed that Ionic 2 (built on Angular 2) was already available. Having built project B from scratch and trained heavily in between, I felt confident switching to Ionic 2. Even though I hadn’t used it before, my Ionic 1 and Angular experience meant it wouldn’t be a hurdle. Since the app still needed APIs, I stuck with Express.js for the backend just like project B.

So on the afternoon of the 17th, I quickly did simultaneous frontend-backend development. After a week, I preliminarily completed development and delivered to the client, who expressed great satisfaction with the progress. Then New Year arrived, finally could rest a few days.

Either/Or Choice?

Pre-New Year app work wrapped up smoothly, but none of us expected the torrent of development waiting right after the holiday. Requirements kept shifting—large and small changes arriving at a rapid pace—while the earlier major project C was still in crunch mode because it hadn’t launched yet. Our timelines collided everywhere. During this period, a very serious incident occurred - at least I personally considered it serious. During development I asked someone to help with part of the app. The heavy lifting was already done—I mainly wanted them to gain experience. After a week there was still no progress, and the client even remarked it looked worse than before, pushing the timeline back. I felt guilty; although I knew the helper was out of their depth, it was ultimately my responsibility. I carved out every spare minute to push the app forward while still handling project C. Thankfully my lead and I had already trained a few strong teammates on C, so I could concentrate on the thornier technical issues.

Even with three heads and six arms, I was stretched too thin and already exhausted. Helpless, I called the CEO and laid out the difficulties. He told me to decide: project C was paramount, and if the app couldn’t be delivered we should drop it and accept the breach. After hanging up I decided that quitting wasn’t an option. I’d find a way to deliver both. Letting the project fail would harm my reputation, the company, and the client—it simply wasn’t acceptable.

So I gritted my teeth and persisted. By end of March, the APP was basically finished, finally winning this battle. Although there were some regrets - inadequate service to the client, existing deficiencies. For this I still feel apologetic.

C Project+

Besides this APP in 2017, the most significant was actually the C project and the extended C-GROUP team. Behind the C project was a series of project dev work. The C project, through struggles, finally launched on April Fool's Day. I joked myself - fool or not fool. On launch day, the team seemed to feel nothing, but I was deeply moved because I knew I had once given up on this project, this project had experienced life and death struggles like me. Thought I could rest a few days, but it seems greater power brings greater responsibility. Immediately, the company requested a mobile version as soon as possible. At this point, my framework needed adjustment because we couldn’t just copy it directly - that would create major maintenance problems in the future. Plus, the web version wasn’t comprehensive enough, so we needed to consider how to improve. Ultimately, I decided to implement a certain degree of reuse. Quickly, within 1-2 months, the mobile version was launched.

The client expressed satisfaction with our mobile version launch progress

But the battle wasn’t over yet. The derivative projects of C project needed to be completed step by step according to plan - 4 more websites by the end of August. These websites could all be considered similar types, but with differences within the similarities. So for me, I needed to consider refining the project code and improving the project structure.

How to achieve reuse? After research and analysis, I decided to use git-submodule to organize the code. This means the project itself could use another project as a third-party library. After some practice, this proved to be a very suitable choice, so development continued this way. As of now, everything is progressing according to the established plan, and the client is satisfied with our development.

Looking back at all this, I really have many feelings. The people in the team followed the established framework, and when they mentioned difficulties or problems, I tried my best to answer them. But what I really wanted to tell them was problem-solving methods - how to describe problems, how to find answers, and even how to find mentors.

Because compared to the difficulties I encountered before, these were actually nothing.

Summary

Unconsciously, I’ve written this several-thousand-word journal. This should be my longest blog post, after all it covers 3 years of experiences. Over these 3 years, I personally believe what these years brought me wasn’t just knowledge of node, angular, ionic, java, php, etc., but rather these:

• Open-minded thinking
• How to describe problems
• How to find answers
• How to find mentors
• Thinking before acting

These insights, these understandings, these methods have formed imprints, deeply embedded in my heart, enabling me to continuously improve. As one of my friends said, programming is more about internal skills - thinking is the most important. Once you master thinking and methods, learning anything and doing anything becomes more efficient.

For these understandings, these insights, these improvements, I want to thank these people:

Myself

First, I thank myself. Over these 3 years, if compared to those who just work normal hours and treat it as a job to earn money for family, I probably put in 5 years worth of effort in 3 years. Because I truly devoted a huge amount of time and consumed countless brain cells. Even for simple problems, I was willing to think about the best implementation methods, and I also wanted to explore why things should be done that way. Because I always demanded of myself to do more, think more, and do things well. Among these, 2016 was the most exhausting year of the 3 - so exhausting that sometimes I really couldn’t go to work and had to reluctantly take a day off. But this experience was truly unforgettable and shaped who I am today.

CEO

CEO, the company’s top leader. I clearly understand that even if you’re willing to work, you need a stage. Gold doesn’t necessarily shine, and the CEO gave me this stage. When you diligently accumulate knowledge and skills, once opportunity comes, you truly take off.

The APP project gave me a comprehensive opportunity to showcase and unleash my abilities and creativity. In that moment, I felt I could complete a project with high quality and efficiency.

The 2016 C project enabled me to have ample time to learn, design, and develop.

Beijing is also a place with many opportunities. There are many conferences like GDD, Microsoft Build, Big Data conferences, etc. All of these were supported by the CEO, giving me opportunities to attend. So many idea collisions enabled me to avoid being closed-minded.

My Leader

Leader Li*, my first web development project at the company used the framework he built. I sincerely admire it - it’s truly high quality. We all need to acknowledge that a good leader is important, just like a good teacher. Also, Li’s thinking is very open, actively absorbing external knowledge. He is my leader, but actually also my friend. Even when I complain to him sometimes, he patiently guides me on what’s right and wrong. We worked together to overcome many technical problems and also worked together to change the company, such as promoting gitlab implementation, etc.

Those Online Friends

For technical work, you first need to use technology. Over these 3 years, I joined no less than 50 QQ groups and countless online friends. Because I was too active, I even became an administrator in several groups, and was mistakenly regarded as a “big shot” by some unaware friends, etc. On GitHub, for some open projects like angular, I also became a contributor (just asking questions and communicating, haven’t done PRs yet, hehe).

Online friends all help without expecting anything in return. This is the infectious power and strength of open source and openness. So now I also write more technical blog posts, am more active in communities, thus actively helping others. Helping each other this way promotes the development of the entire industry.

Conclusion

Long articles always have an end. This article is about a programmer constantly struggling and stumbling, walking a path, and narrating the process of walking that path. The road ahead is long and winding - the path of programming has no end because technology changes rapidly, the entire industry is fiercely competitive. If you don’t advance, you fall behind. The first 3 years have passed, continue working hard, continue fighting. MARK.