Meetings are legalized robbery.

In the development of the whole thing in the works, is not it? This is art, not science. We, developers, solve complex problems, and often our solutions are not at all obvious. We experiment, innovate, investigate and investigate. To do all this, we are talking . We sit together in talks, conferences on Skype or channels in the slug; we discuss our decisions; we ask the opinions of colleagues; we argue about the best ideas. No doubt, meetings are a key component of modern software design ... and this is very sad to see.

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 about that later. Let's first discuss the alternative.
')
Let's say I am 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 the team before making a final decision. So, am I holding a meeting? Not!

Good architect

I ask Jeff, one of our programmers, to create a draft DB schema, but in fact I don’t talk to him about it. I appreciate and respect his time - there is no need to disturb him with this organizational noise, so I simply create a ticket and assign him to Jeff. When he has time, he creates a draft and returns a pull request. I look at it, add a few comments before it updates the branch, and in the end is dead .

Great: we have a draft.

At the end of the document, Jeff also listed assumptions, risks, and questions. For example, this 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?

, , 10 . , . , . , , , .

, . . , , - , , , . : . , . , .

. , . , ; .

- ( ), schema.md.

, - , - . , . , , , , PostgreSQL . — , , .

, ? , ? : - - . !

, .

, , , , — !

. , .

. , : Google Calendar. , -. :

1. : 10 .
2. : 15 .
   
   
   
3. : 15 .
   
   • ?
   
   
4. -: 10 .
5. : 30 .
   
   • PostgreSQL
   
   
6. : 10 .

: , , «». , . , . . , . schema.md .

Git- -, « ». , ?

.

, , , . , , , , , .

30 , . .

, , , - . — , . , , , , .. — , .. , .

, ? , , ? , .

— . , — . , , , , - — — .

— - . «» , , . "" .

, , .. , 2 . , . : , -, , , .

, , . , , . , , , . , .

, . , . — , , , .

, , — , , . -, . , , - - .

, - .

, , . , . , , . , , .

. , , , , , . .

, , . (, CTO, CEO, ) . , , , . .

!

. , .. «» ? - ? , ? , , ? ? , , , ? , . .

, . - , , . , , , .

. , . , , . , , ?

: « ?» — , ; - , ? , , , .

, . , . , - . , .

?

, ? « » , -, ? , , - . ? ; , . ?

. ? . , .

. — , , — . , .