3 ms·

Paul Graham explained the software development mind set here: https://paulgraham.com/makersschedule.html https://paulgraham.com/makersschedule.html There is a

Paul Graham explained the software development mind set here: https://paulgraham.com/makersschedule.html https://paulgraham.com/makersschedule.html There is a very significant cost to having a lot of meetings. At some point someone has to take the requirements and turn them into software that does something. And lots of interruptions destroys that process. There are entire methodologies designed around these constraints. That is why "agile" methodologies introduced the Sprint concept, so there's enough time to focus on building something that the stake holders can interact with, and then give actionable feedback. Which doesn't really happen when you only discuss requirements in the abstract. Painters need time to paint uninterrupted. Writers need time to shut the office door and type without distractions. And developers need quality, focused time spent with their text editor. So developers are completely correct in their emphasis in keeping meetings to only those that are truly useful and required, and guarding their focus time. It is what best serves the customers and other stake holders.

cauch 2y ago
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.

cauch 2y ago

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.