background
I’ve been asked that question a lot. I didn’t answer them in detail. I asked so many questions that I felt I needed to write out everything I wanted to say at once. So if anyone asks me in the future, I’ll dump it. Perfect.
confused
In my opinion, most of the reasons are as follows:
- The degree to which there are too many business demands to work overtime
- The business is simple and feels low-tech
- Don’t know how to improve yourself from a mediocre background
- other
Whatever the reason is, I’m lost. In fact, I feel that these problems can be encountered by everyone, only at different technical stages, including myself, and indeed encountered. Although I don’t think I succeeded in breaking the game, I can share my current coping method, you can refer to see if it is helpful for you.
broken
The degree to which there are too many business demands to work overtime
- As FAR as I know, business requirements never get done. This question, I think if you just join a new company, not familiar with the business, then you have to work overtime, slowly summarize, as fast as possible familiar with the project speed. Here is the summary, which can sum up the content:
-
Document the development process. There are usually several steps, different systems, and even various permissions and accounts. Take a good walk through the process, record the process of the development process in the form of pictures and texts, form their own notes, strive to do, just ask colleagues once, you will learn, familiar with understanding. If you don’t have any documentation or if your documentation is old, you can just deposit a new document, great!
-
Document common business code snippets. The business direction of a team is usually fixed. So there must be a lot of things that you can reuse, or you can reuse after you write them. In this case, if it is a large functional module or logic, an NPM package can be formed and isolated for reuse. Small fragments can be put in util, or even directly copy into your notebook for easy searching and use. Although carrying code does not have much content, but in your understanding of the premise of carrying is the best way to save time and quickly, learn to stand on the shoulder of history.
-
Comb through the pain points and break them down one by one. When you encounter pain points or flash points during development, you must record them in time. For example, I always keep a note directory called ideas worth over 100 million. You can just write one sentence and note the pain point, which is where you find it time-consuming or unreasonable to waste your time. Write it down, and then take time to sort it out. From a problem standpoint, if I find it difficult to use, what do I expect, and how can I make it work for myself? The idea is, I want to make something, solve something. If these insights are not recorded in time, they are often forgotten.
-
Improve their abstraction ability, encapsulation ability. Of course, this said a little abstract, need to rely on their own perception. How to understand, that is to read more excellent great god’s code, look at others when writing code, how to write, how to design, this kind of comparison with their own, pros and cons. If you read enough of this stuff, you can always learn something.
-
Feed back up and throw out risk points. How to say this? Although overtime is inevitable, it is not necessary to walk the pace of 007. According to their own actual situation, set a range of overtime that they can accept. For myself, the maximum overtime time I can accept is 10115 at present. I can also work overtime on weekends if the project is rushed to launch, but I cannot work overtime on weekends continuously for a long time. If you’ve done your best and still can’t deliver on time, take it up with your supervisor. Some people say that the boss doesn’t care about you and will leave if you can’t finish the job. So if I had such a boss, I would leave by myself.
-
Impose free time. When assessing your requirements, set aside a half-hour to an hour of free time each day to do what you really want to do. One of my suggestions is to prioritize infrastructure/wheel research or coding related to the job. After all, productivity is what’s needed at work, and business-based technology is both more meaningful and more challenging.
The business is simple and feels low-tech
-
If your business is simple and you don’t have much skill, and you work crazy overtime, I think it’s a contradiction. First of all, if there are no simple technical requirements, there are usually tools or systems that can be improved to increase productivity. Or if you don’t have one, you might want to research the sharing practices of open source projects/big companies in that context. For example, I always cut images and make pages. Have you ever thought about visual construction? Ever think of a project that outputs page code from a design draft? Have you ever thought of material precipitation, repeated extraction and utilization? Are what can be mined point, or is their own cognition and level, still do not know.
-
Participate in large companies’ technology sharing conference, which is usually based on specific business to do some promotion work, can increase their knowledge and breadth of thinking.
-
If you’re a company or a team that doesn’t have anything, then you’re on your own, building your own community impact, blogging, working on open source projects. You can do what I do, write articles, find money, make official accounts, etc. These are all directions to try.
-
Into the technology group communication, pay attention to the front Q, study articles, pay attention to the front trend, read all kinds of source code, thinking about the design of these frames or wheels, anyway, is much thinking, confluence, feeling out of their own things.
-
Job-hopping. If you feel like you’ve been stuck in the same place for a long time, starting over may be an option.
Don’t know how to improve yourself from a mediocre background
First of all, the context is general and absolutely relative. Glittering people are big, but not all over the street, most of us are just ordinary people. Since we are ordinary people, why care about what background is not background. Just study in silence. I would like to share with you some of my own methods:
-
Summarize the projects that you have access to at work/in the company and get to know the project from the background, what 0 to 1 did, what 1 to 2 did. The most important thing is the data, how these changes are reflected directly in the data. Sum it up.
-
Set up imaginary enemies, such as the same front-end direction, their own to achieve his number, or higher than his number (the most direct embodiment is 💰), always spur their efforts.
-
Replace the ideas/wheels/methods in the framework, most simply, assuming your project uses JQ, can you use native JS implementation and replace the methods in the project? Don’t always say the project is easy, no highlights and no challenges. No matter how simple the project is, you can dig out the difficult points by yourself. It depends on whether you have the courage and patience to do it. For example, applets do not support store state management. Can you implement one? In fact, are their own excuses for their own just, or you feel this can not take out to pack force, do not want to start. However, if there is no early accumulation, and how many people can rise to the sky? Front man, be steady.
-
Touch more of what is necessary for the front-end advancement. Principle source code/automation (performance/test/deployment release)/performance solution (continuous integration/micro front-end /node middle tier), etc
conclusion
A long journey begins at a single step. When you feel like you’re stuck in a rut, take a moment to reflect; When you want to practice some big projects, might as well take small projects to practice hand, slowly precipitation; When you’re working a lot of overtime, look for projects to learn from.
There are not so many hands to teach, the front end is to rely on their own enlightenment, struggle, SAO years!
The last
- Welcome to add my wechat (Winty230), pull you into the technology group, long-term exchange learning…
- Welcome to pay attention to “front-end Q”, seriously learn front-end, do a professional technical people…
