After joining a unicorn company at the end of last year, I served as the Manager of chengdu Department of our business line. Different from the general ones, our Manager takes business as the dimension, instead of splitting it into front and back ends for separate management. A Magager needs to wrap a certain business. When you get your new job, you immediately face three problems:
- Do not have react experience before.
- Team building, because we’re a new team, and the team doesn’t know me, and I don’t know the team.
- Management of back-end teams.
To sum up, in the past six months, we have mainly addressed these three issues.
Technology migration issues
Our line of business is ReactCore, other parts like UI, state management, routing. It’s a set of internal implementations. And because there is a special technical architecture group to encapsulate, as the application layer we actually get started is not difficult, see how others write, write their own line.
But obviously writing is not enough. I need to understand how they are implemented and how their implementation differs from industry-wide solutions.
After nearly half a year of study and practice, I tried to interview for the React job outside. One of them didn’t work, but got an offer (but didn’t take it) for a nearly 50% increase in real estate. Based on this result, there should be no big holes in react knowledge.
So how did I learn React? The main way to do this is to choose a good blog/book and write a demo. I think there are two better series of articles:
1. Smart water mark 2. React Little book. The author @beard big haCopy the code
A better answer on Zhihu:
1. Lucas HC (Hou Ce) 2Copy the code
Some of the more important books:
React Router Redux Redux Redux Redux Redux Redux Redux Redux Redux Redux Redux ReduxCopy the code
Of course, I actually read more than the above, there are many very good, but relatively scattered blog, I did not sum up, a little regret. But overall, I think it’s worth watching because it’s systematic. On the foundation of systematization, see a bit blog post, check a leak to fill a vacancy. But you can’t just look at the pieces and not build the architecture. When the system is built, it is much easier to learn others, and it is more in-depth to see problems. For example, many people talk about the difference between React and Vue, but most of them talk about the difference in syntax, differ, learning curve and so on. There are very few articles that can be analyzed from the ground level like Lucas HC. www.zhihu.com/question/30…
We often say that the front end of things, front-end volume. I feel there is no need to increase the psychological hint and psychological burden on myself. It’s not that hard, it’s not that complicated.
Based on this, I asked the infrastructure team for code and learned about their design ideas for state management. Very useful. So, I think I’m doing a good job on this. Give me an 80. Of course React content has a lot to explore further, I will explore according to my own situation.
Team building
I think this is where I am not dealing well at present. I manage two teams, one of which works remotely. This has many inconveniences in management and work. I think it is mainly in the following aspects:
1. Cognitive consistency among team membersCopy the code
Our team is a new one, and the way we work and collaborate is different. Working together today, it’s important to have a shared goal and understanding. This aspect of construction, mainly through the team consultation training. Established a common understanding:
-
The goal of all actions is better deliveryCopy the code
Under this knowledge, we have established several principles
- Develop self-testing requirements
- Development responsibility for a Story extends to the full declarative cycle
- Block, collaborate, risk, etc. the overall flow of information
- All problems affecting delivery should be reviewed and PCA documents written.
Among these, I think cognitive consistency is more important. In this premise, to avoid the team into the state of internal friction.
2. Team process buildingCopy the code
There are some common processes within the company, such as sensitive processes such as online changes, which should be followed. However, each team also has its own workflow for details such as release rhythm, version management, branch management, bug/ CR management, etc.
3. Land quicklyCopy the code
Needless to say, it’s basically the same thing that Internet companies play with.
Team building this piece, the first half of the year did not do well. Especially in agile, I am not from SM, and the company does not have a full-time SM to serve the team. This leads to agility, which is basically formal agility. In fact, there is no way. SM is a vulnerable group and has no right to speak or decide. In this sense, IT is difficult for SM to protect the team well. In terms of process construction, the current implementation is not in place, which is the key work in the second half of the year. Overall, I’ll give this one a 50. A state is better than nothing.
Back-end management issues
I am the front end of the backend, but the back end is to do Linux development, Java is not very familiar with this set. Although I have some understanding of the concepts and principles of the back end. Microservices, CAP, service governance. But I can’t be a technical leader in general. In this case, it’s awkward.
The first is self-denial. The front end manages the back end with little confidence. Second, there is no direction. I don't know what to catch.Copy the code
This problem is finally overcome their psychological problems, big square back end said, I do not understand the back end is. Each team then assigned a TL as the technical lead on the back end. Let them do the back-end stuff. But I think, as a Manager, I can not be completely ignorant and can still participate in the discussion of their scheme. The division of the front and back ends is more the division of knowledge fields. The code has no front and back ends. Therefore, code design, database design, interface design and even CR are common.
The stability ofCopy the code
Since the front end is released and forgotten, stability issues are mostly back-end issues. First, clarify your stability goals with your boss, such as unavailability time, high P bugs, etc. Then, you learned about other team practices such as stability inventory, stability monitoring, emergency failure drills, etc. Finally, following the practice of other teams, we worked with our TL to develop a stability plan and invited reviews. This one turned out to be pretty good.
Partner performance issuesCopy the code
There are individual members of the team who are low driven. I can do the things I ordered, but my initiative is not very strong. To be honest, I personally think this is a personal problem. It is difficult for us to change a person’s driving force from outside. But the existence of such a person does have some bad driving effect on the team. They are still considering countermeasures.
For back-end management, this is a 70. It’s all about the right TL.
Personal related
Personally related, also did some things.
I'm working on an editorCopy the code
Based on Slate+Electron to achieve a rich text editor client. Read some of Slate’s source code. Progress is not good, there are some blocks on the mind map at the moment. The long-term plan is to see if we can migrate SLATE to Vue.
Broaden the front viewCopy the code
VUE and React WebPack scaffolds from 0 for the first time. More superficial learning using Lerna, Rollup. We learned a little about Svelte, and the use of Rust and Webassmbly.
Management perception: in management, I read some books and articles, which are all good, but I feel very little useful (distressed). The difficulty of management lies in people and communication. These are soft skills that feel hard to build up quickly.
Overall, it was a very empty first half because there wasn’t much output. In the second half of the year, I will focus more on editing and management.
The nuggets essay | 2020 years and I summarize the campaign is under way…