preface

This year, I set myself a small goal of writing 30+ articles, but I still don’t know what to write. Every time I want to write something technical to share, I will find that there are already predecessors who can’t write better. After thinking about it, I thought I was better suited to write things for myself rather than share. Sharing needs to be considered for the public. Good readers may like it, but bad readers will certainly hate it. And write to oneself need not care about so much, right when is to write down a note, in the future.

Combined with some recent reflection on work and after reading “Everyone is a Product Manager” feeling, to talk about their work and books to make up for their own shortcomings.

Insight # 1: Look at coding with the user in mind

In my opinion, essentially speaking, the Internet industry is a service industry, and we programmers are just one of the many service personnel in this industry. It can be likened to a chef in a restaurant. The chef requires the food to be delicious in color, smell and taste. After eating, the user agrees to come back next time. In the same way, we should always remember that “the user is king”.

But I don’t think the phrase “the user is God” is accurate. There are two main problems.

• The first point is from a technical point of view, who are our users?
• The second is what does God really like? We know what God likes so we can do what he likes.

So, in my case, as a front end engineer, who are my customers? In fact, I think there are two general categories.

One is the colleague next to, including the front of the same group of students, as well as the relevant test students. Because we sometimes maintain the same project, the code is written for each other to read, so it can be understood that the code I write is “product”, and they are naturally my users to read my code.

The second category is “real users” who use the project I’m working on, which is understandable because my code ends up being part of the product, so the users who use the product are also my users.

At this point, I seem to be referring only to the first half of the title of the paragraph – targeting the user, not how to think about coding. Don’t worry, keep reading.

When your users are colleagues

Before we begin, let me ask you a question: What do you want your coauthors to write? Leave a comment in the comments section.

If I write my own code as a product and my colleagues as users, I think my code should have at least the following characteristics (it does not mean that I currently have the ability 🐶)

• Easy to read (how will colleagues maintain large amounts of code without comments later?)
• Brevity (as much as possible to write a function in a function point, also for easy maintenance)
• Specification (not following the uniform specification of the project is like a soldier disobeying the command of the unit)

So how do you meet these requirements? My understanding is carefulness. In fact, this part can be achieved as long as you put your heart into it. The lack of deliberate effort only shows that you have no awareness of the maintainability of the project. I also think people are more willing to work with engineers who pay attention to detail. For the sake of your long-term career, try to improve the quality of your code.

When your users are users of the product

At this point, there are more questions to consider and more carefully. Because your code is so uncomfortable, you’ll get yelled at at most. But if something goes wrong with your program, it’s an accident, and it affects the company’s revenue, and in other words, the consequences for you are very serious. They may even lose their jobs.

I’m not exaggerating here, but I’m trying to raise awareness of the product.

When your users are users of a product, what characteristics do you think they want to use?

In my opinion, there should be the following points

• Basic function is normal (this is the most basic requirement, taxi software can take a taxi at least? Order software can be used to order, right?)
• Beautiful page (human is a visual animal, to retain the user’s heart to retain the user’s eyes)
• Smooth performance (stutter, frame drop, crash can you tolerate that?)
• Security (I can still accept bugs, who dares to use viruses)

If the user base is relatively large, it should be considered

• Multi-terminal compatibility (why does it work on your phone but not on your computer? How did this button get so big on a tablet? Ugly!!)
• , etc.

The above is just standing in my personal perspective to consider, on the merits of the product benevolence benevolence wisdom, we can express their views, but I think the general characteristics or so a few, in a word: good to use, good-looking, good safety.

Back to the point, how can we help our product achieve these points during development?

In fact, I still say the same thing, to be product conscious. If you are aware that your code will affect the many, many uses of the product you are working on, you will naturally pay attention to the quality of your code when you code.

For example

At the beginning, IN order to complete the task, I would write some code that could meet the target requirements without considering memory or performance. You also understand that in the future this code will become part of the mountain of shit. Take the crazy setState when writing react code, where there are several variables that render the page several times, and now you wonder if you can combine some of them into one to reduce the page refresh rate.

Again, in memory, maps can be used to cache data that is looped through every page refresh.

For CSS, can not write dead do not write dead, is the page itself to do adaptation.

Here I would like to post the code for you to see, but it is not very good, and this article is not a technical article, it belongs to the miscellaneous, so called pure bullshit, you read fun.

Feeling 2: Move bricks efficiently

During this period of time, I felt that MOST of the time I spent half the effort, and spent a lot of time doing little work. After serious reflection, I reviewed why I had low work efficiency before and summarized how to improve my work efficiency in the future.

More haste, less speed

Eager for success can be a very appropriate description of the development mentality during this period, for the demand in their hands, they often want to solve it quickly and then go to the next one to improve their output, while ignoring the thinking process before the development of demand. Because some requirements it may not be as simple as it looks on the surface, or it may not be difficult to achieve technically, but in fact you need to be very careful, especially at the C end, there can’t be any problems in the style, and the pursuit of speed will lead to quality problems.

Tagline: Find a balance between quantity and quality, and spend as little time as possible to meet the quality and quantity requirements. Manage your time properly and break down the requirements development process into how many tasks to complete each day.

Plan before you act

Here and the above shortcomings are actually very similar, that is, do not pay attention to the thinking process before the development of the pursuit of speed, ultimately lead to quality problems, and then the time saved in front of the modification to go up, not worth the loss.

In addition, it is worth mentioning that in the past, the development habit was to write while tuning, and finally verify, but this development habit should be gradually abandoned, because it can not keep up with the current development pace. Now is the time to spend some time thinking about what you’re going to write before you start developing, then “get it right” and fine-tune the details.

Note: This change in development habits may be uncomfortable at first, but you have to do it or you’ll always be an inefficient coder with no time left for more meaningful things.

To do a good job, he must sharpen his tools

As an engineer, you need to be familiar with the language and development tools at your disposal. For example, for CSS, before just fragmentation learning, know what attributes, probably how to use, in the face of simple UI is of course no problem, but in case to do something is not simple or even to have good sense of animation, it is completely dumbeyed.

The other is the development tool, I use VSCode, because I am not familiar with it in the early development process made a lot of very silly mistakes, especially in the use of git. In fact, if you can proficiently use development tools, will certainly help us greatly improve work efficiency, at least in formatting code, debugging code and other development in addition to help us a lot of help.

Post: Find an article to learn more about the full capabilities of your IDE.

The foundation is weak and the earth shakes

A solid foundation of knowledge is absolutely a prerequisite for efficient work. I believe that when you are proficient in the theoretical knowledge of a language or a technology, you will never have frequent obstruction in coding, and you will have many ideas to solve difficulties when you meet them. The basics can tell you how far a programmer can go.

Tagline: A solid foundation of knowledge helps us to finish our work efficiently so that we have more time to learn other knowledge and form positive feedback. So don’t forget to study no matter how busy you are.

conclusion

To sum up the above points

• When coding, remember to consider the impact on the product, consider the impact on the user, pay attention to details, not rush to success.
• Finish the work efficiently, and remember to keep quality on the basis of quantity.
• Think before you code, be careful when you code, and learn after you code.