March 28, 2019 at 20:22Meetings are legal robbery
- Transfer
It's all about creativity in development, isn't it? This is art, not science. We, developers, solve complex problems, and often our solutions are not at all obvious. We experiment, innovate, research and investigate. To do all this, we talk . We sit together in chat rooms, conferences on Skype or channels in slack; we discuss our decisions; we ask colleagues for opinions; we argue about the best ideas. Without a doubt, meetings are a key component of modern software design ... and it's very sad to watch.
A good architect , like a good PM , does not need meetings and never organizes them.
Meetings demotivate, waste time, burn money and degrade quality. But more on this later. Let's discuss the alternative first.
Let's say I'm an architect who needs to design a relational database schema in a new project, I have a team of five programmers, and I want them to help me with the design. This is a very logical and adequate desire, because a good architect always discusses all possible options with a team before making a final decision. So, am I gathering a meeting? Not!
I ask Jeff, one of our programmers, to create a draft of the database schema, but in fact I'm not talking to him about it. I appreciate and respect his time - there is no need to bother him with this organizational noise, so I just create a ticket and assign it to Jeff. When he has time, he creates a draft and returns the pool request. I look through it, add a few comments before it updates the branch, and eventually freeze .
Excellent: we have a draft.
At the end of the document, Jeff also listed assumptions, risks, and questions. For example, here is what I got from him (this is Markdown, a very convenient format for simple technical documents; I highly recommend it):
I don’t know how much time Jeff spent on this document, but I just created it in 10 minutes. Of course, this is a very simple scheme for a very simple project. But even if Jeff spent an hour on it, every minute of that hour is good for the project. I mean, every dollar that I paid Jeff during this time has returned to me as a text document.
Now I have a draft, and I'm taking the next step. I ask Monica to look at him and suggest changes. Again, this is another hour, and I get a pool request with changes, corrections, new assumptions, risks and questions. I do not speak with Monica: there is no need. She has all the information she needs to work with the database schema. She is a good engineer, and I trust her ability to formulate her opinion in writing.
There is no need to sit together in the same room or stand in front of the board. Monica is smart enough to do her job on her own. She already has all the ideas that Jeff expressed; she doesn't need to talk to him.
As soon as I drew in her pool request (after proper review and corrections), I have a new version of the document
Moreover, I have a git story of this document, as well as a history of pool requests with comments. This is much better than taking notes during a meeting or even a video of a meeting. Anyone who later joins the project will be able to understand how we came to the conclusion that we need to use PostgreSQL and store money without cents. All this is there, in the history of the gita and tickets on the github, forever with us.
What if I need more opinions? Or if I'm still not sure if the circuitry is good enough? No problem: I ask someone else to review it again and send me a pool request with changes. I can even ask Jeff to do it again after several iterations with other programmers!
Moreover, I can add my own questions to the document and at the next iteration ask Jeff to pay attention to them and make decisions on them.
The more we pass the document around, the better it becomes, and every minute the project pays for it turns into a tangible product - a document with a history of changes!
This is how a professional architect gathers opinions and makes difficult decisions. Now let's see what a bad architect would do.
First, I am gathering a meeting. No, hey: I'm planning it on Google Calendar. No, wait, wait. First of all, I draw up the agenda: I’m sure: you understand what I’m talking about, and you saw such summons from your “architects”. However, my first step has been taken. I planned a one and a half hour meeting, which will be attended by all programmers. We will have fun and drink coffee. We will discuss the problem, listen to all opinions and find the best solution. We will document it in and return to our tasks. Instead of transmitting these dry and boring Git documents, we will have real human communication with a pleasant coffee break, on which we will exchange opinions on the latest series of The Big Bang Theories. After all, isn't that what we all love in our
office work ?
I do not think so.
I believe that meetings demotivate, waste time, burn money and degrade quality. Those who organize them either do not imagine what they are doing or quietly rob the company they work for.
We needed meetings 30 years ago when we did not have laptops and a github. But even then we had a pen and paper.
I am talking about meetings designed to collect or disseminate information, discuss or propose something, or find a solution in the technical field. The only good reason to meet is to read body languagethe people you deal with. Politicians, businessmen, poker players, psychiatrists, therapists, etc. - they need meetings, because they should read our bodies, not just thoughts.
Do we really care about Monica's body when we design the database schema? Well, when how, right? But seriously, we are not paid for it.
The best motivation for a creative person is to see the result of their creativity. If I am not mistaken, enjoying the creative process without any results is an obvious sign of a mental illness. A healthy creative person, such as a software developer, for example, wants to see how his efforts turn into something valuable and - ideally - tangible .
Meetings never produce anything tangible and rarely produce anything of value. Sometimes we have “minutes” of meetings, but they are just small pieces of paper with a brief summary of what we talked about. Not a real " product " for a creative person.
Thus, they demotivate me, because I just don’t see what 2 hours have turned intoof my life. In fact, we are not creating anything , we are just discussing . Please note: I am talking about meetings, not about working together on something, such as in pair programming.
You can say that some meetings do lead to great ideas that are tangible results. You can say that these ideas could arise only with direct contact, face to face. You can also say that many brilliant technical solutions were invented precisely thanks to the magical synergy of friends thinking in the same direction, at the same time and in the same room. This argument makes sense, but I will return to it later.
I think this is obvious. The first few minutes of the meeting, you are focused, then you start to watch your feed on Twitter and draw scribbles. Everyone does the same thing - not because we are lazy , but because there is no need to fully focus on the meeting.
While Monica is working with the document, adding comments and suggestions, she is completely focused on the result - mainly because there is no one else to help her . She must provide this pool request, and I am waiting for her. Her concentration is as high as it would be at a meeting when someone would ask her directly about something and she would have to give a detailed answer.
Her time is optimized to get the appropriate result, while others do something else.
At the meeting, on the other hand, we are, at best, not very concentrated. And the longer the meeting, the slower we are. In addition, the more people there, the less we are interested and the more interesting our updates on Facebook become for us. I think this is not surprising for you if you have been at least a few months in the development industry.
This is closely related to the previous conclusion. Meetings are among the largest consumers of the budget of any type of activity on the project simply because everyone who sits in that room or in that conference on Skype is paid, while they produce almost the same result as one person can produce. Or much smaller.
Although this may sound radical, I must say that I consider the meetings a legitimate way to rob a project. Most meeting organizers (architects, CTOs, CEOs, programmers) do not understand this. They believe that the more they talk, the better they are engineers. And their superiors mistakenly appreciate this type of activity in their subordinates.
This is a robbery!
I told you to sketch the DB schema. So you come to me and ask to arrange a meeting, because are some “aspects” incomprehensible? Have you studied software development anywhere? Do you know how to work with technical documents? Are you able to write in such a way that anyone can understand and answer you, also in writing? Not? And now you want the project to pay you not only for a sketch of the database schema, but also for talking with you and a few other guys for sitting next to us and chatting with their friends? Essentially, you want to rob the project owner. No more, no less.
Quality improves when it is controlled . When someone tells me every day that my code is full of errors and needs improvement, my quality improves. When nobody cares what I do and how good my results are, my quality drops no matter how self-motivated I am.
The meeting encouraged the group to achieve and discourages the individual. At the end of the meeting, it is often not clear who exactly proposed the good idea and who made the most effort. In other words, at the end of the meeting, I do not know how good I am. Am I the same as I was a month ago, or is it already better as an engineer?
They smile more and ask me: “What do you think?” - more often than last summer; it should mean something, right? I am sure you understand that this is not the kind of feedback that a serious engineer would expect.
A serious developer wants to produce tangible results and get tangible feedback, like money or code reviews . I want to know what is wrong in my outline of the DB schema and what I missed. And I want this to be documented somewhere. This makes me better, and this is how I learn and grow .
So, what about true creativity and notorious moments of insight? Sometimes it is necessary to “think out loud” in order to come up with something, right? We all know how important it is to communicate face-to-face when we research or develop something new. Where would we be without meetings? We cannot just work with documents; we need to talk to each other in order to express our ideas. Isn't that obvious?
I have only one argument about this. Did Einstein come up with his theory at a meeting with colleagues? I do not think so. And he solved much used on greater problem than the design of the database schema.
Let me summarize. Meetings are activities that require virtually no skills, while documenting ideas with text and diagrams is a lot more difficult. Therefore, train and force yourself to work with documents, and let the juniors enjoy their meetings.
A good architect , like a good PM , does not need meetings and never organizes them.
Meetings demotivate, waste time, burn money and degrade quality. But more on this later. Let's discuss the alternative first.
Let's say I'm an architect who needs to design a relational database schema in a new project, I have a team of five programmers, and I want them to help me with the design. This is a very logical and adequate desire, because a good architect always discusses all possible options with a team before making a final decision. So, am I gathering a meeting? Not!
Good architect
I ask Jeff, one of our programmers, to create a draft of the database schema, but in fact I'm not talking to him about it. I appreciate and respect his time - there is no need to bother him with this organizational noise, so I just create a ticket and assign it to Jeff. When he has time, he creates a draft and returns the pool request. I look through it, add a few comments before it updates the branch, and eventually freeze .
Excellent: we have a draft.
At the end of the document, Jeff also listed assumptions, risks, and questions. For example, here is what I got from him (this is Markdown, a very convenient format for simple technical documents; I highly recommend it):
## Tables
user (id INT, name VARCHAR, email VARCHAR);
payment (id INT, date DATETIME, amount INT);
order (id INT, details VARCHAR, user_id INT FK(user));
## Assumptions
- All payments will be in whole dollars, no cents.
- All users will have only one email.
- There will be no search feature required.
## Risks
- Order details may not fit into VARCHAR.
- Foreign keys may not be supported in the DBMS.
## Concerns
- Would NoSQL be more suitable?
- What is the DB server we'll use?
I don’t know how much time Jeff spent on this document, but I just created it in 10 minutes. Of course, this is a very simple scheme for a very simple project. But even if Jeff spent an hour on it, every minute of that hour is good for the project. I mean, every dollar that I paid Jeff during this time has returned to me as a text document.
Now I have a draft, and I'm taking the next step. I ask Monica to look at him and suggest changes. Again, this is another hour, and I get a pool request with changes, corrections, new assumptions, risks and questions. I do not speak with Monica: there is no need. She has all the information she needs to work with the database schema. She is a good engineer, and I trust her ability to formulate her opinion in writing.
There is no need to sit together in the same room or stand in front of the board. Monica is smart enough to do her job on her own. She already has all the ideas that Jeff expressed; she doesn't need to talk to him.
As soon as I drew in her pool request (after proper review and corrections), I have a new version of the document
schema.md. Moreover, I have a git story of this document, as well as a history of pool requests with comments. This is much better than taking notes during a meeting or even a video of a meeting. Anyone who later joins the project will be able to understand how we came to the conclusion that we need to use PostgreSQL and store money without cents. All this is there, in the history of the gita and tickets on the github, forever with us.
What if I need more opinions? Or if I'm still not sure if the circuitry is good enough? No problem: I ask someone else to review it again and send me a pool request with changes. I can even ask Jeff to do it again after several iterations with other programmers!
Moreover, I can add my own questions to the document and at the next iteration ask Jeff to pay attention to them and make decisions on them.
The more we pass the document around, the better it becomes, and every minute the project pays for it turns into a tangible product - a document with a history of changes!
This is how a professional architect gathers opinions and makes difficult decisions. Now let's see what a bad architect would do.
Bad architect
First, I am gathering a meeting. No, hey: I'm planning it on Google Calendar. No, wait, wait. First of all, I draw up the agenda: I’m sure: you understand what I’m talking about, and you saw such summons from your “architects”. However, my first step has been taken. I planned a one and a half hour meeting, which will be attended by all programmers. We will have fun and drink coffee. We will discuss the problem, listen to all opinions and find the best solution. We will document it in and return to our tasks. Instead of transmitting these dry and boring Git documents, we will have real human communication with a pleasant coffee break, on which we will exchange opinions on the latest series of The Big Bang Theories. After all, isn't that what we all love in our
- Введение: 10 мин.
- Проблема: 15 мин.
- Нам нужна схема БД
- Давайте выберем сервер
- Мнения: 15 мин.
- У Джеффа и Моники есть опыт
- Остальные?
- Кофе-брейк: 10 мин.
- Обсуждение: 30 мин.
- Не будем забывать о рисках
- Спросить Джо про PostgreSQL
- Завершение: 10 мин.
schema.mdoffice work ?
I do not think so.
I believe that meetings demotivate, waste time, burn money and degrade quality. Those who organize them either do not imagine what they are doing or quietly rob the company they work for.
We needed meetings 30 years ago when we did not have laptops and a github. But even then we had a pen and paper.
I am talking about meetings designed to collect or disseminate information, discuss or propose something, or find a solution in the technical field. The only good reason to meet is to read body languagethe people you deal with. Politicians, businessmen, poker players, psychiatrists, therapists, etc. - they need meetings, because they should read our bodies, not just thoughts.
Do we really care about Monica's body when we design the database schema? Well, when how, right? But seriously, we are not paid for it.
Meetings Demotivate
The best motivation for a creative person is to see the result of their creativity. If I am not mistaken, enjoying the creative process without any results is an obvious sign of a mental illness. A healthy creative person, such as a software developer, for example, wants to see how his efforts turn into something valuable and - ideally - tangible .
Meetings never produce anything tangible and rarely produce anything of value. Sometimes we have “minutes” of meetings, but they are just small pieces of paper with a brief summary of what we talked about. Not a real " product " for a creative person.
Thus, they demotivate me, because I just don’t see what 2 hours have turned intoof my life. In fact, we are not creating anything , we are just discussing . Please note: I am talking about meetings, not about working together on something, such as in pair programming.
You can say that some meetings do lead to great ideas that are tangible results. You can say that these ideas could arise only with direct contact, face to face. You can also say that many brilliant technical solutions were invented precisely thanks to the magical synergy of friends thinking in the same direction, at the same time and in the same room. This argument makes sense, but I will return to it later.
Meetings are wasting time
I think this is obvious. The first few minutes of the meeting, you are focused, then you start to watch your feed on Twitter and draw scribbles. Everyone does the same thing - not because we are lazy , but because there is no need to fully focus on the meeting.
While Monica is working with the document, adding comments and suggestions, she is completely focused on the result - mainly because there is no one else to help her . She must provide this pool request, and I am waiting for her. Her concentration is as high as it would be at a meeting when someone would ask her directly about something and she would have to give a detailed answer.
Her time is optimized to get the appropriate result, while others do something else.
At the meeting, on the other hand, we are, at best, not very concentrated. And the longer the meeting, the slower we are. In addition, the more people there, the less we are interested and the more interesting our updates on Facebook become for us. I think this is not surprising for you if you have been at least a few months in the development industry.
Meetings burn money
This is closely related to the previous conclusion. Meetings are among the largest consumers of the budget of any type of activity on the project simply because everyone who sits in that room or in that conference on Skype is paid, while they produce almost the same result as one person can produce. Or much smaller.
Although this may sound radical, I must say that I consider the meetings a legitimate way to rob a project. Most meeting organizers (architects, CTOs, CEOs, programmers) do not understand this. They believe that the more they talk, the better they are engineers. And their superiors mistakenly appreciate this type of activity in their subordinates.
This is a robbery!
I told you to sketch the DB schema. So you come to me and ask to arrange a meeting, because are some “aspects” incomprehensible? Have you studied software development anywhere? Do you know how to work with technical documents? Are you able to write in such a way that anyone can understand and answer you, also in writing? Not? And now you want the project to pay you not only for a sketch of the database schema, but also for talking with you and a few other guys for sitting next to us and chatting with their friends? Essentially, you want to rob the project owner. No more, no less.
Meetings degrade quality
Quality improves when it is controlled . When someone tells me every day that my code is full of errors and needs improvement, my quality improves. When nobody cares what I do and how good my results are, my quality drops no matter how self-motivated I am.
The meeting encouraged the group to achieve and discourages the individual. At the end of the meeting, it is often not clear who exactly proposed the good idea and who made the most effort. In other words, at the end of the meeting, I do not know how good I am. Am I the same as I was a month ago, or is it already better as an engineer?
They smile more and ask me: “What do you think?” - more often than last summer; it should mean something, right? I am sure you understand that this is not the kind of feedback that a serious engineer would expect.
A serious developer wants to produce tangible results and get tangible feedback, like money or code reviews . I want to know what is wrong in my outline of the DB schema and what I missed. And I want this to be documented somewhere. This makes me better, and this is how I learn and grow .
How about moments of insight?
So, what about true creativity and notorious moments of insight? Sometimes it is necessary to “think out loud” in order to come up with something, right? We all know how important it is to communicate face-to-face when we research or develop something new. Where would we be without meetings? We cannot just work with documents; we need to talk to each other in order to express our ideas. Isn't that obvious?
I have only one argument about this. Did Einstein come up with his theory at a meeting with colleagues? I do not think so. And he solved much used on greater problem than the design of the database schema.
Let me summarize. Meetings are activities that require virtually no skills, while documenting ideas with text and diagrams is a lot more difficult. Therefore, train and force yourself to work with documents, and let the juniors enjoy their meetings.