zhanglun

zhanglun

My Five-Year Plan

In 2011, when I just started my freshman year in college, I began learning front-end development. At that time, it was still called "graphic design," mainly involving image slicing and page writing. Now, it has been eight years since I started working in this industry, and I am considered quite experienced. I have witnessed the rise of the industry and encountered many peculiarities.

I believe that front-end development is a resource-oriented position. You go wherever the resources are needed. The entry barrier is low, and the ceiling is not high. I also believe that front-end development is actually a deviant position that has emerged from the subdivision of positions in software development.

After advocating for front-end and back-end separation, front-end development became stuck between design and backend, only doing a little bit of page design and API integration. Yes, I am talking about: front-end development involves designing pages and integrating APIs.

With the development of Node.js, front-end developers felt that they had the ability to compete with backend developers. They wanted to do everything that backend developers did, using Node.js to "raise the ceiling" for front-end development. This phenomenon is common in big companies like Alibaba. After all these years, I think it's a bit self-indulgent.

It cannot be denied that with the emergence of Node.js, front-end developers can do more. But does everyone need to do these things? Does everyone need to build a web framework? Most front-end developers still jump between different business tasks. Some of them don't even need to use Node.js for several years because their work simply doesn't require it. However, the industry's atmosphere has gradually changed, and front-end developers who only know how to write business logic are considered to lack technical skills and potential.

With the development of the Internet, there are more and more domains and audiences to cater to, and the requirements for software interfaces have become higher. UI development still involves page design and API integration, but in order to meet higher software requirements, it is necessary to build and maintain efficient, practical, and high-quality software using engineering methods. This is where the concept of front-end engineering comes in. Front-end developers believe that with the help of Node.js, they can do more, and their potential is higher. Similarly, the industry's atmosphere has intensified, and front-end developers who do not understand front-end engineering are considered to lack technical skills and potential.

Most front-end development work still involves writing pages and integrating APIs. Other peripheral tasks serve these two main tasks, making the page design faster and better, and the API integration faster and more stable. However, these tasks are further subdivided within the front-end development field. A common example is the establishment of a "front-end infrastructure" team in many companies, with some people focusing on business tasks and others working on technical projects to support the work of the business team. Then some strange phenomena arise:

  1. Front-end developers who work on infrastructure support often come up with design solutions that are difficult to implement in practice, but their performance is not too bad. On the other hand, front-end developers who work on business tasks and help the company make money are considered to lack technical skills, have high replaceability, and cannot achieve high performance based solely on their business tasks.
  2. Front-end developers working on infrastructure support are required to "apply technology to drive business growth" from a technical perspective, while front-end developers working on business tasks need to demonstrate their technical abilities through some activities.
  3. There is even a hierarchy of disdain, where front-end developers working on infrastructure support are considered more advanced than those working on business tasks, and no one wants to work on business tasks.

It's really strange. One of the evaluation criteria now is that doing a good job in your own role is far from enough. So, what is the significance of role subdivision? Is the front-end development position somewhat redundant in the software development process?

I never wanted to limit myself to the front-end development position. Every time I introduce myself, I hope to be called a "software development engineer." When I was at Didi, there was no such title as "xxx front-end," and I really liked that. I have always believed and insisted that an excellent engineer lies in their problem-solving abilities and their ability to learn new things. After joining a new company, I have more time to do what I want to do. In my spare time, I started exploring various technical and non-technical matters and developed two desktop applications, Lettura and Pavo. From conceptualizing the product to its release, it requires the abilities of a complete development team. During this process, I learned a lot and gained a lot, which gave me greater confidence in independently developing a product.

After immersing myself in Product Hunt and Twitter for a while and referring to the experiences and thoughts of some independent developers in the community, I made a decision: to spend five years building a paid subscription software. Honestly, I have never done these things before, from the initial product research to the later operation and promotion. But I still want to take this step bravely for several reasons:

  1. I have a habit of coding and tinkering with technology, so I might as well make use of my time and achieve something.
  2. The toolchain ecosystem for software development is very complete, and many platforms can be used to accomplish certain tasks. It's actually quite simple if you don't delve into technical details.
  3. Create opportunities for myself to learn and experience the complete software development cycle.
  4. Operation and promotion are great opportunities for personal growth.

This five-year plan will undoubtedly be challenging, but it will also bring many rewards. I hope that after five years, I will have a product that I am proud of.

Loading...
Ownership of this post data is guaranteed by blockchain and smart contracts to the creator alone.