From the translator: we publish for you the
article of the developer Jack Finlay. Jack talks about his own case - an attempt to organize the work of a team of juniors, where everyone is equal and there is no technical manager. The article will be useful for novice programmers.
Some projects may come to a standstill, to end with nothing for a number of reasons. Technical guidance is something that is often lacking. This problem can lead to a fiasco. Once it happened with a project I was involved in developing.
Skillbox recommends: A two-year hands-on course “I am a PRO web developer . ”
')
We remind: for all readers of "Habr" - a discount of 10,000 rubles when recording for any Skillbox course on the promotional code "Habr".
Time can teach you a lot. Unfortunately, we gain experience as a result of working not only with successful projects, but also with unsuccessful ones.

Personal experience and leadership
More precisely, the lack thereof. In our project there was no lead or someone with the post of senior developer. In principle, it was already clear what would happen with our work, but at that time we did not understand it.
The team had no experience. Almost all of us were students, and there was no one who could lead us. Then it did not seem necessary to us.
Over the course of one summer, the number of team members increased fivefold. Problem? All were about the same professional level. Everyone lacked experience. We split into several groups, each of which was responsible for something.
And almost all the project participants were good people, responsible. But it was our first commercial project. My team was very good, we worked perfectly, but the result was a failure.
ToolsA key component of any professional's work is tools. Without the right tools, the normal course of the process is impossible. A good team usually has a leader who knows who needs what tools and where to get them.
DatabaseIn this project, we had access to a common database hosted on a virtual machine, one of the slowest ones that could be obtained. Naturally, we experienced all the "pleasures" of such work: data loss, falling tables, simultaneous actions on the same elements. All this great braked our work.
We did not have the ability to reproduce the database, either locally or in the cloud, without performing a backup and restore operation. There was no way to get a “clean” database in the same state in which we would like to deploy it in different environments. The database could only be created as a clone from the database of our server.
But the project worked only from the database, which was located on the working server. This meant that we could not test the base and the project dependent on it locally. Several times there was a situation when we had to roll back the base to a certain point, because at night someone had destroyed it with careless actions. This greatly hampered the development process.
The migration and update of the database was done manually. That meant ... yes, we were losing time again.
Now it seems obvious that developers should have local databases on their machines. In addition, you need to use automatic migration tools. This gives developers the freedom and opportunity to maneuver in certain situations.
PerformanceDevelopers need high performance from both local machines and the server where the project is being tested. But since we had slow tools, there was no reason to dream about it.
Many had extremely slow devices that had been used for many years. Keyboards, trackpads - all this bore the stamp of time.
The servers were also slow, as I mentioned above. As a result, the whole development process was slow. Tests also progressed slowly.
The conclusion is simple, in the style of KO, - to give the developer the equipment and resources that they need for the normal development process.
Source control
It was all chaos. We used the corporate source control system, but the problem was not software. There was just no strategy. Separate development teams worked each “in their own swamp,” and we had no agreement on when we would merge the individual brunches together. The result was what turned out to be: conflicts, conflicts in merging everywhere. We had to spend a lot of time solving problems and correct synchronization.
Integration and DeploymentWe had no CI / CD solutions at all. The deployment was simple: we copied resources from the built-in folder and pasted them into the server via Remote Desktop. If you did something similar, you can understand my pain.
For those who have not encountered a problem: if you have something in the buffer, besides the necessary files, this will kill the upload of files to the server. If someone else from the team joins the server to upload files, you will have problems. In addition, some files may be transferred damaged.
My advice is to choose a CI / CD solution for yourself.
Quality control
Another important element of the development process is quality control.
ReviewThis work was with us in that the team members got together and looked at the work done. And in the code, we sometimes did not even look, so that a huge number of moments passed by the attention. Another problem was that we had no experience, and therefore, an understanding of what is good code. We could not immediately isolate the errors in the code that an experienced developer sees immediately.
If the team had a senior developer, he would immediately be able to let us know where the problems are and how to deal with them. But it was not, we worked independently.
TestersWe didn't have them either. We conducted tests on our own. Again without experience. As a result, precious time was wasted, which we spent on catching bugs and eliminating them.
If you want a good code - we need testers, and professional ones. Developers do not always cope with the problem of software testing.
Quality code
Many of us at the beginning of the journey are representatives of the “copy-past” culture. This means that the developer is looking for the necessary project solutions on Stackoverflow and inserts the found piece without a twinge of conscience. The result is not very good code, which is practically unreadable and which developers find it difficult to explain completely. Even the person who copied a certain area often cannot understand his work.
I can only advise one thing: if you copy the code, you must fully understand it. Without this, it is impossible to implement a normal project.
Spaghetti codeA poor understanding of the architecture of the project led to total chaos. Spaghetti code - a soft description of what happened in the end.
Some sites passed through different hands, different developers, each of which added something different. The final project code was a collection of ideas and crutches.
We did not have a dependency injection system, and we didn’t use any common design patterns. This led to a lot of bad code that just started to "rot."
What can I say? Code readability is just as important as proper operation, and these two things go hand in hand. Clear, consistent style and holistic code provide the most effective result.
Conclusion
Many problems arose due to our lack of experience. We just did not know how to work on the project. We could not properly implement the environment. We did not have the right tools and technology.
A good team leader would solve all these problems. He would have foreseen much in advance.
By the way, the project itself was not the worst of what could have happened. I met many future colleagues with whom I still communicate. Got the necessary experience to work as a pro. And I realized that without a normal leadership, even the most capable team does not fully realize its potential. Never.
Skillbox recommends: