Almost all problems are really people problems, and people problems can only be solved by communicating with other people.

Some engineers seem to want to work for long stretches uninterrupted, like monks copying sacred texts. That is not the way to succeed. To succeed you need to make sure what you are building is actually what you should be building. I've never seen a way to figure that out without having meetings with other people.

Think of it this way -- a software engineer is not just a programmer, just as a fireman is not just a "hose operator." You are ultimately someone who gets things done and solves problems for other people, and that requires regular communication with those other people.

This is why "it could've been an email" exists. If you're not making me an active/reactive, valuable contributor, then you're wasting my time and the boss' money.

>That is not the way to succeed.

I mean, seems a lot of people managed to succeed just fine going radio silent for a long time and simply observing their target audience until the last moment. Which does allow for long stretches of work, and rails against the "communication and work need to be heavily intertwined for success!" spiel. Nor does it say meetings are the best way to do this intertwining, even situationally.

>To succeed you need to make sure what you are building is actually what you should be building.

Which does not necessarily conclude that meetings do this.

The whole comment also misses obvious points such as analysis paralysis, death by committee and more.

In my experience, the people who work like this are the sort of people with 5000 unread emails who ignore slack DMs too because they're "too busy".

> I mean, seems a lot of people managed to succeed just fine going radio silent for a long time and simply observing their target audience until the last moment.

This is a local optimization, and only works if the entire team is on board with "keep BlargMcLarg unblocked" at the expense of themselves. As the parent put it, this is a people problem, not a tech problem, and by only dealing with _your_ needs you're ignoring the needs of your team.

> Which does allow for long stretches of work,

This is a time management (and people) problem. Not going to any meetings is likely to result in producers appearing at your desk because they don't know what's going on (because _they_ have 5k emails and you've not spoken to them in a week). It also doesn't solve the long stretches of work problem; time management does.

In my experience, there is absolutely zero correlation between preference for meetings and willingness to communicate asynchronously. To me, this is simply advocating for meetings to force people to communicate and be empathic. This has its own set of problems, as evident by anecdotes in this thread and the many discussions prior.

>This is a local optimization

On the flipside, you assume that the local optimization does not lead into a global optimization, while referring back to the parent's "meetings good" as a global solution. Obviously, giving an anecdote of the other extreme of the curve is just there to show how absurd the notion of "meetings are best" is. There is success on both sides of the curve. I would really like to see empirical evidence of "meetings best", as the trend continues towards "more meetings" (or really just more bureaucracy) without any strong evidence as to why this is beneficial for the entire company.

>As the parent put it, this is a people problem

I agree. More communication != better communication. Synchronous communication != better communication. Just like some books read better with fewer words, so can less communication lead to better communication. Unlike what a lot of pro-meeting people like to believe, the anti-meeting crowd isn't arguing for "no communication" as a whole.

The best line I heard, from a team lead that wouldn't back a "don't implement a task queue using postgresql", was "because I don't understand it/am not familiar with it [the alternative solution, RabbitMQ/whateverelse Q], we're not doing it". Other times it's just silence and, then, in an email or through somebody else "we don't want to do the incorrect solution". Without offering alternatives or what's "incorrect" about them.

These are common scenarios in mega corps. The above couple of anectodes were from one of the largest payment processing company and one of the largest b2b security company.

Oh, and you'll forgive my endless rant, the best one was out of some multi-billion nasdaq blabla company: CTO was absolutely ADAMANT how to implement encryption at rest. Using some tool from his college days. But, that tool wasn't maintained for years and didn't make use of Intel's AES-NI. Even though we explained him about latter, showed him the numbers using simple Linux tools, he kept scheduling meetings "to show us". Needless to say, using Intel's AES-NI was a good approach, compared to software-level encryption. Absolute waste of a couple of weeks.

Pro tip: avoid working working at companies that follow HIPPO (highest paid person’s opinion).

Why do I care if I have no say in it? Why am I wasting an hour or two of my day listening in on this when they could have emailed me the meeting minutes and decisions so I can spend 5 minutes reading through them?

If I'm not actively participating i na meeting, if my views are not taken into account and respected, then it's a pointless meeting for me.

>Some engineers seem to want to work for long stretches uninterrupted, like monks copying sacred texts. That is not the way to succeed.

The reason we want to do this is precisely because we're *not* just copying sacred texts. But rather we're sitting there working with some mental models and concepts, figuring out the chain of API calls and how it all clicks together so that we can better work on the actual problems. Getting up to that point always takes some time. Even getting to the same headspace where I was the previous day when I left work, takes some time.

So if you come to my desk and interrupt me I'm going to have to start from zero again and this will take time. So if I have a meeting coming up in 30 minutes, there's a good chance I won't start anything big. And after the meeting I'm again going to just be going through stuff for 30-60 minutes before I get to the point where I was.

I hate being interrupted because my work is in large parts, inside my own head as opposed to just typing in code. And thinking is often easier when someone is not talking to you.

https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt...

And why wouldn't they? If I can ensure that a machine runs at 120% by giving it the illusion of participation in decisions I would absolutely do this.

/s

Now, to understand the problem to be solved, to agree on a solution being proposed (out of the results of focused work), and to synchronize the progress when multiple people are working on said solution, this does require communication, and meetings are often a good way to do this. They are therefore essential to enabling the long uninterrupted stretches of work to produce great outcomes, but they must not come at the expense of that focused work.

I must dissent.

You are right that many problems look like people problems. But in all honesty, we have no clue how to solve people problems.

Talking can sometimes work, but it's not a panacea. Otherwise parliaments would have solved all problems by now.

A shockingly large amount of time, you can solve people problems by turning them into technical problems, and thus amenable to technical solutions.

To give a silly example: if people keep walking in on you when you are on the loo, a flippable keep-out sign or a simple lock on the door is a much better solution than talking to the intruders.

Less silly: if people keep breaking your build, you might be tempted to say that the solution is to clearly communicate with them to let them know that breaking the build is not OK.

The technical solution is to set up a pre-merge check that makes sure everything compiles and your automated tests succeed.

Guess which of the two approaches works better in practice? Especially when people are under stress to deliver?

(Know, if your co-workers find ways to deliberately bypass the pre-merge checks, _and_ also keep breaking the build; then this should probably be treated as a people probably. Your company should give them a warning once, and then probably fire them on the next offense.)

If all you're doing is sitting around in meetings all day, you won't get any actual work done.

That was never my experience, especially if those meetings were standup meetings as the parent poster was referring. The standup meetings were a lot of feel good so the business could cajole the developers. Any actual coordination that needed to happen was outside those meetings among developers, with the business making their own decisions and dictating from on high.

If you don't think you're needed in a meeting, say so. Give a reason like "I have nothing to add to that discussion." or "There's no agenda so I don't know if I'm needed." or simply "I'm busy, I think my time would be better spent on story 123." Make the people who invite you start to consider if you're really needed[1].

Also, create your own "meetings" by putting blocks of focused coding time in your calendar where you're unavailable to other people.

Part of your job as a dev is to organise your time well. You can't just delegate that to other people. If you're saying yes to every invite, and then you sit and don't have anything to add, then you haven't done your job properly.

[1] They might stop inviting you, and then you'll have less input on things and less visibility to management (which mean you were needed in the meetings after all). Make sure you're happy with that before you try this strategy.

The other meetings are small in number and comparatively more useful per minute.

Yes you can. Just send a note saying why you won't be there and what you'd have said if you had been. Agile ceremony meetings are practically the definition of meetings that could be emails.

If your point is "then put up your resignation", then yes it is available. I am not a serf. That is not however what the "I cant do it" sentence in English refers to.

I hear this from lots of developers. I also hear that none of them have ever raised the problem with their management, or attempted to suggest that they could submit notes instead when they have a lot of other work on, or anything that would reduce the number of meetings they need to attend. Practically all developers just coast along believing that because that's how things are it's impossible to change anything. This is despite the fact that agile includes a retro meeting specifically for raising these things. However, FWIW I wasn't actually suggesting missing all those meetings. Just some of them, when you have other priorities.

I've worked on teams where I've been invited to multiple daily standups and I'd have lost a couple of hours a day if I'd not been willing to push back. In every case I've been listened to and been able to communicate what I've been doing and whether I need any help in other ways instead (usually just by editing the standup notes myself).

Here's a suggestion. One of the key things about agile is that you have to 'process your processes'. If something isn't working for the team then you should iterate on it. At your next retrospective raise the problem - say "We should stop spending N hours a week on standups because it's stopping me finding clear blocks of time to focus on delivery. We should find a way to reduce the number of meetings I have. How about we have them on Monday, Wednesday and Friday, and email our standup updates to the PM on Tuesday and Thursday." If the team agrees that would save you 40% of your standups..

I have. TL;DR: My managers effectively gaslighted me. "You don't understand agile" despite them being incapable of reciting the agile manifesto and not even knowing what does/doesn't belong to Scrum. "Oh but there has to be some communication", despite my argument clearly not being "there should be no communication". "You're not a team player", despite working together just fine outside those windows. It was an experience which effectively achieved nothing while wasting my time and emotional investment.

That's not to mention the obvious: a lot of managers have ulterior motives to keep the status quo.

>Practically all developers just coast along believing that because that's how things are it's impossible to change anything.

For the most part, that echoes my experience with a lot of companies. The majority don't want change. The majority don't have the power to change things alone. A lot of people don't know any better, and are afraid of the unknown. They have a positive experience with "Agile/SCRUM" because it's marginally better than what they had, even though they can't pinpoint exactly what attributes to their improved situation, leading to pointing the entire package as a big plus.

This really shouldn't come as a surprise either. You can introduce retrospectives and whatever; most companies are still top-down hierarchies at heart. The majority of people learn from a young age not to rile things up, and the IT crowd is definitely not known for being rebellious towards those in power. The entire thing points towards waiting for some people in power to try something different, or for individuals to try their own luck at entrepreneurship.

NB: I don't fault people for liking this or wanting this. The bigger problem is how quickly the far majority of companies force feed the entire development team this way of working, leaving almost no place for the people who don't want to work this way. If you don't like it, good luck finding something that isn't highly Agile/SCRUM/meeting-oriented or at risk of becoming that in the near future. It's the same thing with remote work, asynchronous work, non-standard work hours, you name it. It's the incessant need for a one-size-fits-all approach which to this day is questionable at best.

It might be true in many settings, but I'd see that as a toxic and hostile environment we shouldn't be accepting as normal. Some people will sure enjoy Fight Club kind of places, I still wouldn't assume they are "a very simple fix" to shitty companies.

Quitting for a better workplace looks to me like a better course of action if the opportunity presents itself.

No one automatically just knows when people are unhappy with a process if they don't talk about it. There are lots of people who think agile ceremonies are a good thing, and they think they work, and in a lot of cases they do work. People don't question that if they don't need to. Consequently, if you're unhappy with it, you need to say something.

"Quit for a better workplace" doesn't work for minor things because every workplace will have something that you don't like. You'll never be able to find the perfect role. You have to find somewhere that's mostly good, and then change it to be better. If you can't then you should move on.

If you’re in need for tricks and tough love to get away from meeting hell, it’s already beyond “talking about it”, and beyond minor annoyances IMO. And sure it must happen because other people believe it’s a good, or at least a necessary thing. Working with people that value your time isn’t as exotic or rare as we make it sound, and it often will be enforced through the whole org to avoid having each one fight on their own.

Agreed. when I started in the 90s I often got several months of focused work without many interruptions. Nowadays you have to attend meetings and always have somebody breathe down your neck. Hard to accomplish anything that requires experimentation over months until it works.

I did that too. Quite often the project failed after those months because we'd built the wrong thing, or the landscape had changed, or the customer had failed to spec what they needed well enough. This was the "Waterfall" methodology, and Agile, with all its meetings, is specifically designed to fix that problem.

Besides, why can't we be lower case agile, and avoid all these meetings anyway? I write very detailed PRs with high level summaries, screenshots and videos, explanation of risks and trade offs, and deeper technical dives. Everything you need to know about what I'm working on is literally right there. I push up code early and often, it's not like I just want to sit in an isolated cave for 6 months and then emerge with a finished product.

My first job with daily standups was 2008 or so, and I just realized I left less than a year after they were implemented.

In short, I probably had less meetings in my first ten years in software than I did last quarter.

That said, the industry matured so much that experimentation that fold up as planned are generally doomed by large structural issue in the approach. 20 years ago, tweaking and digging your way in trench was the expected path since having to work around implementation details and bugs happened whatever you wanted to get done.

Am I really in such a small minority, or has HN turned into an echo chamber on this issue, where no one with a countervailing opinion dares to get a word in?

Having a meeting interrupt my work ranges from slightly irritating (if it comes during flow, but I can always easily get back into the groove later) to a welcome break from the intellectual stress of solo development work. I get to interact with my colleagues, learn about what they've been doing, and understand more about what the team needs and what our customers need.

Have I forgotten that I sold my soul to the devil to obtain a unique ability to focus, and regain focus after interruption? Or are there a double digit percentage of HN inhabitants who are just like me but not speaking up in this thread?

I don't know how I would understand my team mates as people, understand what they need from me and understand what other parts of the business need from me without meetings. Am I missing something here?

This sounds overly dramatic considering most people are very different in a meeting setup. We didn't need meetings to do this for the majority of our species' existence. Just talk with them, basic empathy.

The way it sounds, you like some meetings because they fulfill X, but X can also be fulfilled in different ways without the downsides of meetings, be it specific meetings or in general. It's those downsides and knowing X can still be satisfied that drives many of us against meetings. Many times, meetings are also subpar or flat-out fail to achieve X because of other circumstances.

The problem I have with them in practice is that they are usually (in my experience) turned into a management progress meeting where developers are made to answer for their progress on specific items, rather a round-robin "Here's what I'm doing". At that point collaboration and team communication is out of the window.

It's a self-selecting sample effect. No one responds to a survey when things are just ok.

I recently started a new job where we have weekly recurring "standups" with clients. Most of the gaps between meetings are an hour with a few 1 1/2 hour gaps throughout the week. After the 3rd day I asked my boss "with all these recurring meetings when an I suppose to actually get my work done"?

"haha, yeah it's ridiculous, right?"

IME it's sadly common for an organisation to have a Problem, for everyone to acknowledge there is a Problem, for someone to even come up with a roadmap to solve the Problem...and yet nothing will change because there is some ineffable disconnect between knowing and doing.

Really it seems to come down something like "well, if we're going to go to all the effort to change something, we better do it right. If you can't prove the change you're going to make is going to solve this issue perfectly forever it's better to leave it as it is right now. rather than waste all that effort"

or, "good idea, let's add a weekly meeting to monitor fixing this issue"

At one company, we started having daily "show and tell" meetings at the end of every day in addition to daily morning standups. I said during a retro that these were causing extra stress for the team, and felt unnecessary.

The team lead responded to that by making them 15 minutes longer, because he claimed the stress was just coming from team members not having enough time for their demos.

I kid you not.

p.s.: "I have an idea as to how we could streamline our processes!"

It might not be an ideal schedule for everyone but I have almost 4 uninterrupted hours in the morning and I naturally wake up early so it works for me.

The only reason I'm not there anymore is that the team disintegrated after a change in leadership. Despite that being years ago, our tooling survived, judging from some headers.

If you glue things together, you inevitably have unknowns about the specifics of how your software actually works, and that very often comes back to bite you. But it's even worse if you do platform engineering, because developers downstream from you will find features (or anti-features) you didn't notice and completely derail and guardrails you had envisioned.

Having full control over everything we wrote kept us nimble and able to react fast. If you own all your code, making small adjustments is easy. If you glue together packages or off the shelf code you may end up having to choose between a trade off and maintaining a fork of a piece of code far beyond the scope of the thing you need. The only pain we had left was keeping in step with kubernetes API packages.

I think it would be a "2020 remote work" style revelation for many teams. Many teams thought remote work would never work out for them, but when they were forced to do it, they found it actually worked great.

That being said, I doubt many companies would ever find the idea tractable. So we should start with something simpler: you should never schedule more than 2 hours worth of meetings for your developers in any given week. And those 2 hours should be very carefully considered, such that they don't segment their day.

The amount of wasted productivity that comes from endless meetings is staggering. Not to mention the mental health hit of trying to do challenging knowledge work while having your day constantly interrupted.

No, you don't need a weekly project update meeting. I can send you something out of Jira and if there is an issue, you can post a reply to it, or email me. And I can spend time thinking about what you've written and write a careful reply. Only when that still doesn't work, do we do a synchronous meeting, at which point we cover only the points of contention, and with as few people as necessary.

The other beauty of tools like Jira is that the conversation is preserved. Why did we approach the problem that way? Well, go look at it. You'll have someone asking why we can't do a thing and a reply pointing out the problems of that and hence why we have to do it this way. You don't get all of that from the email of the meeting.

I wish this is how it worked IME. IME "documentation" or rather a document would need to be created explaining the decision. No one reads the documents anyways! Referring to the ultimate source of truth, the conversation, preserves EVERYTHING that went into it. "But I don't want all the details so please create a document." You want a document? You know what you want in it? Why don't you go and write it? Seems no one can be bothered to research and read anymore. /End rant

For whatever reason, my team generally likes having scheduled times to discuss certain topics. I always give them optionality on the meeting however (i.e. we regularly review if a given meeting is causing more pain than it's solving)

My meetings all get scattered throughout the week haphazardly such that getting even a few hours of dedicated work done is almost impossible on many days.

I agree. Core issue now seem to be that no one ever thinks much about project/module/library as a whole.

While I have not been developing anything much lately, I realized that most of my career making things ended up being. In part because of this, I found the passion to start digging through again stuff I wanted to learn but never had a project for, basically now a deep dive into system programming. At the moment, I'll probably only gain insight, but it feels more gratifying than learning how to glue packages together.

Programmers do talk about stuff informally anyway if and when the need arises, often via asynchronous messaging or even face-to-face but those aren't meetings in the sense that they adapt to the programmer flow and not the other way around.

I don't agree there. Constant communication is important for a good team, however in constant flow it often is being lost, what is important. Important things easily get lost between other noise.

Whether a daily is the right approach can be argued. Maybe a weekly is enough. However having a time where everybody listens and things can be brought to attention is useful in my experience.

But that, planned, too frequent, mandatory, with a prescriptive format, meetings (which dailies/weeklies are) is harmful.

I've been 21 years in this industry, the past 7 in Scrum/Agile infested companies/teams and I've never seen such a sterile and unproductive way of work.

I also agree that it isn't as important as they make it out to be.

I agree that a high quality team communicates with each other often and status amongst them should not be necessary, or require a daily scheduled time.

What's wrong with an email?

How do people deal with this? I'm expected to take on more and more meetings and my time to do deep work diminishes as I go on. I'm curious to learn more from people who are handling this well.

If it's a meeting-heavy day just resign yourself to the fact that you're not going to get anything done that day. So basically, you have to plan your sprints to be two days shorter than they actually are (or whatever, depending on your company's meeting schedule).

Adjust all your estimates accordingly. A 3 hour task will take all day when you factor in interruptions, meetings, and meeting fatigue, so estimate 8 hours for it.

Sigh heavily, and remind yourself that you couldn't possibly get more than 3 days work done in two weeks, under the circumstances. So what little you did is actually pretty good.

Working as an IC I just don't accept invites and don't attend. With the following exceptions:

- Weekly review/Agile flavour meetings with my team

- Meeting with a team member to solve a specific issue

- A manager/VP/CTO _explicitly_ makes it clear _my_ presence is required

Perhaps I've been luck with my managers or perhaps it comes with seniority but I've never got any negative feedback on this. Most people invite you in for stuff just as a passive listener.

When I'm doing contract work I make it clear I am available for milestone review meetings and everything else is surcharged billable hours.

"I have nothing to contribute to this, so I see no value in attending this meeting."

"I see that point 3 on the agenda is relevant to me, can you bring me into the meeting at that point"?

These are professional answers. You are telling whoever has invited you that you think your time is better spent, on behalf of the company, doing something else. If they then insist despite your protests, you have to accept it. Although you might at some point realise that the person you are working for is an idiot.

This to me sounds like you are equally disrespectful of other people times as you complain that they are about yours.

What having them "bring you into the meeting at that point" means is that now everyone else has to wait the 5 minutes it takes the host to message you, wait for your arrival and then go over why they brought you in (for your benefit, and maybe everyone else's), instead of just going on with the point. I would be bothered if this would happen in one of my meetings. What you're basically saying is that your 30 minutes saved of the meeting are more important than the 5 minutes it loses for everyone else.