Programming: Practices that I will take with me

I have quite a bit of experience in software development (only 6 years old), but I have already gained a number of useful and correct practices (in my humble opinion) that can be used to create software.

Basically, the moments that relate to the support of the software development process are described, the topics of planning progress are not affected. Also, the programming process and useful buns for it (for example, stratification of the system into levels, use of design patterns) are not affected. But everything below was and remains useful for me personally, and I will be glad if you can use anything :)

• At the end of the working day, a brief summary, and a written answer to three questions: what was done, what problems arose, what was planned to be done. It is also a good idea to provide this information to the whole team (email, internal blog), and if they have an interest, they can read this report. The usefulness of this practice is invaluable, everyone who prepares a report thinks at the end of the day about the question: what did he do today useful. And in order to answer this question, it is already worth using this practice. By the way, some will notice that this practice is present in the Scrum methodology. But the first time I saw her at the Irkutsk Aviation Plant, one very interesting person told me about her.
• All project materials should be concentrated in one place. For example, links to the logs of communication with the customer or URL for source code repositories. Order is never superfluous, and sometimes it greatly enhances performance.
• Need to manage customer requirements. What is meant by such a general statement? Everything is simple, all requests for changes made to the project from the customer must be recorded in electronic form. In severe cases, the customer must sign for each of their requirements. Yes, this is bureaucracy, and it is more interesting to write code, but without this your project has a very high probability of failure. Although a lot depends on it.
• After receiving the job from the customer, you need to explain to him in your own words what he wants. This thing is very important, without it, things that the developer wants, and not the customer, are often realized. Although this sounds crazy, but here we must very carefully coordinate the requirements, because the developer is also not a fool and understands what the implementation of strange requirements will lead to.
• To hang up on the general review the chart describing architectural features of the project. Ideally, next to it hang a diagram with the progress of work on the project. This will raise the level of communication between team members to a fundamentally different level. The main thing to remember to poke a finger in the elements of the diagrams when discussing the project. And don't forget to draw your thoughts on the blackboard for general discussion :)
• The source code of the project should be stored in the version control system. Order is never redundant. This is especially important when the code is written by more than one person, although I no longer imagine how you can write code without a version control system. I guess I have a complex :)
• There should be instructions for setting up the working environment for working on the project. If this document is not present, then true chaos turns out when a new person is connected to the project. Yes, and the transfer of cases is much more difficult. Project wiki is perfect.
• Using a task management system. The presence of this system will allow for more productively correcting various problems and not forgetting about them. Do not forget it well.
• The presence of a description of the assembly project. If every time a project is assembled is a series of magical passes, and only a single guru in a team can assemble a project, then this is a mess. If there is a description of the application build process, at least in text form, this will greatly simplify the work of all team members, and will relieve you of a number of stupid questions. Ideal when the application build process is automated (for example, using Ant or Maven), then the happiness of the developers is truly infinite.
• The use of continuous integration systems. Perhaps you don’t need this, but I’m very happy about the fact that the system is being assembled every day, and perhaps all the tests pass. This greatly increases confidence in the system you are developing.
• Be wary of systems independent of you. Internet unreliable thing.
• Be ready for change. Not all changes are equally beneficial, but you must be prepared to accept sensible things and use them for your own purposes. Including, it is necessary to take this text critically :)

I hope you do not waste your time reading this text, and something will be useful to you :) By the way, a draft of this text can be found on my blog :)