Hacker News Reader

Comment by pc86 | Hacker News Reader

> Others said they had so many meetings they couldn't possibly find enough time to have that many meetings in a day (doesn't make sense to me but that's a direct quote).

How doesn't that make sense? If you want to compress all your meetings into one day for every two-week sprint (ten working days), you only need to average 48 minutes a day of meetings to fill that day. That's not an obscene amount.

View on HN

The scenario is thus: you have, say, 6 hours of meetings relevant to team X per week. However, you tell team X that you have too many meetings on your calendar (from teams A,B,C) and thus do not have room to move X meetings to one day (but you can have these meetings otherwise).

It just sounds like a combination of lazy scheduling and no desire to improve dev experience.

Yeah, lazy scheduling is an easy trap to fall into. People have the wrong cost optimization function in mind while scheduling meetings -- moving an existing meeting is too expensive to consider, while breaking up an engineer's 4 hour block of productivity into 2 1:30 minute blocks is considered totally okay. In reality, the actual cost is the opposite -- moving a meeting costs nothing, but breaking up that block of free time costs an entire day of an engineer's time (something like $1000).

I have a plan for this. I'm writing a small program to move certain meetings to an auto-scheduled state. You pick some blocks on your calendar where you'll accept auto-scheduled meetings. You then say "I want to have a meeting with X, Y, and Z", and the system will use a constraint solver to find a time. The cost function favors bin-packed meetings, keeping entire days free, etc. If existing meetings have to move to optimize the cost function, so be it.

I don't actually know if people will tolerate this. People are creatures of habit, so if you're used to a biweekly team meeting on Monday, it will be weird when it gets replaced with a postmortem review that starts 30 minutes earlier and the team meeting moves to Thursday or whatever. I also think it will be hard to get people to commit to giving the bot a slot to work with. We shall see. If anything interesting comes of this I'll write up something about how it went.

Please do. Sounds really interesting.

There's an extension called Clockwise that does this for Google Calendar. It hugely improved productivity in my team.

https://www.getclockwise.com/

I don't see how it is lazy scheduling to have at least one meeting each day of the week that you cannot reschedule. Finding time for six one-hour meetings is by definition easier than finding time for one six-hour block of meetings.

By definition? Surely finding time in your month for a 3-day conference is a lot easier than finding time for thirty one hour conferences?

If you have a 6-unit block, then by definition you can fit 6 1-unit items - by putting them in that block. On the other hand, if you don't have a contiguous 6-unit block, you might still be able fit 6 1-unit items in (for example) 2 3-unit blocks. Compare memory allocation for 6 1KB blocks versus 1 6KB block, and how it's affected by memory fragmentation.

This is predicated on the idea that meetings are immutable once created, which is part of my original complaint.

Edit: I see what you're saying, that makes perfect sense.

I was only supporting the:

> Finding time for six one-[unit] [block]s is by definition easier than finding time for one six-[unit] [block] of meetings.

that you responded to. As long as there's anything at all with fixed position, you can end up with fragmentation, and even when (you can guarantee) there isn't, the former is just "exactly as easy" as the latter, so the general case degrades to "is by definition at least as easy as".

Reply on news.ycombinator.com