Did you just saw the word "meet" and your brain directly when into the usual rant without understanding at all the message of the sentence? Firstly, I have a n

Did you just saw the word "meet" and your brain directly when into the usual rant without understanding at all the message of the sentence? Firstly, I have a news for you: avoiding interruptions is not something special to developers. It's the case for ALL EMPLOYEES, even the ones that have more contact with people. The complexity of the flow may vary between employees, but it's just ego-inflated bs when devs are painting themselves as such snowflake beautiful minds with their so special workflow. There is a very strange mentality of developers not being able to do what other people in the company are able to manage and they therefore need to invent that they are "special". Secondly, many devs are shit at being able to tell if a meeting is useful or not. I saw very good dev teams, I also saw dev teams where we reduced the amount of meetings and where they started producing useless code that did not do what was needed, while at the same time, some of those devs were saying "see, less meeting, now we deliver twice faster" without even realizing that the useful outputs were twice slower because of all the things that needed to be redone. Unsurprisingly, the number of meetings re-increased and some adults had to supervise the team more closely to make sure they understood what was needed. And of course, some of those devs were complaining, while being totally incapable to even conceived that their twice-faster delivery did not matter if they delivered the wrong output. So, yeah, NO ONE HERE IS PRETENDING THAT WE SHOULD HAVE USELESS MEETINGS. Simply, I'm pretty sure that some meetings that you consider useless are in fact very useful but your "I-just-generate-code-I-don't-need-to-exchange-with-people-to-understand-what-is-needed" mentality makes you unable to notice it. And again, while there is some truth and things to learn behind the "maker schedule interruption problem", a lot of devs complaining about it are just people who are not good at their job because they lack basic skills that are required. I'm a scientist working in R&D for a private company. I'm working with devs, I even sometimes write full modules that end up in production (it should be done by proper devs, but I'm stepping in to fill the gaps). Trust me, I know very well the "maker schedule interruption problem" and it is indeed a tricky balance. But the reality is that I see some devs who are working on things way less complicated than me and having way less meeting than me who are using the "maker schedule interruption problem" to justify that they should not do a part of their job (yes, going to the meeting to align your work with the company needs is YOUR responsibility). I'm doing things that require juggling with complicated things in my mind all the time, and yet I'm able to go to these meetings without much problem. If they cannot, it's not the meeting the problem, it's them unable to manage. When you suffer from the "maker schedule interruption problem", your first reaction should be: "is it because I should learn to work better with interruptions?" followed by "I should try to understand why these meetings exists, in an intellectually honest way", and not "I'm a developer, I'm special, the world revolves around me and if I don't like it, it means it's useless". To come back to the subject: this is yet another good example of the divergence of what software development intrinsically is and what the software developers invent it is. Software development requires interacting with people, software development requires to be good at managing interruption. Somehow, software developers have invented, probably based on TV show clichés and teenager nerd mentality, that software development is just limited to them playing around with code.