"Constitution" for Developers: How a GitHub Page Has Been Helping Us Not to Swear for a Year

A year ago, my team grew: the business logic became more complicated, in fact, we were divided into three sub-teams - each of them included both newcomers and those who had worked in the company for years. The sub-teams focused on their directions, and although everyone sawed billing, the principle of a common area of ​​responsibility ceased to work. And the practices that worked for the "oldies" did not always fit the new team.







Usually, to rally teams, we practice trips: the rest of the time, working remotely from their cities, the guys gather in one part of the world. In the afternoon, they go through part of the sprint, in the evening they have fun together. But the deadlines were tight, so we went the other way. Here's what we came up with - and it seems that this approach can be used by any team in which there is no authoritarian management.



Thanks to Ray for the idea



In the spring of 2019, there was only talk about the book β€œPrinciples. Life and Work ”from Ray Dalio. Aleksey Kataev also heard about her - he is also "Team Lead Leonid" and our then team lead.



Ray Dalio? Who is it?
1975- Bridgewater Associates. 2010- - . 100 .



, , , , .


Lyosha came to billing to establish processes. He had a clear vision of what the team should be - and the ability to persuade. When everything worked, he went up. And before leaving, he offered to form contracts and consolidate the work of already debugged processes in the team, writing the "rules of life" for the development team. The new team lead supported the idea - and it started.



To begin with, we read those very principles of Dalio . There are 16 of them in total, but in order to find out everything, you need to buy a book, the meaning can be understood from these four.

  • Accept reality and work with it.
  • , , .
  • .
  • , .


Pathetic, of course. But we decided to try to adapt them for ourselves. Lyosha sketched out a list of 10 principles, and the team supplemented it, bringing the total number of abstracts to 43. We opened a repository on github: it is symbolic that the rules of work will be hosted in the same place as its result.





And, to be honest, it's easier to maintain and develop this whole business this way.



Then they began to shorten the list and improve the wording, evaluating each item according to three criteria: concreteness, agreement with the principle, importance. Discussed and refined until the thesis suited all interested.





We agreed on the shore. This was Lyosha's idea.



In the process, it became clear what we are looking at differently, but after several days of active discussion, we have a release candidate.



image

The pool request had to be approved by every team member.



After the final vote, the team lead released the first official version of the Team Life Rules.





Announce the entire list, please



We have broken our "constitution" into two parts: 12 general rules of life and behavior in a team, plus 15 technical principles. The text is quite long, so we will hide its main volume under the spoilers. Spelling and punctuation are preserved in the original.



Work principles



1.1. We follow accepted principles, regardless of whether we agree with them.

Personal disagreement is not a reason to deviate from the principles. However, you can start discussing any principle if circumstances change and it is no longer useful.



11 more points
1.2

β€” . β€” . β€” . , . , .



1.3

- . , . . . , . . . . β€” .



1.4

: , , , . β€” . β€” .



1.5 ,


1.6

β€” . : , , , .


1.7

. , , . β€” .



1.8

β€” , β€” . , . , .



1.9


1.10 β€”

, , β€” , β€” . : , , , . , , . -, β€œ ”, β€œ ” β€œ ”. , .


1.11 , ,

. β€” , , , β€” .


1.12

. .



Technical principles



2.1. We think about the consequences

Before a difficult rollout or migration, we think about what we will do if everything goes wrong. We make backups, rollback scripts, assess the risks of a fall. We drive away the thoughts β€œah, it will blow, everything will be ok”.




13 more points
2.2 ,

β€œ ” -.


2.3

, , , . , .


2.4

!= . .



2.5 , β€”

β€” , Skyeng. , , .


2.6 ,

, - , - . β€œ ” β€œ, ”.


2.7

, :

β€” RabbitMQ: ,

β€” : ,

β€”

β€” SOLID, DI, IoC



2.8

β€” , . : . β€œ ” β€” . .



2.9 , QA

. β€” . β€” QA. β€œin development”, production : .



2.10

100% coverage , 100% coverage.



2.11

.



2.12

: , .



2.13

, . , .



2.14

, . , phpdoc, , README.



2.15 We do not rewrite projects from scratch The

chance that this is a good idea is minimal. We drive away the thought of writing something from scratch by throwing away working code that has been tested over the years. We are constantly improving and refactoring, making shit code a dream code. We get rid of "double" systems, but do not create them.



By the way, Lyosha made a separate report on the last point .





Okay, how does it work?



  • : , , GitHub β€” , , .
  • β€” . 360, : . - .
  • β€” : , . (, ) , , . , ( ) Β« !Β». , , . , .
  • , . : , , β€” Β« Β». , .








After some time, the team became virtualized at the rally in Sochi. Then we printed the principles on paper like papyrus, flashed them, and everyone got a beautiful brochure that they took home.





Teamlead says he wanted to get our autographs on paper in blood. He's joking, I guess.



The principles can be changed now. If someone comes up with a good idea, doesn't like something, or wants to add something, any team member can create a request and vote on it: 100% β€œfor” and the amendment has been made.



image

The main thing is not to be afraid to negotiate and discuss problems.



I wonder how it works with you.



All Articles