The Last Supper of Developers
It would seem that in small development teams (20+ people) there should not be problems with disunity, work on a common code and making technical decisions. But we all know that this is not so (not to mention teams like ours, where 80+ people). Three years ago, to solve them, we began to hold a weekly internal DevForum developer conference. Under the cat you will learn about how it helps us, why other formats (such as weekly meetings or Sprint Review) and instructions for creating it are not always suitable.
DevForum is our weekly internal event for Dodo IS developers. It has been running on Thursdays for three years. Developers get together and devote an hour to communicating with each other.
At this meeting, we discuss technical issues relevant to the entire team. An hour of time, two reports of half an hour, time for questions and answers.
In order to advance towards the achievement of a common goal, it is important for us to maintain a focus on significant company issues. For the overall synchron of all Dodo, we have weekly meetings on Mondays. All employees, partners / franchisees are present at them, meeting records can be viewed in the public domain . For a synchron with business and partners, we arrange a bi-weekly Sprint Review . For a single focus and regular synchron of the IT team, you need more immersion in the technical "meat". This is what we are doing on DevForum.
Here is a list of problems and their solutions:
Where did this format come from? Korotenechko. Three years ago, our company made its first attempt to introduce Sprint Review on a regular basis.
It looked like this: everyone gathered in one room, absolutely everything and took turns telling each other who had done what over the past weeks. At that time, there were only 20 of us, but just imagine what it feels like to listen to and look at the code for the business representative, and the developer to look at the pizzeria buildings. We very quickly realized that people listen only to topics that are of interest to them, and on the other topics they are painfully stuck in the phone.
We are faced with the fact that a demonstration of deeply technical to those people who are far from this is such. They came to see how the cash desk starts, and we tell them about the experience of using the Polly framework for implementing retrays between services. We quickly realized that such a format was of little use to people, and Sprint Review, in that form, was bent. At some point, it was simply canceled, and the meeting on the calendar remained.
An initiative group of people thought: itās so cool to show technical things to those who are in the subject. There is a meeting, there are people, there is a desire, there are topics. So we began to gather once a week and continue to do so to this day.
We know that our DevForum is not a super unique format, many of our colleagues have tried something similar. But, unfortunately, often such regular meetings do not take root, quickly become obsolete and wither. Our DevForum lives for three years - this is a long time in order to analyze, collect expertise and share with you the experience of creating and maintaining this format.
You will need 6 basic things:
1. Understanding the tasks and formats of DevForum.
2. Powerful and charged organizers.
3. Consent from the management of your IT department.
4. The availability of space and equipment for meetings.
5. The presence of an audience of listeners.
6. The presence of speakers and topics for discussion.
It may seem that everything is simple (or vice versa nothing is clear), so I will list a few more features of the organization that must be taken into account and kept in mind.
Organizers need to work with speakers. We solve the fear of speaking through help in preparing for the speech. Laziness or disorganization is stopped by a request to formulate the topic in advance, even in draft form, and with the exact date of the speech.
Sometimes there are none. There are times when a lot has been found, sometimes when a little. In this case, you canāt categorically cancel the event. We must try to find topics or speak for ourselves. Organizers are also developers, so we also always have something to tell. You can resort to tricks, arranging more free discussions.
Video and sound quality. Itās a purely technical moment, but it is important for people that the sound is good (check the connection and the Internet in advance), and the demonstration of the code on the screen is readable. Even the most interesting topic, filed with technical flaws, can alienate viewers.
We accumulate material. Meetings must be recorded. We have an archive of videos, with presentations and additional materials attached thereto. There are playlists on YouTube. We put all the records in our documentation system, where there is a full-text search and you can find the topic of interest after and get acquainted.
Dedicated to those development teams in which there are no managers in which you work on a single code, in which developers are interested in knowing what's going on around, for those people who want to develop and help others grow, those teams for whom trust is important inside.
From Dodo Pizza Engineering with humanity
What is DevForum and what problems does it solve?
DevForum is our weekly internal event for Dodo IS developers. It has been running on Thursdays for three years. Developers get together and devote an hour to communicating with each other.
At this meeting, we discuss technical issues relevant to the entire team. An hour of time, two reports of half an hour, time for questions and answers.
What problems does the internal conference solve?
In order to advance towards the achievement of a common goal, it is important for us to maintain a focus on significant company issues. For the overall synchron of all Dodo, we have weekly meetings on Mondays. All employees, partners / franchisees are present at them, meeting records can be viewed in the public domain . For a synchron with business and partners, we arrange a bi-weekly Sprint Review . For a single focus and regular synchron of the IT team, you need more immersion in the technical "meat". This is what we are doing on DevForum.
Here is a list of problems and their solutions:
- Sharing knowledge . Now we have 80+ developers in our team. Each of them has its own background, its own specifics of work, its own level of immersion. Our teams are divided by product. And it may happen that two independent teams need to go through the same wilds. When they have the opportunity to share their experiences, thoughts, successes, or vice versa with each other, it becomes better. There is a small chance of not stepping on someone's rake.
Plus, our team is constantly expanding, new people come and get a ready-made tool for regular upgrade and sharing of knowledge. - Training . Here you can learn if you canāt do it yourself and teach if you can. Training is a point that is very closely intertwined with the sharing of knowledge. Whether we like it or not, we must constantly improve our technical level.
- Technical synchronization of commands (not to be confused with the daily synchronization of commands) . It's easy to keep abreast of everything when you are only three people. Now we are much more. Sometimes we encounter such a problem: teams worked in parallel on one product, but did not know what each one does. As a result, conflicts arose, rewriting someone else's code, etc. When some do, while others throw, the development process may slip. At DevForum, we also focus on the technical synchronization of teams and are struggling with disunity.
- Tool for change . You can come here and change the course of history. Here you need to tell by example.
Example. Let's say we have Oleg. He sits in the infrastructure and does the Autonomy project with the guys. When the project starts at its full potential, the life of simple developers will become easier. They will stop pulling the infrastructure and will do everything themselves. You do everything yourself, you donāt depend on anyone, fine.
Oleg is ready to make changes in the company. But he knows that simply writing about the changes made to Slack is not enough. It is necessary to tell in public, explain, answer questions, write an article, conduct a series of actions, otherwise nothing will change. Oleg comes to DevForum and uses it as a tool for change.
- Workout before the performance . Here you can practice before a big performance. Again, take Oleg as an example.
An example . Oleg wants to speak at large conferences. He needs honor, fame and thousands of views on Youtube.
He comes to us and honestly talks about his ambitious goals. We, in turn, provide him with a platform for a (practically) painless training. If necessary, we help, prompt, guide.
The threshold for entering DevForum (unlike a mitap or conference) is minimal. Oleg needs to prepare a topic, prepare slides for half an hour and come at the right time. This is a great place for a trial rehearsal. Training on cats, i.e. on us. We will give feedback, and go through the slides, and you can check the jokes on us.
After DevForuma, the report can already be thrown on a local mitap. And most likely they will take him.
A bit retro: how DevForum came about
Where did this format come from? Korotenechko. Three years ago, our company made its first attempt to introduce Sprint Review on a regular basis.
It looked like this: everyone gathered in one room, absolutely everything and took turns telling each other who had done what over the past weeks. At that time, there were only 20 of us, but just imagine what it feels like to listen to and look at the code for the business representative, and the developer to look at the pizzeria buildings. We very quickly realized that people listen only to topics that are of interest to them, and on the other topics they are painfully stuck in the phone.
We are faced with the fact that a demonstration of deeply technical to those people who are far from this is such. They came to see how the cash desk starts, and we tell them about the experience of using the Polly framework for implementing retrays between services. We quickly realized that such a format was of little use to people, and Sprint Review, in that form, was bent. At some point, it was simply canceled, and the meeting on the calendar remained.
An initiative group of people thought: itās so cool to show technical things to those who are in the subject. There is a meeting, there are people, there is a desire, there are topics. So we began to gather once a week and continue to do so to this day.
For three years, the format has undergone some changes.
- We began to record our performances. The format itself has been going on for three years, we have records for two years. All of them are stored in one place, if desired, you can review.
- We left the format of the demonstration because we came to the conclusion that the preparation and the demo itself take more time than the format of the presentation.
- We moved on to the presentation format, which is easy to prepare for, giving it literally 40 minutes of time (although here, of course, it depends on the complexity of the topic and the speaker).
- At first, every developer spoke at DevForum. At some point in time, we made the assumption that not each individual person spoke, but a representative from the team.
- Then we went further and stopped pestering with a proposal to speak to those teams for which ānothing is happeningā now.
- Initially, we fit four topics per hour, but came to the conclusion that no matter how interesting the reports were, by the end of the hour only porridge remained in my head. Therefore, now we take one or two topics on DevForum, 25 minutes of a report and 5 minutes for questions.
- Recently, we decided to expand the range of topics a little and sometimes invite external speakers.
We know that our DevForum is not a super unique format, many of our colleagues have tried something similar. But, unfortunately, often such regular meetings do not take root, quickly become obsolete and wither. Our DevForum lives for three years - this is a long time in order to analyze, collect expertise and share with you the experience of creating and maintaining this format.
How to organize DevForum in your company
You will need 6 basic things:
1. Understanding the tasks and formats of DevForum.
More details
To understand whether it is necessary to run DevForum at home, you can consult the tasks that this format solves in our Dodo. These are the tasks of communication, training and self-realization of programmers. DevForum is a flexible mechanism and can, at one time or another, work more to achieve different goals.
There are two verified speech formats that we have developed over three years. You can adopt:
Report : one developer prepares and speaks, while others ask questions.
An example . Once, the topic was āStructural Loggingā, where they talked about serilog, its use in our projects, and how it helps to better work with logs in Kibana. It also addressed the topic of structural logging via NLog and the use of common ILogging interfaces for .NET CORE projects.
After the presentation, there was a session of questions, and all participants understood how easy it was to add this lib to a new project. It took us 30 minutes. For another half an hour we discussed that day logging levels such as Debug, Info, Warn, Error etc., and specifically, what levels describe what situations in the system. At the question session, the problem of noise errors in the logs, especially those related to retrays, was raised. Since DevForum, all new microservice projects use exactly Serilog, and it also appeared in our service template.
Decision-making : there is a problem that somehow affects everyone. People come with possible solutions to dwell on one thing.
An example . We gathered DevForum to discuss Definition of done and wanted to stabilize the quality of the code supplied for production. But how to do this when you have several commands working on a common code at once? The solution was to make common to all Definition of done user stories. The proposed DOD was a controversial point. We got together and discussed whether we needed it or not. A general decision was made. To implement it, we added an item to the checklist in our task tracker (Kaiten) and made it an obligatory item when closing tasks. Some teams then further strengthened DoD by adding their own points that were important to them.
There are two verified speech formats that we have developed over three years. You can adopt:
Report : one developer prepares and speaks, while others ask questions.
An example . Once, the topic was āStructural Loggingā, where they talked about serilog, its use in our projects, and how it helps to better work with logs in Kibana. It also addressed the topic of structural logging via NLog and the use of common ILogging interfaces for .NET CORE projects.
After the presentation, there was a session of questions, and all participants understood how easy it was to add this lib to a new project. It took us 30 minutes. For another half an hour we discussed that day logging levels such as Debug, Info, Warn, Error etc., and specifically, what levels describe what situations in the system. At the question session, the problem of noise errors in the logs, especially those related to retrays, was raised. Since DevForum, all new microservice projects use exactly Serilog, and it also appeared in our service template.
Decision-making : there is a problem that somehow affects everyone. People come with possible solutions to dwell on one thing.
An example . We gathered DevForum to discuss Definition of done and wanted to stabilize the quality of the code supplied for production. But how to do this when you have several commands working on a common code at once? The solution was to make common to all Definition of done user stories. The proposed DOD was a controversial point. We got together and discussed whether we needed it or not. A general decision was made. To implement it, we added an item to the checklist in our task tracker (Kaiten) and made it an obligatory item when closing tasks. Some teams then further strengthened DoD by adding their own points that were important to them.
2. Powerful and charged organizers.
More details
What else must be taken into account is the presence of people who are constantly engaged in the event - the organizers. It is important that they are from developers or people who understand the technical part. They will have to help participants formulate topics, seek out new speakers, and even sometimes maintain a discussion by asking good questions.
In our case, we have 3 organizers from the developers, as well as an actively helping IT brand team.
In our case, we have 3 organizers from the developers, as well as an actively helping IT brand team.
3. Consent from the management of your IT department.
More details
In addition to the goals and organizers, an important component of the success of the event is the lack of opposition from above. This process is a purely grassroots initiative, we can say that enthusiasts do it. Help from management can be beneficial, and opposition will be disastrous. Still, people gather during working hours, use office premises and equipment. This, at a minimum, should not be prohibited.
4. The availability of space and equipment for meetings.
More details
The space can be either a meeting room in the office, or a virtual meeting place, a general call in Skype or Google meet.
We always gather in one meeting room booked āforever at this timeā in the office, but at the same time we broadcast everything in general Google meet, which is also the same and does not change between meetings.
Our negotiation is large, accommodating 20-30 people. There is a projector and a sound output system for remote calling. Everyone knows that on Thursdays from 16:00 to 17:00 DevForum is held in this meeting room.
Due to the fact that we have a partially distributed development, we are sure to bring remote workers to a common call. It also allows speakers to display their screen from their computer, connecting to a general meeting. Speakers can be in the general meeting room or in any other place convenient for them. We will all hear them, and also see their screen.
The designated permanent space makes this meeting more reliable and predictable for participants.
We always gather in one meeting room booked āforever at this timeā in the office, but at the same time we broadcast everything in general Google meet, which is also the same and does not change between meetings.
Our negotiation is large, accommodating 20-30 people. There is a projector and a sound output system for remote calling. Everyone knows that on Thursdays from 16:00 to 17:00 DevForum is held in this meeting room.
Due to the fact that we have a partially distributed development, we are sure to bring remote workers to a common call. It also allows speakers to display their screen from their computer, connecting to a general meeting. Speakers can be in the general meeting room or in any other place convenient for them. We will all hear them, and also see their screen.
The designated permanent space makes this meeting more reliable and predictable for participants.
5. The presence of an audience of listeners.
More details
To gather participants, we have a permanent channel in the #devforum slack, where all developers sit for sure. We even included this channel in the list of required channels in the checklist of the new developer. Plus, novice mentors ensure that they fall into the #devforum channel.
There are announcements of meetings, discussion after, the choice of topics and discussion on topics.
In order for people to participate in the life of the forum, we organize polls, ask speakers to give feedback, and also publish a recording of the meeting the next day in the morning.
It is also important that the event is voluntary and optional. Yes, it is held during working hours, but if someone wants to work or has more important things to do at this time, he may miss.
Post-event publication example:
An example of a discussion after a meeting:
There are announcements of meetings, discussion after, the choice of topics and discussion on topics.
In order for people to participate in the life of the forum, we organize polls, ask speakers to give feedback, and also publish a recording of the meeting the next day in the morning.
It is also important that the event is voluntary and optional. Yes, it is held during working hours, but if someone wants to work or has more important things to do at this time, he may miss.
Post-event publication example:
An example of a discussion after a meeting:
6. The presence of speakers and topics for discussion.
More details
This is the most important and most difficult part of the organization. Here we are faced with problems, both the search for speakers and the availability of topics.
Here is just a short list of activities that organizers do to engage people:
Here is just a short list of activities that organizers do to engage people:
- We look for topics in advance, draw up a performance plan for more than a week. At first, we searched for topics at the beginning of the week, and on Thursday we had to speak.
- We go into the command channels and ask explicitly: are there any topics for DevForum?
- We conduct personal conversations with programmers, encouraging them to perform. We substantiate the value for the speaker to participate: a deeper understanding of the topic, speaking experience, public benefit, material for a future article, conference.
- We throw into the channel topics for discussion that people would be interested to listen to. Knowledgeable developers can respond and act as speakers.
- We respond to socially important events, independently arranging discussions on problematic development topics.
- We watch past conferences with our participants. After attending conferences, there is always something to tell.
- Following the results of conferences that are important for us, which were attended by a lot of people from us, we are organizing a discussion in the format of ā3 best reports from the latest Highload ++ā.
- We invite external speakers.
Something else important
It may seem that everything is simple (or vice versa nothing is clear), so I will list a few more features of the organization that must be taken into account and kept in mind.
Organizers need to work with speakers. We solve the fear of speaking through help in preparing for the speech. Laziness or disorganization is stopped by a request to formulate the topic in advance, even in draft form, and with the exact date of the speech.
Sometimes there are none. There are times when a lot has been found, sometimes when a little. In this case, you canāt categorically cancel the event. We must try to find topics or speak for ourselves. Organizers are also developers, so we also always have something to tell. You can resort to tricks, arranging more free discussions.
Video and sound quality. Itās a purely technical moment, but it is important for people that the sound is good (check the connection and the Internet in advance), and the demonstration of the code on the screen is readable. Even the most interesting topic, filed with technical flaws, can alienate viewers.
We accumulate material. Meetings must be recorded. We have an archive of videos, with presentations and additional materials attached thereto. There are playlists on YouTube. We put all the records in our documentation system, where there is a full-text search and you can find the topic of interest after and get acquainted.
For three years we have accumulated a lot of good content. Therefore, there will be a series of articles written based on speeches at DevForum :
1. Schrodinger cat without box: the problem of consensus in distributed systems.
2. Infrastructure as code. (In progress ...)
3. Generation of Typescript contracts for c # models. (In progress ...)
...
All Articles