Year 5

Zero. Looking Back

After writing blogs for so many years, I finally let go.

Along with it, I also let go of the weekly plans I had been recording since February 7, 2014, which ran until week 356 and then abruptly stopped.

I gave up my stubborn persistence all along, and used the time freed up to try to think about things I had never noticed before, complex yet interesting.

Learning Gains

It's been barren for over half a year, so only 22 blog posts:

Cross-platform technology: Change and Unchanged x1, Three Major Dilemmas x1, Dynamic Evolution x1
React: New Features x2
SSR: Significance x3, Principles x3, Frameworks x3
Frontend Engineering: IDE x1, Low-code x2, Frontend Engineering System x2, Efficiency Value x2
Thoughts: Grasp x1

It took 2 years of support work to truly understand cross-platform technology. React didn't change much this year either. SSR gained quite a few skill points but didn't land and bloom. I defined the frontend engineering system and tried to quantify its efficiency value.

Less research on technical details, more thinking and summarizing, and the field of frontend engineering became clearer. The knowledge boundary doesn't show much change, but through practice I gained more understanding of some knowledge learned from books, such as architecture design, cache warming, gray release, emergency rollback, Serverless, Cloud IDE...

Goal Completion

Influence: WeChat Official Account ~~3000 followers~~ (only 2300), internal speeches ~~10+ times~~ (only 3 times)
Frontend Engineering: ~~Since I'm still doing this, do it beyond expectations~~ (ran away, first need expectations, then possible to exceed expectations)
Learn PM way of doing things: ~~Finish reading "Everyone is a Product Manager"~~ (read halfway), and apply to 3 (0) actual scenarios
Go out: Maintain 14 links with the inner circle?
Self-reflection: ~~Monthly~~ review and summarize once (continued written summaries for 3 months, afterwards reflected on some things)
Observation: Build my own "view on people and affairs"?

With the original intention of doing it well if doing it at all, I set a goal of 3000 followers (about double or more), but later discovered that "gaining followers" relies more on operational methods than content quality, so this indicator is not that important. Internal influence has improved, but not through technical operations like speeches, and there's still much room for improvement.

Frontend engineering and learning PM way of doing things, these two goals became generalized in actual execution. R&D models, frontend architecture, production relations, etc. were all incorporated into the frontend engineering category. And learning PM way of doing things, abstracted one more layer, is learning how people do things, learning from those who have done it, learning from those who do it well:

First rigidify, then optimize, then solidify.

And in this year, I learned from at least 3 people's ways of doing things. Although I only learned the surface, it has already shown some results.

The habit of "going out" has been formed, and on a quiet night on a train, my own "view on people and affairs" sprouted. The frequency and depth of self-reflection are not enough, but at least I can realize some problems afterwards.

Growth Experience

20 mood records:

People problems: Perspective-taking x1, Complexity x1, Those involved are confused x1
Words starting with borrow: Borrow false to cultivate true x1, Borrow momentum x1, Borrow things to cultivate people x1
Opportunities: Distribution by complaint x1, Problems and opportunities x1, Taking sides and grabbing spotlight x1
Growth: Learning and having learned x1, Output thinking and output knowledge x1, Spring model x1, Fast growth x1
Communication: Exchange information x1, Speak carefully x1, Bottom-up and top-down x1
Methods: Grasp the root x1, Mountain climbing model x1, User needs and product needs x1, Cultivate user mentality x1

After experiencing complex things, I started to pay more attention to some non-technical factors.

I. Insights

Definition of Architect

I once explored the responsibilities of architects, with no result. Until I found this definition:

Solving complex problems should be defined as a typical role of an architect.

(Excerpted from My Understanding of Technical Architecture and Thoughts on the Role of Architects)

That is to say, an architect is someone who can solve complex problems. This answer resolved many of my long-standing confusions:

Which work belongs to the architecture (design) category?
What capabilities should an architect possess?
If technical ability is not at the top level, can one be considered an architect?
What about solution architects?

Under this definition, complex problems all belong to the architecture category. Whether physical structure, logical design, or even personnel arrangement, the process of specifically making plans to solve complex problems is architecture design.

The purpose is to solve problems, so different problems require different capabilities from architects. But generally speaking, one needs both hard skills to accurately define, analyze problems, and formulate plans (such as logical thinking, technical ability), and soft skills to reach consensus on plans and implement them (including influence, coordination ability). Therefore, some people whose technical ability is not at the top level but can still solve complex problems are undoubtedly architects.

Solution architect is a position that can provide solutions based on the actual business scenarios of (client enterprises), such as solving complex problems like digital operations, cloud deployment, cloud R&D, etc.

So, it's not wrong for technical people to set architect as a career goal, but becoming an architect is not just a technical goal. And complex architecture design in business scenarios is a challenging field that fascinates people.

Unity of Knowledge and Action

Learning (reserving knowledge) and Having Learned (having learned knowledge means being able to solve practical problems, which is also the standard of having learned)

Learning and having learned are two different things. Learning is an input process, like charging, while having learned depends more on output, making light bulbs glow, making high-speed trains speed up (instead of directly discharging).

Knowing so much knowledge, what's the use?

Input every year, but no output seen. From an external perspective, it's useless. Although I feel I've internalized a lot and am full of power, I haven't lit up any bulbs or driven any high-speed trains, so externally there's no way to judge the energy of this battery. So, learning is subjective from one's own perspective, having learned is objective from others' perspective.

