Hacker News Reader

Comment by ipaddr | Hacker News Reader

As someone who has been in the industry for 20+ years I've noticed changes that may have lead to this point.

Daily standups, meetings, gluing frameworks

Daily standups are is a one size solution to a communication problem. Daily standups shouldn't be necessary with a team constantly communicating. Daily standups leads to cutting projects into small daily tasks. This leads to a system of micromanagement and it doesn't provide an opportunity of non-verbal self reflection and focuses you into threadmill small task thinking never connecting with the project as a whole.

Developers are expected to attend meetings more than ever. The focus required to deep dive into complex issues get's broken with meetings that developers shouldn't be attending. You can attend meetings or you program rarely can you do both effectively on the same day and rarely can you get the focus you once had.

No one wants to reinvent the wheel so gluing together packages is considered best practice. The work has become more about making decisions around the packages you choose rather than being given time to make the package.

Top pay with top companies seem to lead to burnout, lost purpose and this unhappiness. There is something unhealthy when companies get too large, force employees into promotions or unemployment, have an avg employment of under a year or designs interview processes around finding people who optimize for a high paycheck over those with a long history of experience.

View on HN

Being in meetings means you get to be in the room when decisions are made. Even if you aren't an active participant, you get to at least listen in.

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.

True… but I can’t have 5h of meetings a day and be expected to produce much…

Yes you can, if you take into account the impact of what it is you produce.

I think the idea of deep work has a place too. I haven't read the book but I think it touch's Linus locking himself away at a critical point in Linux's development. Bill gates did something similar (not sure what he was working on at that time).

I think he did that when he created git?

Yeah maybe it was that not sure!

But how many meetings are enough? Each week, I have eight meetings only with my team (that is, aside from other company meetings). And us mere developers are not invited to the design meetings. No, work is handed out piecemeal to each developer by our team leader, and we're only expected to work on our pieces, bug reports be damned! (they have to go through him first)

Decisions made in meetings? 9 out of 10 decisions are made far away from meetings. Meetings are there to tell people about a decision.

Or to make people believe they had actual input and ensure a stronger commitment that way. Because a team that committed to something is more likely to see it through. Even if it means unpaid overtime and all the other crap management uses to extract the highest possible return out of us working drones.

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.

Have yet to meet a company where a developer's opinion is taken into account in software architecture and solution design. And, usually, like some other guy here said, they aren't invited to these types of meetings, at all.

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.

Why do you care ? If top monkey want to spend money on stupid shit, I'll happily indulge it. It is not my money that is badly spent anyway.

I envy you if you can go through your whole career like that.

But perhaps there is a middle way. Many of us care too much, and each subsequent difficult - or bad - decision drives us deeper into burnout. It's not healthy. In which case GP's attitude is the right one.

To extend further perhaps it is only useful to care as far as your influence, motivation, and energy reach. And perhaps the happiest of us at all levels of the ladder are the ones who understand their capabilities and match their care accordingly.

I have yet to work at a company where the developer’s wasn’t the primary opinion that mattered.

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

> 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.

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

>Even if you aren't an active participant, you get to at least listen in.

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.

> 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.

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

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.

>Being in meetings means you get to be in the room when decisions are made. Even if you aren't an active participant, you get to at least listen in.

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...

Focused work is essential to quality results in programming. I guarantee you that whatever piece of software you hold most dear as an example of how software should be made, the key parts of it were written in long uninterrupted stretches of work. Thinking up good solutions similarly is a focused work activity, and meetings are almost entirely unsuited to thinking of great solutions that cover all the edge cases (although they can be ok for thinking of good enough solutions).

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.

You wouldn't interrupt a fireman that is on active duty in a mission, though. "Stop extinguishing that fire, put down the hose and have a random meeting with me who is not directly involved in the actual process".

You might if the fireman is pointing the hose at the wrong house, or a larger fire has broken out and you need to figure out whether he should change what he’s doing.

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

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.)

>Being in meetings means you get to be in the room when decisions are made.

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.

There's a very simple fix if you believe you have too many meetings - decline them.

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.

