How lessons from a tradesman can help out a techie
In fact, most of the knowledge and skills in work and life are the same. It helps greatly improve your skills. This article is some of the experiences that a software developer has learned from his father as a mechanic, and these experiences have eventually become the best developer.
The full text is as follows:
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 woodworking engineer. He is very smart and talented in both construction and maintenance (as long as it does not involve electrical engineering, it is another thing ). He can even work on walls, sheds, and decks at the age of 60. When my brother and I were younger, he began to expose us to some tools for his work. Therefore, when we found that we needed to fix or make something, we have the ability to do it well. Well, although he has almost failed in my education, I still learned many important things along the way, and whether you believe or not, what I learned, I have benefited a lot from being a good developer and entrepreneur.
Here is what I learned from him.
Lesson 1: think twice
Cutting firewood is a one-time task. As long as the trees are cut down, they cannot be kept as they are. Therefore, it is very important to ensure that every delete operation is correct. Even if you are sure that your practice is correct, please make an assessment at any time. Re-check your evaluation to make sure it is correct. In this way, you can avoid mistakes that can be avoided, and the cost is much lower.
The same is true for developing products. If you do not measure the size of the space occupied by the bookshelves, how can you make a suitable bookshelves? If you do not know your needs in advance, why did you develop a useless product? This principle has been mentioned many times. I have skipped it here. But what is not often mentioned is that your product is a collection of functions, just like a collection of shelves. Every function should be taken seriously and evaluated carefully to ensure that it is applicable to the audience. It is important not only to collect feedback at the beginning of the project, but to pay attention to feedback throughout the development phase of the project, rather than waiting for the end of the project, to remember that there are still some good ideas not implemented.
Lesson 2: It is very difficult to paint a built pavilion.
On one occasion, several workers repaired the pavilions at home and they began painting after the pavilions were built. Dad pointed out that if the workers could paint the wood on the ground, they could spend about 1/10 of the time and the effect would be better. After painting, you only need to do some connection work to quickly build the pavilion. It is not only slow and inconvenient to paint the built pavilions, but may also lead to some areas that are not easy to paint. The worst thing is, if unfortunately, it makes a mess.
In the product development process, it is easy to forget the design and ui, but these are very important. The user-centered design is to take service users as the top priority when designing pages, and then develop corresponding applications to support this design. Taking software development as the priority and putting the design at the end, you will do more work and the product will also have potential disadvantages. UX should be a continuous process, not something that can be discarded at will.
Lesson 3: Keep your projects and workspace clean and tidy
Working in a messy environment will make your project results messy. If broken wood chips are everywhere, you won't be able to paint well. If your tools are full of oil, you won't be able to assemble the broken engine parts together; if you do not collect and organize the tools, you may never find the screwdrivers you want. Any mechanic will tell you how important it is to work in a clean environment. What's worse is that you spend more time looking for tools with the wrong location, which can lead to more losses.
Every developer's code may have some bugs. Many developers know the term "code debt". It only looks at this messy area from the developer's perspective. If you bury hidden risks at the source, the consequences will not only be more difficult to find bugs, but also cause more confusion in the future. Eventually you will have to clear them (especially before you start your work, you will have to clear these bugs left by others !). Every developer knows the terror of modifying others' code, and will realize that they have left a bunch of troubles waiting for you to solve. It takes a little time to sort out your workspace. In the future, you will save more time.
Lesson 4: always use the right tools (and don't be stingy with your tools)
One of the main reasons for messing up a job is the use of inappropriate tools. Although this is obvious, many people do not realize this. The end of an incorrect tool is usually a disaster. Don't worry about money. You should find the right tool when you start your work.
Improper selection of tools is usually a mistake made by the management, but our developers are also responsible for this. Without a doubt, a notebook that has been in use for six years will be very slow. Even if you spend $10 on a text editor, choosing the worst one won't help you. The savings won't help you win the hearts of customers. The worst thing is that using pirated software to make money is totally wrong. Today, you may feel that you have saved some money, but it will definitely cost you more in future operations. Find the development tool that best suits your project and then spend some money (unless it is open-source !). After the project starts, saving is especially challenging. Don't spend money unless you need it. But if some tools need to be used, you have to choose the best one.
Lesson 5: If none of the methods work, find a bigger hammer.
Sometimes you get stuck, which means you have encountered a problem. Sometimes, no matter how hard you are, you cannot screw the bolt into the nut. Sometimes no matter how hard you beat, the nails won't be knocked in. At this time, you only need a bigger and more suitable hammer.
As one of the founders of bugherd, I used to encounter situations where I was supposed to seek help. But I am struggling. I read through the manual, watch videos, and read blog articles. Then I woke up and realized that no matter what I did, someone else would do better than me in this regard. Currently, we have two colleagues who are proficient in JS. They do better work than we do at any time. There are many excellent tools for remote team collaboration, so don't make excuses to say that there are no suitable colleagues working with you. Sometimes, you only need to accept the reality and find the corresponding solution.
As an entrepreneur active in a professional development and design community, I often feel like living in a petri dish. It is also a good practice to stop and observe more traditional industries and see what we can learn from the previous generations who have made outstanding contributions. No matter how smart we think we are or what advantages they have, we can always learn a lot from these predecessors.