The mechanic's father taught me 5 lessons.

My father is an engineer-a mechanical engineer, not a software engineer. Before he became a mechanical engineer, he also worked as a mechanic and carpenter. He's smart, and he's gifted at building and maintenance (as long as it doesn't involve electricity, but that's another thing). He was able to do work like fences, sheds and decks even at the age of 60.
　　
When my brother and I were young, he started to let us get in touch with some of the tools he worked on, so when we found something we needed to fix or make, we were able to do it. Well, although his education on me has almost failed, I've learned a lot of important things along the way, and, whether you believe it or not, these things I've learned have benefited me a lot from being a good developer and entrepreneur.
　　
Here is the knowledge I learned from him.
　　
Lesson one: Think twice.
　　
Chopping wood is a one-off job. As long as the trees are cut off, it is impossible to keep them as they are. Therefore, it is important to make sure that you delete every time the operation is correct. Even if you are sure that you are doing the right thing, please do another assessment anyway. Re-check your assessment to make sure it's correct so you can avoid mistakes that could have been avoided, and pay a much smaller price.http://blog.voc.com.cn/blog_showone_type_blog_id_981314_p_1.html
　　
The same is true for developing products. How can you make a bookshelf that fits the size of a bookshelf without measuring the size of the space it occupies? If you do not know the needs of users in advance, why should you develop a useless product?
　　
This has been mentioned many times, I have skipped here. But one thing that is not often mentioned is that your product is a set of functions, just as a bookshelf is a collection of shelves. Each feature should be taken seriously and evaluated carefully to ensure it is suitable for the audience. It is important not only to collect feedback at the start of the project, but to focus on feedback throughout the development phase of the project, rather than wait until the end, to think of some good ideas that have not been realized.
　　
Lesson two: It's hard to paint a built gazebo.
　　
On one occasion, a few workers repaired a gazebo at home, and they began to paint after the gazebo had been built. Dad saw that if the workers were able to paint on the ground, they would save 1/10 of their time, and the results would be better. After the painting, just do some connection work, you can quickly build the pavilion. Painting a well-built gazebo is not only slow but inconvenient, but it can also lead to some hard-to-brush places, and, worst of all, make a mess of it if it's unfortunate.
　　
In the product development process, it is easy to forget the design and UI (the short name of the user interface interface), but these are important. User-centric design is the design of the page, to serve the user as the first priority, and then develop the corresponding application to support the design. With software development as a priority and the design put to the end, you will do more work and the product will have potential drawbacks. UX (User experience test) should be a continuous process, not something that can be discarded at will.
　　
Lesson Three: Keep your projects and workspaces tidy
　　
Working in a cluttered environment is sure to mess up your project results. If the chips are everywhere, you can't paint them, and if your tools are covered with grease, you won't be able to assemble the dismantled engine parts together, and if you don't collect them after you run out of tools, you may never find the screwdriver you want. MoreInspirational EmperorThe article recommends that any mechanic will tell you how important it is to work in a neat environment. It's not just that you spend more time looking for misplaced tools, but also more damage.
　　
There may be bugs in every developer's code. Many developers know the term "code debt," which is really just a developer's view of this area of work chaos. If you bury the pitfalls at the source, the consequences are not only more difficult to spot bugs, but more confusing in the future. Eventually you will have to clean them up (especially before you start your own work and you will have to clean up the bug! left by others. ）。
　　
Presumably every developer knows the horror of changing someone's code and realizes they're leaving a lot of trouble for you to solve. Now take a moment to tidy up your work space and you will save more time in the future.
　　
Lesson Four: Always use the right tools (and don't skimp on your tools)
　　
One of the main reasons for screwing up a job is to use inappropriate tools. Although this is obvious, many people are unaware of this. The consequences of using the wrong tool are usually a disaster. Don't be distressed with money, you should find the right tool when you start your work.
　　
Improper use of tools is often a mistake made by management, but we developers are also responsible for this. There is no doubt that a 6-year-old notebook will be slow to run. Even if it costs $10 for a text editor, it doesn't help your job by choosing the most crappy one. Saving a few dollars will not help you win the customer's heart. Worst of all, using pirated software to help you make money is a completely wrong thing to do.
　　
Today you may think you have saved some, but you will spend more money in future operations. Find the development tool that best suits your project and then spend some money (unless it's open source!). ）。 Savings can be particularly challenging when the project starts. Don't spend money unless you need it, but choose the best if there are tools that need to be spent.
　　
Lesson Five: If the method doesn't work, then find a bigger hammer.
　　
Sometimes you get stuck, which means you have a problem. Sometimes no matter how hard you push, you can't screw the bolt into the screw hole. Sometimes no matter how hard you knock, the nails will not be typed. At this point you just need a bigger, more appropriate hammer.
　　
As one of the founders of Bugherd, I used to encounter situations where I should have sought help. But I struggled, I read through the manuals, watched video footage and read blog posts. Then I woke up and realised that no matter what I did, someone else would have done better than me in that respect. Maybe you like to watcha sentence of positive energyOh.
　　
At the moment, we have 2 colleagues who are proficient in JS, and they do a better job than we do at any time. There are plenty of great tools for working with remote teams, so don't make excuses to say that you don't have the right coworkers to work with you. Sometimes, you just need to accept the reality and find a solution.
　　
As an entrepreneur who is active in the professional development and design community, I often feel like living in a petri dish. It is also a good practice to stop and watch some of the more traditional industries and see what we can learn from those who have made outstanding contributions. No matter how smart we think we are, and whatever their merits, we can always learn a lot from these predecessors.

The mechanic's father taught me 5 lessons.