I cant refuse to go to planning meetings, standups and retrospective. Those are core of agile and already take massive massive amount of time. Some of their parts are useful, but they also contain hours of nothingness.

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

I cant refuse to go to planning meetings, standups and retrospective.

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.

Sight. I cant refuse agile ceremony while working employment in that company. I can leave the job for non-agile one or make myself fired. However, the combination of "being in one of those majorities of companies that believes in agile" and "not being in these meetings" is not available.

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.

It would be interesting to try it, if you had another job lined up.

However, the combination of "being in one of those majorities of companies that believes in agile" and "not being in these meetings" is not available.

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 also hear that none of them have ever raised the problem with their management

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.

That can require some standing within the organization and mental fortitude. Absence can be interpreted as a failing, important information can be droppend throughout long meetings, people expect you to be around to answer questions that come up.

Your point sounds to me like: "It's your fault if you're miserable. It's up to you to confront your peers and fight your organization to protect your sanity "

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.

Your point sounds to me like: "It's your fault if you're miserable. It's up to you to confront your peers and fight your organization to protect your sanity"

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.

There’s to me a decent gap between discussing processes, voicing opinions, and straight declining meetings and making yourself unavailable.

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.

"Developers are expected to attend meetings more than ever. The focus required to deep dive into complex issues get's broken with meetings that developers shouldn't be attending. You can attend meetings or you program rarely can you do both effectively on the same day and rarely can you get the focus you once had."

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.

God, the thought of being treated like a skilled professional and trusted to actually do your job, rather than a code monkey who has to report their progress every single day on how many of the endless "user stories" they got done the previous day...

I also started I the 90s and now that you mention it I don’t think I had any meetings at my first job at a small software company. And even after we were acquired I still think we had at most semi monthly meetings.

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.

Agreed. when I started in the 90s I often got several months of focused work without many interruptions.

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.

Yeah and it doesn't. In practice, it just enables managers to become even more useless by blaming devs for their poor project management.

Agile projects can still fail obviously, but when they do they tend to fail in smaller ways (eg 4 weeks late instead of 6 months late, or almost hit the requirements instead of completely missed). That's a massive win.

And in the process, you burn out your devs, and have constant churn. How late are things happening in the long term, because teams prioritize the Agile rituals over cultivating long term technical excellence, craftsmanship, and team satisfaction? The way many teams practice Agile has a huge opportunity cost that's very difficult to measure, but still real.

My favorite Agile failure case is when you have all the meetings and still fail, because you spent all your time on Agile paperwork instead of designing and building a product.

I am currently succeeding at this failure.

You just didn’t do enough stand ups /s

Exactly. Teams that drink the Agile Kool-Aid seem to fail and build the wrong things just as often.

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.

They failed because you were overmanaged and leadership didn’t trust people to do the right thing. We were very agile back then, iterated quickly towards the goal but we didn’t do rituals, stand ups and other ceremonies. We just talked to each other and stakeholders.

> Hard to accomplish anything that requires experimentation over months until it works.

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.

We are still fiddling endlessly with edge cases in Kubernetes or AWS. I don’t see much difference.

I'm generally puzzled by the HN conventional wisdom against meetings, and I'm puzzled by this thread specifically because there doesn't seem to be a single commenter who is as much as just fine with meetings.

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?

I don't mind the morning meeting, they can be useful to catch up with where the team is and who needs help, and who's working on a problem someone else solved last week/month/year.

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.

I feel the same, the dayli meetings are super important for fast iteration. Sayinf you dont need those is implying there is no outside input that yould improve your work. Wich is only true when your task is so sepperated from everyone that you could effectively get your own one man team.

>I don't know how I would understand my team mates as people

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.

Yeah, the connection between understanding them as people and meetings per se is a bit tenuous, but to get to know them better I would have to interrupt them for a chat, or schedule a coffee break with them, or go to lunch with them, all of which seem as "interrupting to flow" as a scheduled meeting.

> I'm puzzled by this thread specifically because there doesn't seem to be a single commenter who is as much as just fine with meetings.

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

