I started an internship in an outsourcing company in March last year. I resigned in June and officially graduated in July. Then I entered the current startup company in mid-August. The young and immature us have quietly changed under the baptism of a year, at least the weight has almost exceeded the standard. A code farm worker who is a programmer, but there is such a literary and showy young man in his heart. He can't help but want to write something to pay homage to the past year, what happened, and about growth, about Feelings, about the current view of their own positioning.
Entering a startup is really exhausting. I am very fortunate to go to a startup company with a relatively strong technical atmosphere. Although I work overtime all day long - I inexplicably think of a joke. It is said that a programmer graduated one year but wrote three years of work experience, and two years came from overtime... We are 996's The work system, and secondly, seven or eight of our back-end technicians publish a version every week, so 996 does not seem to be very appropriate. In the taxi, looking at the bright moon in the sky through the glass window, it does not seem to be very bright. I remember that for a while, I entered a state of crazy overtime work, and the version was incrementally issued almost every day. During this seemingly dark and gloomy time, I panicked, apprehensive, thought about escaping overtime, thought about resigning, in short, I just thought that it would be great if I could do everything possible to avoid overtime? Now, when I look back and think about the past, I feel that I was not so tired at the time, because I seem to be making progress every day. I am afraid that feeling is a bit strange and exciting. Of course, in addition, I must be grateful to my lover, who gave me meticulous care and encouragement. However, no matter how exciting it is, I won't go back to that kind of life...
I don’t know if other programmers have a mentality: I would rather spend my time studying various middleware, various frameworks, and even various framework source codes, rather than spending more time on business code.
I often have this strong feeling that as a technical person, I am eager to study framework research technology, business code is repeatedly if else... How can technology progress? What is the salary increase? This kind of extreme and persistent idea directly led me to resign. The reason is roughly that the new framework has arrived, and the discussions on the Internet are in full swing, with different opinions, and I just got off work at 12 o'clock and copied the last line of business code today. Forums, QQ technology group analysis of all kinds of big cows, online blogs are emerging one after another, others are making progress and I am still writing these bird stuff, what the hell! ! ! About a month later, someone started recruiting in the group, proficient in XXX new technologies and new frameworks, with a monthly salary of XXK and an address of XXX. Seeing this kind of recruitment in the group, I panicked, my God, the outside world has started to use it, and I am in a corner, am I doing technology? Struggling, but you never offered to leave until... friends around you started to discuss these issues that you didn't understand very well, or saw his QQ avatar in a group posting a big bull-like statement Instructive speech, discussing the past and present of new technologies and new frameworks. When I was on the way back, my heart was churning. Did I fall behind so much among my classmates? The resignation application was sent to the personnel at ten o'clock tomorrow morning...
In the end, under the persuasion of the bosses, I still did not leave the job. There are many reasons, but the main reason is that I have no money, and I can't live in Shenzhen without a job...
Today, with the endless emergence of new technologies and new frameworks, the attitude is more humble and awe-inspiring. Before, I was planning to explore the source code of MyBatis in a series of articles. Although there are many such series of articles on the Internet, it is not my own after all. It was clear to me, so I started to write several articles, but they were later deleted by me. The reason was that I didn't have the ability to really output something that I've thought about, that can stand up to exploration and test. Really insightful, if there is an error in the writing, and it happens to be seen by others, isn't it misleading the children? Second, there seems to be another unexpected "beauty" when looking at technology from a product perspective.
During my stay in the startup company, it seems that it is even more difficult to return to the business. At least if I go to take over a new framework, I will bring the full document and run a demo. I can always follow up with reference to the document to solve the technical problem. question. But business thinking is the key to testing growth. When taking over a business function, do you think about what value this function brings to our users? How much value can it bring to us, how many users can be saved, how much competitiveness can it improve, and what role does it play at the strategic level (thinking at the level of company strategy)? Is the demand returned by the market a pseudo demand? How do competing products achieve this business function (think from the perspective of the product)? How much time does it take to implement this business function? How to design this business function? How is this function designed at the code level? How many other functions does this function spill over (think in terms of actually implementing the function)? Wait...it really takes a lot of time to take over a business function and actually get into coding. When we look at this process carefully, we will find that the people who think ahead in this series will focus more and more differently. So, we are writing the code again, while the boss is writing the financing plan (these ideas are often given to me by the technical director, thanks to the director)
Growth seems to be the angle of looking at the problem and the idea of solving the problem.
Another point is to look at a framework from the perspective of a product. Originally, I saw that the best way to learn a framework was to open the official document and run the demo. Later, in the process of communicating with friends, I found that if I saw a framework from the perspective of a product The significance of the framework allows us to look at this issue from another perspective. For example, MyBatis, we have used Mybatis for so long and wrote so much code. Have you ever tortured yourself, why is there MyBatis? Maybe you can list a lot of things, but it is difficult for you to say it in an orderly manner, maybe you just think of one and it is one. It seems that you don't really use it, feel its good, accept its bad, and even invest in the development of MyBatis plug-ins for optimization... For example: why there is it --> what is bad about the specification --> competing products Contrast --> where is good, why is good, where is bad, why is not good --> …… --> When you finally return to the principle, you often already understand it very thoroughly. When you look at the source code, you are often inclined to understand its architecture design and code design. In fact, as a developer, I have always liked design patterns the most, and I love it. I always feel that its charm is too great. In actual development, my boss is a development veteran of nearly ten years, because I tend to be keen on these things, so I often ask him for advice. I often say how I should design here. In fact, I want to say what design pattern I want to use. Then I looked at Baidu to see how to do it. As a result, he looked at it after he came up and said that he drew an interface here and an abstract class there. ...no design patterns were said from start to finish, and I just did. Sometimes I would say whether it is better to use a design pattern here, but he said that it is enough to abstract an interface here, and what to do with so much complexity. I asked him again after three or two times, but he said, what design patterns, do those things yourself, don't waste my time. ... Later, I slowly gave up my obsession with following design patterns (although I did a lot of blogging, and the purpose of blogging was to take notes), and when I chatted with the boss, I asked about design patterns, and he said that many years ago He used C# and C++ to play demos, and he has long forgotten these things... He used his ten years of experience to actually save me a lot of detours. Although I am still very good, the solution he taught me is actually regression To the essential problem - abstract understanding. So on a design level if you also torture yourself: what's wrong with doing this? How to do it better to expand? Wait... Slowly, these questions seem to become why. (Although my product vision is narrow, I insist on reading more articles about product experience, learning more about the thinking of product managers, and hoping to have more opportunities to learn product concepts in the future)
After a brief review, I have a very clear position on my current position. There will always be a change in thinking after a review.
I am really grateful to the technical director and R&D manager for their profound guidance. Changed my way of thinking. It has changed the way I look at problems, the angle, the means of dealing with problems, and the posture. It has helped me grow a lot. After reading many articles, I think there is a sentence that actually makes sense: look at problems from the perspective of a product manager, Solve problems with the eyes of an architect.