Of course, the 4000 and 6000 in the title are just a gesture.
The document seems to be a weakness of technology.
Recently, I have been migrating from ant to maven. I have arranged for a colleague to write two documents: one is the migration step by step, and the other is the maven getting started tutorial. The tutorial is easy to explain. We can use the PPT to introduce the basic concepts and usage. In the migration step document, I arranged three people to perform drills according to the document, and asked him to correct the document based on the problems encountered during the drill, in order to achieve the reference document, the owner of each module can basically complete the migration. I modified it four times. In fact, the main content has been clearly written, but I can't help but make the final improvements, in fact, there is nothing to add, mainly as follows:
1. Connecting Sentences.
2. explicit declaration of the assumptions, for example, if the maven installation path is XXXX. Otherwise, it is difficult for readers to understand the location of settings. xml.
3. Added cross-reference. For example, the artifactid in POM should be filled in XXXX. For details, see the negotiation result in section 1.2.
4. Add more methods for further help for areas that are difficult to clearly describe. For example, the path for submitting CVS must be determined based on the groupid and artifactid of the module and the inheritance relationship between the modules. If you cannot confirm the path you should submit, contact xx.
Every time a meeting asks a developer what your goal is, everyone will answer: first raise the technical skills, then design and become a project manager. In short, no one is willing to lag behind, at least I have not heard anyone say so. If I ask another question: how can we make progress? Many people will answer: to improve the ability to analyze questions, some people also replied: to strengthen the technology.
However, in the subsequent daily work, many people do not regard what they are doing as an ideal opportunity to practice. In most of my contacts, it seems very difficult to ask them to leave programming language analysis problems away, such as writing documents. Let me say: You should refine the ideas we discuss today and organize a document. So what I often get is a few words of notes, and there is not much content outside of our conversation, more like meeting minutes. But if I say: you can elaborate on this idea. I often get a demo soon. This demo does have many ideas worth exploring.
Although it is good to verify some ideas through the demo, if you are dealing with a large system, it is impossible to describe all aspects first and then refine. The difficulty of writing a document reflects the lack of ability to analyze the problem. However, the more you lack this, the more you should make up for it in practice, rather than avoiding the document. There is a conflict between beautiful ideals and daily work.
If there is such a rule: A demo will be made for 4 K/month, and a document will be written for 6 K/month, can this situation be reversed?