I'm on your side but that's because my team is small and any meeting I'm attending means my input is required. The daily standups are helpful in knowing what is the progress of the overall project and whether I should stop to help somewhere else, and also gives me a chance to talk with my colleagues. I suspect most of the people objecting here aren't attending discussion based meetings but heres-the-latest-news type of meetings.

> Developers are expected to attend meetings more than ever. The focus required to deep dive into complex issues get's broken with meetings that developers shouldn't be attending. You can attend meetings or you program rarely can you do both effectively on the same day and rarely can you get the focus you once had.

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"?

I'm curious, how did your boss respond to that?

My bet would be something like:

"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"

> 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.

That is horrifying !

The weekly pre-meeting to the weekly meeting on streamlining our processes.

I kid you not.

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

He let me change my hours so I now work 6:30am to noon. The rest of the day I play video games, watch tv, walk my dog, go grocery shopping, etc. I just make sure to show up to the the 15 - 30 minute "standups" throughout the afternoon.

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.

I've spent 2 years in a team that was allowed to build platform tooling from scratch and it's been the most productive and high impact work i've done to date.

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.

Re: meetings, I really think we need more tech companies taking the initiative to cut out meetings entirely. I think many companies would be shocked to find out that work would continue on, productivity would actually go up, and reported employer happiness would improve.

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.

I tried this, it didn't work well for my team.

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)

In that situation, I think just the goal of minimizing the amount of meetings to the best of your team's ability would still help. Preferably 2 hours or less total, but 3 or 4 might be okay if special care is taken to when they are scheduled.

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 wish there was a true measure for opportunity cost.

There's a place for meetings, but if you're efficient, they should be rare, small and short.

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.

>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.

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

> doesn't provide an opportunity of non-verbal self reflection and focuses you into threadmill small task thinking never connecting with the project as a whole.

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

> No one wants to reinvent the wheel so gluing together packages is considered best practice. The work has become more about making decisions around the packages you choose rather than being given time to make the package.

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.

Meetings on Monday only. A lot of wasted time on Mondays anyway (how can be it be that your mind adapts to the weekend's free time in a minute but takes hours to drudge itself back to "work mode" after the weekend?) and that leaves the rest of the week for programming.

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.

> Daily standups shouldn't be necessary with a team constantly communicating.

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.

He's not denying that (constant) communication isn't important.

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.

> He's not denying that (constant) communication isn't important.

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

I view the daily standup as a way to communicate status to a Product Owner/Project Manager/SCRUM Master who may have to communicate status to a larger "Standup of Standups", if you will.

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.

>I view the daily standup as a way to communicate status to a Product Owner/Project Manager/SCRUM Master who may have to communicate status to a larger "Standup of Standups", if you will.

What's wrong with an email?

Or that work tracking system they spent all that time and money configuring.

Standups aren't supposed to be status reports. They're supposed to be huddles (to determine the plan of action). Want "status"? Look at the "xyz board". Blockers? That's important. Communicating any blockers that need to be addressed. That can be an email. And shouldn't have to wait until the next huddle. You can waste hours waiting. Communicate blockers immediately synchronously (interrupting) or asynchronously (noninterrupting, like email) depending on your work environments preferred or agreed upon protocols.

Perhaps not, but a 10-minute daily face-to-face status update isn't so bad. Some thing can't be clearly communicated via a project board. Blockers shouldn't wait until a standup, but a standup can be a useful failsafe. It means that a quick sync up happens at least once a day.

> Developers are expected to attend meetings more than ever.

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.

> I'm curious to learn more from people who are handling this well.

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.

Sleep until about 15 minutes before the first meeting. There's no sense bothering getting into work only to be interrupted by a meeting.

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.

Mostly, I refuse and explain why I am refusing. I write replies like:-

"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.

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

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.

Sometimes, I've just kept on coding through the meeting. It's like listening to a podcast as you code. You do have to keep one ear out in case someone asks you a question directly, but listening for your name Alexa-wake-word-style isn't that hard.

Reply on news.ycombinator.com