Maker's schedule, Manager's schedule (2009)
paulgraham.com
Maker's schedule, Manager's schedule (2009)
1–10 of 76 posts
Re: Maker's schedule, Manager's schedule (2009)
#2I have nothing to add to this specific essay discussion, except that this has been the PG essay I’ve referenced the most over the past 14 years. Wow that feels like a long time.
Re: Maker's schedule, Manager's schedule (2009)
#3The important point about this essay is that it brings to light an issue that most people would feel that they'd be blamed as overreacting for complaining about.
Re: Maker's schedule, Manager's schedule (2009)
#4Interesting article that makes some good points but this part
>They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started.
Seems ... made up?
There are all sorts of things you can do in an hour as a programmer: update a test, fix an automation script, fix and/or test a bug.
Not all programming starts with grandiose algorithm design or an architectural green field. Some does, so there's a small nugget of truth, but this is far too great a generalisation.
I do agree with the difference in schedule though. Having worked on both IC and mgmt tracks, it was easy to see a whole day fragment in to nothing when needing to get on the critical path.
Re: Maker's schedule, Manager's schedule (2009)
#5Interesting article that makes some good points but this part >They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started. Seems ... made up? There are all sorts of things you can do in an hour as a programmer: update a test, fix an automation script, fix and/or test a bug. Not all programming starts with grandiose a…
That isn’t made up in the slightest. Creative thought processes take time to get into the flow state.
Frequent disruptions to this are deeply frustrating and almost every dev I’ve worked with has made similar remarks. Poor meeting scheduling is a guaranteed way of ensuring your devs have little to no motivation to do anything.
In a previous job we called Wednesday “Meeting Wednesday” because total meeting time was at least 4 hours sometimes with small gaps between where nothing would get done.
Sure you might be able to do small tasks that truly take less than an hour but in reality that’s rarely the case.
Re: Maker's schedule, Manager's schedule (2009)
#6Interesting article that makes some good points but this part >They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started. Seems ... made up? There are all sorts of things you can do in an hour as a programmer: update a test, fix an automation script, fix and/or test a bug. Not all programming starts with grandiose a…
It's a reference to cost of context shift. Context shift matters a bit less for a manager since they are by definition juggling things already. Doesn't not matter...but less
Re: Maker's schedule, Manager's schedule (2009)
#7All true; I have also recently discovered that meetings at the start of the day are not a solution to this problem, because if the meeting is intense (in good or bad, but the effect is more pronounced if the meeting went bad) then you can spend the rest of the day thinking about it.
The only solution I can think of about the meeting problem is to have them all in the same day. A day with even just one meeting is ruined, however you organize it. Let's have them all the same day.
Re: Maker's schedule, Manager's schedule (2009)
#8Interesting article that makes some good points but this part >They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started. Seems ... made up? There are all sorts of things you can do in an hour as a programmer: update a test, fix an automation script, fix and/or test a bug. Not all programming starts with grandiose a…
It's a reference to cost of context shift. Context shift matters a bit less for a manager since they are by definition juggling things already. Doesn't not matter...but less
I'm aware of context switching but that doesn't apply to finite tasks that fit within a predefined timebox of e.g. less than half a day. And there are a lot of those out there.
Presupposing that all programming is in the pursuit of grand designs (i.e. it take half a day to a day to make meaningful progress on any task) is the only thing that would justify it. But the reality is, it isn't like that except for a subset of specific engineers in specific roles and industries.
Re: Maker's schedule, Manager's schedule (2009)
#9Interesting article that makes some good points but this part >They generally prefer to use time in units of half a day at least. You can't write or program well in units of an hour. That's barely enough time to get started. Seems ... made up? There are all sorts of things you can do in an hour as a programmer: update a test, fix an automation script, fix and/or test a bug. Not all programming starts with grandiose a…
That isn’t made up in the slightest. Creative thought processes take time to get into the flow state. Frequent disruptions to this are deeply frustrating and almost every dev I’ve worked with has made similar remarks. Poor meeting scheduling is a guaranteed way of ensuring your devs have little to no motivation to do anything. In a previous job we called Wednesday “Meeting Wednesday” because total meeting time was at…
Your rarity is another man's frequency. Defining all programming in terms of long drawn out creative endeavours isn't very useful, which is the point I was making to begin with.
Re: Maker's schedule, Manager's schedule (2009)
#10All true; I have also recently discovered that meetings at the start of the day are not a solution to this problem, because if the meeting is intense (in good or bad, but the effect is more pronounced if the meeting went bad) then you can spend the rest of the day thinking about it. The only solution I can think of about the meeting problem is to have them all in the same day. A day with even just one meeting is ruin…
I don't think I've ever had an intense meeting but the last thing any of them does is ruin my day.
My usual response is to not even remember what was discussed minutes after it's over.
But I also think most of the meetings I take part in are useless.