To echo pg on this- another trick that i was taught early on was to book out a day or half day per week for meetings. Slot them in, try and get people to come to you (helps if you have membership to a club or some such :)) and then keep people to their time slots. If they need to follow up - email or reschedule based on an action point.
One other point: agile standups seem to work well even for makers because they're bound tightly to the start of working sessions and last for a short time. They enable everyone to feel connected to each other on a team, but allow them to disappear back into their office or cube to work for the rest of the day.
> agile standups seem to work well even for makers because they're bound tightly to the start of working sessions and last for a short time.
I think there's another thing going on too. Most meetings that developers go to have some specific purpose of importance. They are tactical, so as a developer you need to prepare (mentally and/or more concretely) for them. Standups - being recurring events - don't have this aspect to them. This makes them much less stressful.
The problem with the meetings PG is talking about is they tend to be in the middle of productive blocks and they are long.
The idea of an Agile standup is usually it is right at the start of the day, when people are still drinking their coffee and waking up, and they are short (the standing is deliberately to keep it short and to the point). Sure, you might have a 10 minute standup at the start of the day, but that's only 10 minutes off the beginning of your 3-hour productive chunk. They can also help you get into the flow by getting you thinking about work.
A very interesting article. As a manager, I always tried to schedule meetings with my people first thing in the morning for precisely this reason (though I could not have articulated it in these terms before.)
One other option for his dilemma about "grabbing coffee" is simply to reschedule. It may not always work, but you can often minimize that interruption by pushing it to the end of the day or having it coincide with lunch where there is at least some small interruption anyway. It is hardly a perfect option, but it may often be the best.
Really, really interesting. Totally agree. As activity around Woobius has picked up recently, I've been struggling with exactly this problem. My cofounder happily schedules meetings with various potential clients or contacts or other useful people to meet, and they tend to break up my day in disastrous ways. I do indeed find that often, a meeting in the early afternoon (say 1-2pm) can blow up my entire day (at least in terms of turning a day that could have been chock full with super-productive work into one that only contributes a few bits of real work here or there).
I like the tip about working from dinner to 3am, too, but doesn't that blow away any chance whatsoever of social life? If you have a significant other, I imagine that's a clear no-go. Also, if you plan to attend the odd networking event, you won't (or at least, a networking event will basically cost you a whole working day, which seems pretty disastrous). How do you deal with those sociable activities when you're on the dinner-3am schedule?
A 1pm meeting (directly after a 12pm lunch) works ok for me. It's the 10am and 3pm ones that kill me. They mean virtually nothing done in the morning or afternoon, respectively.
It does blow away a social life and is antithetical to a significant other. PG clearly states elsewhere that he had neither for all but a very short part of the time that he was working on Viaweb, and implies or states in numerous places that this kind of dedication is necessary to achieve startup success.
The theory goes that the financial reward of a startup is a highly dense, compressed version of what you would otherwise be collecting through decades of salaried work of some sort, but is risky and always close to the margin of failure. So, the account goes, it requires a level of commitment that pretty much necessarily precludes a "healthy work-life balance."
Hey, I'm not suggesting "it gets in the way of a healthy work-life balance". Going out for drinks or to networking events is often a part of work. A lot of business success depends on who you meet, and how you get on with them, rather than how well you build your product. If you're totally anti-social, you'll probably miss out on a lot of potential business contacts that could make or break your business, no matter how good your product is.
Paul Graham can be hit or miss, IMO, but this one is a direct hit. I don't mind meetings per se - in a good company, they have merit - but their effect on the work day can be disastrous. If you don't work somewhere that understand that programmers need large uninterrupted chunks of time, well, you're not at a developer friendly place. There's few worse problems. And non-makers often don't have any idea that it's not just the standard 'coders are cranky' going on. (We, as a group, _are_ cranky, mind you.)
I work an odd job. It is approximately equal parts system administration, programming, and tech support. Can you guess which part I dread most?
I relish the days I can lock myself in a basement laboratory and hide out with my code. Some days I just give up on getting non-support work done because I'm getting interrupted every hour with a 5-minute fix or to reboot a fax machine. I've toyed with the idea of shifting my schedule to only overlap with the rest of the office half the day. There is no way I can really schedule much active work (as opposed to reactive tech support) in a chunk less than about three hours.
I'll move on when I can, but right now I've got one perk I don't want to trade for anything.
I have a similar job + management duties. I've found the guidelines in the book Time Management for System Administrators ( http://my.safaribooksonline.com/0596007833 ) pretty good.
The strategy where you have a fellow team member act as your shield is effective. Every other day you rotate the role of shield, aka as the secretary.
Students, take this advice to heart as well. Are all your classes grouped together? They should be. I'd go so far to claim that you should take a less interesting set of classes in order to group them all together. I'm taking Distributed Systems this semester instead of Data Mining for this very reason. Am I more interested in Data Mining? Yes. But I'll wait until next semester. Distributed Systems are pretty cool too, and even the most amazing class is not worth adding several hours of dead time to your week.
(Interesting note for anyone familiar with Randy Pausch: he mentions this very phemonena in his lecture about time management.)
Counterpoint: While I agree, I have found that when I have a little spacing between classes per week (say one hour between lectures on Mondays) I face less administrative hassles in the long run.
This is because there's nothing productive that can be done in that hour except administrative work. Submitting forms, replying to emails, returning library books are all things that otherwise fall by the wayside to your productivity, but this way I don't get into trouble or waste "good" time doing them either.
Good point. Another option (as Randy mentions in his talk) is to schedule a "fake" class during the dead hour. Just go to the same spot in the library every day and work on the same class. Office hours are useful for this purpose as well.
I sort of did this during my undergrad. But instead it was essentially 9-5 minus whatever classes I had. I would just spend any time not in class during the work day to work on class work unless I had every assignment done. It helped me get ahead and then I could just relax in the evenings because I knew I'd have time to work on things later in the week.
In many classes it's much easier to do productive work in an hour than at most programming jobs. Programming jobs tend to be structured in terms of large projects/milestones, while classes tend to have smaller goals or problems on the problem sets that can be done in < 1 hour. And if all else fails, reading a text book for an hour can be quite productive, and it's nice to let the information settle in your brain before applying it anyway.
"All we ask from those on the manager's schedule is that they understand the cost."
YES! I was just saying this the other day: how a meeting for a programmer has a different cost than a meeting for a manager. I will be sending this link out to many people.
The hardest jobs in software (IMHO) will be the engineering leads that have to be an interface between management and their engineering team. They are also asked to "make" at high quality but can't escape the management schedule overlap. So the only other option is to work themselves to death at night when no one can interrupt.
I think some managers have also begun to require (or encourage) semi-constant instant messaging which can hurt a "maker's schedule", too. I've been guilty of this even recently. Perhaps the continual overhang of the interruptive IM can make them feel that anxiety of not being able to work on any hard/long problems for fear of being interrupted?
The best "makers" have adapted to this in their own ways, of course.
I agree, the problem (and the solution) lies with the people who are the interface between makers and managers. The job description for these people varies but you know who they are - project leader type people.
Here's what we try to do: all meetings known to involve lots of people are all scheduled Thursdays. The people who only have to attend one meeting don't care, and the people who have to attend multiple ones just cross off Thursday from being a "real work" day. Yes okay, it's a cost, but at least it is only a 20% cost.
"Emergency" meetings involving senior management (you all know why the sarcasm quotes are there): the interface person should take the hit. In my experience there is rarely a technical issue raised in a senior management context that cannot be adequeately fielded (!= implemented) by a good project lead. Actually, I regard this as one of the major contributions of the leader: take all the crap on so that your guys can be left alone to do their work. I realise this opens a whole different can of worms in discussing what kind of person should be a project leader.
If you have a shop with people working mixed hours (ie when everybody is not on a 9-5 schedule) you should have "core hours" to allow for meetings anyway. This at least stops meetingitis from creeping throughout the day.
IM is a bigger problem I agree, but not necessarily in this category as it is a maker-to-maker disruption source as well as manager-to-maker one.
Another problem this poses for companies is that conference rooms are a scarce resource. Not everyone can schedule all their meetings so they're not in the middle of an uninterrupted work period.
There is a parallel to the "work expands to fill the schedule" thing. Our big company team recently moved to a brand new big building. No expense was spared. Lots and lots of conference rooms are available; a significant amount more per employee capita. However, the scarcity is only marginally less. People just start booking rooms for time slots or of sizes they don't really need.
It's a nightmare for me to lug two laptops and for a meeting just to spend the whole time fighting with others over power outlets and waiting for the last person to get online.
Lately, I do all my "meetings" on GoToMeeting or Skype, and reserve face to face meetings for the beer relay and bonding.
This is why our team meetings are only 15 minutes long, and usually shorter. Any discussion or questions get done offline by only those people that are directly affected.
One way to prevent 2 hour meetings is not to let people sit down. We had an unofficial rule to that effect at Viaweb.
I remember once passing by a room and noticing a bunch of people sitting around a table. I must have raised an eyebrow or something, because one of them jumped up and said "We're not having a meeting! We were just talking."
One of the better practices from the world of "agile" software methodology is dropping the team's weekly status meeting and instead having morning "stand-up meetings" every day. Same thing - you don't let people sit down. It completely changes the tone of the conversations, because no one wants to stand in a meeting room for longer than 10 or 15 minutes.
Not to mention that when the status meetings - or, even more significantly, other kinds of meetings (design meetings, planning meetings, etc.) - are spaced that far apart temporally, every meeting just becomes mostly a rehash of everything forgotten since the last meeting. The "agile" folks have the additional insight that reporting early and often is good.
My solution is to simply follow my old student cycle - "lecture time" from 9am to 1pm, lunch break from 1-2 (if you want a hot lunch as I do, it always triggers an interrupt regardless). Since lectures are almost never contiguous, you can slot meetings and speculative meetings between them. I often meet people for lunch (the equivalent of "for coffee") and put important meetings at 2pm - 3pm (so that they stand out in my schedule, but still don't break my contiguous day.)
Everything important happens at 2/3pm onwards. I often go for a run at 6/7pm (hint: exercise is important) but I usually do a lot of thinking while on the treadmill, so it counts more as "retreat and reassess time" than an interrupt. Peak time is 8/9pm onwards, since the run provides time for reflection and restrategizing. I view the next few hours as a "runway" in that it provides a time for loading things onto my mental stack. If by midnight things aren't flowing, I wind down and get to bed by 1am to prep for the next day - but if things are in flow, I unleash and never stop until I'm exhausted (anywhere between 3am - 8am) and crash. (This is why important meetings are kept for 2pm, so that recovery is still possible without constraining the runway)
This is nice validation to have. For a while now, I've been wondering if I'm just a bit precious for asserting that I absolutely need full focus and no interruptions otherwise my productivity dies.
Still, makes me wonder how on earth I'm ever going to successfully grow the business, while I've still got development work to focus on.
This also speaks to why Makers tend to be somewhat noctural: the default for night-time that it be uninterrupted. Not just interruptions by other people, but by our own notions of what we "should be doing", i.e. going to the post office when it's open, doing laundry, following the news, etc.
Similarly, those people who have figured out that showing up to the office at 7am (or earlier) increses productivity are actually carving out Un-interrupted Time. I've found that early mornings are often a good strategy for being more productive if other things in your life conspire to deprive you of Un-interrupted Time.
That's my experience, too. I typically work for several hours early in the morning and late in the evening, then spend between 6-8 hours in the office. Time in the office is always full of disruptions, and I often can't get into any sort of groove. When I'm alone, at home, I'm far more productive in just a few hours.
You've got it, it absolutely is like that! It's such a subtle thing when you talk about it to people who obviously are trying to achieve things in a different mode, they'll say things like "come on, pull yourself together - you are simply not ambitious enough!" which makes you feel even more miserable and not productive. So we keep staying up all night - for a short period I managed to be able to rise at exactly 5 AM in the morning which was great but I endured it just for a month or so. You need discipline but you get much of your health back. I am working to get back in the habit again. Although nighttime has some additional quality for me which morning time doesn't seem to offer as much which is simply a higher frequency of creativity sparks (and maybe a higher error rate as well ;))
The problem I've had with coming in early is that most of the people I work around are procrastinators. So if the business day is 9 to 5, they will push off most of their work to close to 5. If I come in at 7am and expect to leave at 4 it is nearly impossible because that is the busiest time of most peoples days. It is a let down if I leave "early". I end up working 7 to 5 and then can't do my usual nighttime distraction-less work because I need to get up early the next day.
I've actually found that I can't get into top "people mode" form without a warm-up. This means that, not only does a random meeting deprive me of a half day's worth of intense "maker" concentration, but I'm not even at my best for the 30 or 60 minutes of the meeting, because I've not warmed up into "people mode".
In my ideal world, I'd be in maker mode all but one day every workweek. I'd spend that remaining day doing nothing but meeting with people. I'd be in better form for both "maker mode" and "people mode", and I'd get more of both done.
Although the comparison of schedule types is interesting, the application to YC's schedule makes no sense.
An investor may use the manager's schedule for his work-day where he meets with prospective investments, meets with current investments, "grabs coffee"s, etc. When he goes home, he does not spend an hour with his wife, an hour with his kids, an hour reading "the brothers karamazov", and an hour of sleep. He goes home and has the maker's schedule.
Similarly, PG mentions that YC operates on the maker's schedule. But what he means is: if he grabs coffee it will cost him half a day's making work, not a half a day's YC managing work. PG, I'm assuming, writes essays, writes code, etc, not for YC investment management but for other projects. YC does operate on a manager's schedule: he mentions that Office hours are scheduled, interviews are in timely segments, etc.
So really, YC spends less time on investment management than other investors. There's nothing wrong with this. That's great. But let's not suggest that management is better done on a maker's schedule.
Strangely enough, management may actually be better done on a maker's schedule. It's certainly no worse done. Office hours seem to work fine for all the startups who want to talk to me. And in addition, compressing them all into the shortest time means that a group that shows up for an appointment during office hours is likely to meet several other groups of their peers while they're there. They invariably talk, and often end up helping one another.
Plus you're assuming that doing making work doesn't affect the quality of one's managing work. But that isn't true. Actively working on webapps myself makes me a much better advisor to startups doing it.
"Management on a maker's schedule" is a powerful idea. Imagine the world under that paradigm. So much quieter.
Unrelatedly, for some reason I'm leery of terms like 'office hours'. They seem ... infantilising. I guess 'office hours' is a precise description, though.
Yeah, I don't love the term "office hours" either. It's not even correct, since people have actual appointments; they're just clumped together. But I got into the habit of calling this thing office hours, and it is probably too late to change now.
"Meetings suck." Preaching to the choir a bit? I'm not impressed. Nobody ever got fired for buying IBM|Microsoft|flavor du jour. No hacker every got shot down for saying meetings suck.
Is that really all you got from this? Did you actually read it?
The thing I find about PG's essays isn't that his points are revelational, unexpected or intrinsically new, but that he so often manages to explain why these things are true, in such a way that I find myself nodding along with (nearly) every point. And he doesn't say "Meetings suck." He says:
> Those of us on the maker's schedule ... know we
> have to have some number of meetings. All we ask
> from those on the manager's schedule is that they
> understand the cost.
And that's the difference between PG and so many others. He explicitly recognises that it's not a binary "Sucks" versus "Doesn't Suck". Meetings are essential, but costly. KNowing why they're costly is of enormous value.
"Grab coffee" meetings can be particularly bad (in terms of time lost) because of the extra cost in getting to and from the cafe. When I had a normal job, getting to a meeting meant putting my shoes back on and walking down the hall. Now I have to consider which bus I'm going to take...
I've found a way to partially counteract a manager's meeting schedule: splinter my work into extremely small pieces, and write them down in a TODO list. These tasks must have a clear DONE/NOT DONE boundary, and shouldn't need to be revisited. You should also break it up so that every time you finish something, you should be able to check something off of your TODO list. If it's not already there, add it, and then check it off.
For instance, if I had to write code to read data from a GPS unit, I might break it up like this:
* Find data spec on new GPS unit.
* Look up current GPS interface.. if none, write an example and design an API around the example.
* Write out header file (We use C++... that's another story :D)
* Write function 1.
...
* Write function n.
* Procure GPS unit.
* Debug.
I always feel some personal inertia against doing a task like "Write class to load data from the new GPS unit", but it's pretty hard to look at each subtask and say "err, I guess I should organize my inbox." Which I would probably do otherwise.
I have trouble finding tasks that are indivisible, but they exist! Designing and implementing custom data structures is one that I've run into recently... it has an ambiguous up-front design cost that makes it hard to divvy-up work.
Yes! Microtasking is the enemy of procrastination. When I feel like procrastinating (99.99% of the time?) and nodding off, I just tell myself, - I'll go play this game but first I'll let myself know what exactly I'll do after I get bored with procrastination. And so I write something like:
1. Pull init code from old repository.
2. Find function that accepts the data.
3. Insert init code into the class.
4. Debug and see if it works.
5. Write callback for accepting data from TCP.
6. Link callback to init.
7. Refactor.
Then, as I have successfully broken down the huge (2-4 hr for me) task into 20-30 minutes tasks I go and run, or swim, or play 3d shooters (love Tribes 1). Interestingly, while I do that, my brain subconsciously works on the stuff from todolist and when I get back and look at the tasks it's extremely easy to get started, plus, I got a chance to think of a better way (if exists) to do stuff.
95 comments
[ 3.3 ms ] story [ 167 ms ] threadOne other point: agile standups seem to work well even for makers because they're bound tightly to the start of working sessions and last for a short time. They enable everyone to feel connected to each other on a team, but allow them to disappear back into their office or cube to work for the rest of the day.
I think there's another thing going on too. Most meetings that developers go to have some specific purpose of importance. They are tactical, so as a developer you need to prepare (mentally and/or more concretely) for them. Standups - being recurring events - don't have this aspect to them. This makes them much less stressful.
The idea of an Agile standup is usually it is right at the start of the day, when people are still drinking their coffee and waking up, and they are short (the standing is deliberately to keep it short and to the point). Sure, you might have a 10 minute standup at the start of the day, but that's only 10 minutes off the beginning of your 3-hour productive chunk. They can also help you get into the flow by getting you thinking about work.
One other option for his dilemma about "grabbing coffee" is simply to reschedule. It may not always work, but you can often minimize that interruption by pushing it to the end of the day or having it coincide with lunch where there is at least some small interruption anyway. It is hardly a perfect option, but it may often be the best.
I like the tip about working from dinner to 3am, too, but doesn't that blow away any chance whatsoever of social life? If you have a significant other, I imagine that's a clear no-go. Also, if you plan to attend the odd networking event, you won't (or at least, a networking event will basically cost you a whole working day, which seems pretty disastrous). How do you deal with those sociable activities when you're on the dinner-3am schedule?
The theory goes that the financial reward of a startup is a highly dense, compressed version of what you would otherwise be collecting through decades of salaried work of some sort, but is risky and always close to the margin of failure. So, the account goes, it requires a level of commitment that pretty much necessarily precludes a "healthy work-life balance."
I relish the days I can lock myself in a basement laboratory and hide out with my code. Some days I just give up on getting non-support work done because I'm getting interrupted every hour with a 5-minute fix or to reboot a fax machine. I've toyed with the idea of shifting my schedule to only overlap with the rest of the office half the day. There is no way I can really schedule much active work (as opposed to reactive tech support) in a chunk less than about three hours.
I'll move on when I can, but right now I've got one perk I don't want to trade for anything.
The strategy where you have a fellow team member act as your shield is effective. Every other day you rotate the role of shield, aka as the secretary.
(Interesting note for anyone familiar with Randy Pausch: he mentions this very phemonena in his lecture about time management.)
This is because there's nothing productive that can be done in that hour except administrative work. Submitting forms, replying to emails, returning library books are all things that otherwise fall by the wayside to your productivity, but this way I don't get into trouble or waste "good" time doing them either.
In many classes it's much easier to do productive work in an hour than at most programming jobs. Programming jobs tend to be structured in terms of large projects/milestones, while classes tend to have smaller goals or problems on the problem sets that can be done in < 1 hour. And if all else fails, reading a text book for an hour can be quite productive, and it's nice to let the information settle in your brain before applying it anyway.
"All we ask from those on the manager's schedule is that they understand the cost."
YES! I was just saying this the other day: how a meeting for a programmer has a different cost than a meeting for a manager. I will be sending this link out to many people.
The hardest jobs in software (IMHO) will be the engineering leads that have to be an interface between management and their engineering team. They are also asked to "make" at high quality but can't escape the management schedule overlap. So the only other option is to work themselves to death at night when no one can interrupt.
I think some managers have also begun to require (or encourage) semi-constant instant messaging which can hurt a "maker's schedule", too. I've been guilty of this even recently. Perhaps the continual overhang of the interruptive IM can make them feel that anxiety of not being able to work on any hard/long problems for fear of being interrupted?
The best "makers" have adapted to this in their own ways, of course.
Here's what we try to do: all meetings known to involve lots of people are all scheduled Thursdays. The people who only have to attend one meeting don't care, and the people who have to attend multiple ones just cross off Thursday from being a "real work" day. Yes okay, it's a cost, but at least it is only a 20% cost.
"Emergency" meetings involving senior management (you all know why the sarcasm quotes are there): the interface person should take the hit. In my experience there is rarely a technical issue raised in a senior management context that cannot be adequeately fielded (!= implemented) by a good project lead. Actually, I regard this as one of the major contributions of the leader: take all the crap on so that your guys can be left alone to do their work. I realise this opens a whole different can of worms in discussing what kind of person should be a project leader.
If you have a shop with people working mixed hours (ie when everybody is not on a 9-5 schedule) you should have "core hours" to allow for meetings anyway. This at least stops meetingitis from creeping throughout the day.
IM is a bigger problem I agree, but not necessarily in this category as it is a maker-to-maker disruption source as well as manager-to-maker one.
Lately, I do all my "meetings" on GoToMeeting or Skype, and reserve face to face meetings for the beer relay and bonding.
From a smaller n, I'd expect not only a shorter meeting, but also a greater per person output.
I remember once passing by a room and noticing a bunch of people sitting around a table. I must have raised an eyebrow or something, because one of them jumped up and said "We're not having a meeting! We were just talking."
Everything important happens at 2/3pm onwards. I often go for a run at 6/7pm (hint: exercise is important) but I usually do a lot of thinking while on the treadmill, so it counts more as "retreat and reassess time" than an interrupt. Peak time is 8/9pm onwards, since the run provides time for reflection and restrategizing. I view the next few hours as a "runway" in that it provides a time for loading things onto my mental stack. If by midnight things aren't flowing, I wind down and get to bed by 1am to prep for the next day - but if things are in flow, I unleash and never stop until I'm exhausted (anywhere between 3am - 8am) and crash. (This is why important meetings are kept for 2pm, so that recovery is still possible without constraining the runway)
Still, makes me wonder how on earth I'm ever going to successfully grow the business, while I've still got development work to focus on.
Similarly, those people who have figured out that showing up to the office at 7am (or earlier) increses productivity are actually carving out Un-interrupted Time. I've found that early mornings are often a good strategy for being more productive if other things in your life conspire to deprive you of Un-interrupted Time.
In my ideal world, I'd be in maker mode all but one day every workweek. I'd spend that remaining day doing nothing but meeting with people. I'd be in better form for both "maker mode" and "people mode", and I'd get more of both done.
An investor may use the manager's schedule for his work-day where he meets with prospective investments, meets with current investments, "grabs coffee"s, etc. When he goes home, he does not spend an hour with his wife, an hour with his kids, an hour reading "the brothers karamazov", and an hour of sleep. He goes home and has the maker's schedule.
Similarly, PG mentions that YC operates on the maker's schedule. But what he means is: if he grabs coffee it will cost him half a day's making work, not a half a day's YC managing work. PG, I'm assuming, writes essays, writes code, etc, not for YC investment management but for other projects. YC does operate on a manager's schedule: he mentions that Office hours are scheduled, interviews are in timely segments, etc.
So really, YC spends less time on investment management than other investors. There's nothing wrong with this. That's great. But let's not suggest that management is better done on a maker's schedule.
Plus you're assuming that doing making work doesn't affect the quality of one's managing work. But that isn't true. Actively working on webapps myself makes me a much better advisor to startups doing it.
Unrelatedly, for some reason I'm leery of terms like 'office hours'. They seem ... infantilising. I guess 'office hours' is a precise description, though.
A "regular schedule", for me, is the worst possible thing for productivity.
And it has been said many times, too. Perhaps this iteration will be more successful: people may want to listen to pg more than some random guy.
I just forwarded this to my latest ex-girlfriend to help her understand one of the major causes of drama while we were dating. :)
Is that really all you got from this? Did you actually read it?
The thing I find about PG's essays isn't that his points are revelational, unexpected or intrinsically new, but that he so often manages to explain why these things are true, in such a way that I find myself nodding along with (nearly) every point. And he doesn't say "Meetings suck." He says:
And that's the difference between PG and so many others. He explicitly recognises that it's not a binary "Sucks" versus "Doesn't Suck". Meetings are essential, but costly. KNowing why they're costly is of enormous value.I'll be pointing my co-directors at this.
If you're a manager, you're supposed to think & act with people as a priority. U're supposed to operate from 'Social Intelligence'.
But if u're a programmer, u're supposed to operate from 'Technical Intelligence'.
Since these two are very different and will result in different thinking & acting so the schedule will obviously be different.
Anyone solve this by setting aside a few half-days each week for manager stuff, and reserving the other time for maker stuff?
For instance, if I had to write code to read data from a GPS unit, I might break it up like this:
* Find data spec on new GPS unit. * Look up current GPS interface.. if none, write an example and design an API around the example. * Write out header file (We use C++... that's another story :D) * Write function 1. ... * Write function n. * Procure GPS unit. * Debug.
I always feel some personal inertia against doing a task like "Write class to load data from the new GPS unit", but it's pretty hard to look at each subtask and say "err, I guess I should organize my inbox." Which I would probably do otherwise.
I have trouble finding tasks that are indivisible, but they exist! Designing and implementing custom data structures is one that I've run into recently... it has an ambiguous up-front design cost that makes it hard to divvy-up work.
1. Pull init code from old repository.
2. Find function that accepts the data.
3. Insert init code into the class.
4. Debug and see if it works.
5. Write callback for accepting data from TCP.
6. Link callback to init.
7. Refactor.
Then, as I have successfully broken down the huge (2-4 hr for me) task into 20-30 minutes tasks I go and run, or swim, or play 3d shooters (love Tribes 1). Interestingly, while I do that, my brain subconsciously works on the stuff from todolist and when I get back and look at the tasks it's extremely easy to get started, plus, I got a chance to think of a better way (if exists) to do stuff.