I learned the backend knowledge system, learned and even played with Serverless, but in real business scenarios with real weapons, I was at a loss:

What's learned from books is always shallow; to truly understand, one must practice personally.

(Seemingly the older I get, the more I can deeply understand the simple truths I rigidly learned in youth.)

Unity of knowledge and action also speaks to this principle. Use action to verify knowledge, generate new knowledge in the process, then use action to verify again... Only through repeated cycles can one continuously improve.

No Time to Think is Most Terrifying

As a result, the more diligent and busy they are, the more they contract their skills into a single track.

Typically, I persisted in writing blogs for up to 7 years, a perfect case of "tactical diligence". Many weekends and days in those 7 years were spent single-mindedly researching technology, lighting up many skill trees, but also missing many opportunities, even losing a large part of life.

Around the beginning of last year, I started to realize the disadvantages brought by the habit of writing blogs:

A research-oriented personality is not a bad thing, but eyes tend to stay on underlying principles, hindering thinking about business scenarios, which is a main reason for slow growth. Therefore, must restrain the abnormal desire to drill down, and shift the gaze upward.

Weekend time was almost all spent on writing blogs. The logic of output forcing input is not wrong. I input a lot of technical knowledge from this diligence and busyness. Over time, my vision was also limited to technical aspects. Whether abstract/concrete, frontend/backend/cross-platform, complex/simple... I was trapped in a strange circle. All I could see was technology, unable to jump out.

Long-term state of extreme busyness with no time for anything else, seemingly fully committed, is actually a very bad state. The diligence of action completely covers the laziness of thought. Like a machine, repeatedly doing the same thing without thinking more, and no time to think?

P.S. Actually, I thought about stopping last year, but finally decided to write for one more year. Wanted to maintain half pure technical investment in the first decade. Call it stubbornness.

Do Things with an Entrepreneurial Mindset

This point was realized from my old leader half a year ago, a god-like person who could make all the吹牛 (boasts) come true.

P.S. Coincidentally, two days ago, I saw A Xiang's sharing "Work and Grow with an Entrepreneurial Mindset", secretly sighing that great minds think alike. The Wallfacer Plan is not necessarily reliable.

Always able to make things that everyone thinks impossible happen. I initially thought it relied on gambler's courage, daring to boast and do with only 30% confidence. Everyone lost on the courage to go all in. Later I found it's not so. Going all in after boasting is as important as the calculation and courage before decision-making. Not just going all in, not just doing one's best and leaving the rest to fate, but at least going forward unflinchingly with "by any means necessary".

Treating work as entrepreneurship. If every matter concerns life and death, one can better understand this "by any means necessary", and try every possible way to get things done. This is the entrepreneurial mindset.

Specifically, entrepreneurship requires doing three things well: finding people, finding money, finding direction. Finding the right people, and the matter is half done. I used to take this lightly, until I truly experienced months of stalemate, then had to realize the importance of finding the right people. Finding money is finding resources, requiring architects to have organizational influence, able to influence all relevant parties, and promoting architecture implementation is a kind of "finding money" ability. Finding direction tests judgment more, the ability to see more, see deeper, see higher, see faster.

Like entrepreneurship, the actual situation is resources are always insufficient, timing is always inappropriate, direction is always unclear, yet things must be done. Racking brains, trying every possible way, technical, non-technical, conventional, unconventional... Using all possible means is the only way to possibly raise confidence from 30% to 60%, to 80%, before the final natural success.

Stay Humble

Weakness and ignorance are not barriers to survival; arrogance is.

Long-term focus on one field, such as frontend engineering, cross-platform, low-code, IDE, easily makes one "arrogant":

Theia doesn't necessarily beat VSCode's web version.

Subjectively filtered information weaves a cocoon of self-satisfaction. Raising shields, looking at everything with disdain. Over time, forming one's own "field", being the authority in the field, the god controlling everything in the field.

Only by putting away the field can one see the real world. Stay humble, and there's a chance to see the shining points in others:

Last time I looked at Theia, it's developing quite fast haha.

II. Goals

Year 6

Architect: Build my own business model, possess business insight ability.
Frontend Engineering: Put away the field, settle down.
Learn from People: Learn to do business, first rigidify, then optimize.
Go Out: Make 1 new friend.
Self-reflection: Develop self-reflection habit, regardless of size, subconsciously reflect afterwards.

Architect

If the first 5 years were wholeheartedly on the technical expert path, then the goal for the next 5 years is to become an architect.

Several reasons:

Complex architecture design in business scenarios fascinates me
Have architects around as role models, can seek help and guidance
Architect is clearly defined, and the space is large enough (hard to reach the top in the next 5-20 years)

Compared to the expert path, the architect path has more tension, of course, also more difficult.

Practice in Affairs, Gain from Difficulties

Thinking is one thing, doing is another.

Only by truly doing, in the process of doing, or even after doing, does one know whether the thinking was right, and by how much.

Once the direction is thought through, or even just the method of finding direction is thought through, one should immediately start doing. Shooting while aiming is the norm, there won't be detailed design for everything, execution stroke by stroke.

Thinking, all are problems; Doing, there will be answers.

III. Plan

Main Thread

Architect

Side Thread

Frontend Engineering

Daily

Learn from People
Go Out
Self-reflection