Recently, I took a good course on time management called "First Things First," based on the book of the same title by Stephen Covey. It emphasizes linking time management decisions to one's personal priorities and overall goals. As I was thinking about it, I saw many connections between time management and process scheduling in an operating system. As Rob Kolstad observed in his "motd" column recently, the overhead of ineffective multitasking can be extremely crippling. I can certainly relate firsthand.
At the risk of sounding corny, I'll indulge in analogies between the concepts of First Things First and the software world. I
hope it will be worth the risk and there will be some interesting connections. At the very least, there might be some humor value.
One of the things that First Things First teaches is to make an explicit distinction between the importance and urgency of a task. Covey draws a four-quadrant map relating the two attributes:
Quadrant I tasks are both important and urgent. These are high-priority items that we just have to address right now things like a disk crash or a rapidly approaching deadline. Our schedulers have gotten good at handling these tasks, since they are immediately important to our livelihood.
Quadrant II tasks are important, but not urgent. These are the things that we know we should do, but we can put them off because they aren't pressing things like backups and commenting code, sometimes even things like taking a break or finding some time to relax. These are the CPU-starved processes that need better treatment from our schedulers.
Quadrant III tasks have an insidious sense of urgency to them, but are in fact unimportant. We do these things because they present themselves to us immediately, and they end up being major time sinks. The are things like replying to unimportant email messages as they arrive, responding to flame-bait news articles and downloading, compiling, and installing the latest version of a rarely used software package just because we see an announcement. These are the rogue processes that fool our schedulers into putting them on the run queue, but they have no business being there.
Quadrant IV tasks are both unimportant and not urgent. This is when we randomly surf the Web or read news for the express purpose of avoiding something else (as opposed to surfing the Web or reading news as part of a normal routine that would be a Quadrant II activity). When our schedulers are caught up in Quadrant I crises and Quadrant III rat holes, we compensate by escaping to Quadrant IV, forking off random processes, and redundantly sweeping our mental caches.
It seems like the vanilla behavior for many of our schedulers is to service Quadrants I and III, focusing on urgency while sacrificing importance. This is somewhat akin to a first come first served approach. Compared to that, the first things first approach ensures that Quadrant II tasks have a high priority, and Quadrant III tasks have a low priority. A beneficial side effect of this is that completing Quadrant II tasks decreases the number of Quadrant I crises that have to be dealt with and in turn lessens the need for us to escape to Quadrant IV.
But how does one go about implementing this scheduling algorithm? There is no quick fix approach; we have to rewrite our wetware kernels. Before we can do that, we need to understand our own source code. We need to do some major code inspection and discover what our priorities really are, what we really think is important to us. Then we are ready to rearchitect our code to do the right things. (Covey refers to these as "true north" principles, those things we know to be correct, independent of ourselves.) While we're at it, we can take the opportunity to unlink those encumbering behavioral scripts that we have implicitly copied from other people (mindless code reuse is not a good thing).
We also need to do realtime debugging. When we encounter an inconsistency between what we think we should be doing and what we're actually doing, we need to be able to singlestep through our code to figure out the problem. Covey calls this "exercising integrity in the moment of choice." If we get good at self-awareness, we can consistently run with both -g and -O turned on without any decrease in performance. We can sense when our scheduler is about to switch to a Quadrant III task, like impulsively responding to an unimportant email message, and say "no" because we've internalized the higher priority of other things.
Just as with software, tracking down challenging bugs and making the code more concise, more elegant, and cleverer can be really satisfying. And the understanding that we gain in the process is truly enlightening. But at the same time, we need to guard against creeping featurism (stretching ourselves too thin by trying to do too many things) and overengineering (perfectionism, which ends up collapsing under its own weight).
The book discusses several other aspects of time management by putting them in the context of a bigger picture and is chock-full of real-life anecdotes. If you're looking for a robust and flexible conceptual model for time management, I highly recommend First Things First.
At the risk of sounding corny, I'll indulge in analogies between the concepts of First Things First and the software world. I
hope it will be worth the risk and there will be some interesting connections. At the very least, there might be some humor value.
One of the things that First Things First teaches is to make an explicit distinction between the importance and urgency of a task. Covey draws a four-quadrant map relating the two attributes:
| Quadrant 1: Urgent/Important | Quadrant II: Not Urgent/Important |
| Quadrant III: Urgent/Unimportant | Quadrant IV: Not Urgent/Unimportant |
Quadrant II tasks are important, but not urgent. These are the things that we know we should do, but we can put them off because they aren't pressing things like backups and commenting code, sometimes even things like taking a break or finding some time to relax. These are the CPU-starved processes that need better treatment from our schedulers.
Quadrant III tasks have an insidious sense of urgency to them, but are in fact unimportant. We do these things because they present themselves to us immediately, and they end up being major time sinks. The are things like replying to unimportant email messages as they arrive, responding to flame-bait news articles and downloading, compiling, and installing the latest version of a rarely used software package just because we see an announcement. These are the rogue processes that fool our schedulers into putting them on the run queue, but they have no business being there.
Quadrant IV tasks are both unimportant and not urgent. This is when we randomly surf the Web or read news for the express purpose of avoiding something else (as opposed to surfing the Web or reading news as part of a normal routine that would be a Quadrant II activity). When our schedulers are caught up in Quadrant I crises and Quadrant III rat holes, we compensate by escaping to Quadrant IV, forking off random processes, and redundantly sweeping our mental caches.
It seems like the vanilla behavior for many of our schedulers is to service Quadrants I and III, focusing on urgency while sacrificing importance. This is somewhat akin to a first come first served approach. Compared to that, the first things first approach ensures that Quadrant II tasks have a high priority, and Quadrant III tasks have a low priority. A beneficial side effect of this is that completing Quadrant II tasks decreases the number of Quadrant I crises that have to be dealt with and in turn lessens the need for us to escape to Quadrant IV.
But how does one go about implementing this scheduling algorithm? There is no quick fix approach; we have to rewrite our wetware kernels. Before we can do that, we need to understand our own source code. We need to do some major code inspection and discover what our priorities really are, what we really think is important to us. Then we are ready to rearchitect our code to do the right things. (Covey refers to these as "true north" principles, those things we know to be correct, independent of ourselves.) While we're at it, we can take the opportunity to unlink those encumbering behavioral scripts that we have implicitly copied from other people (mindless code reuse is not a good thing).
We also need to do realtime debugging. When we encounter an inconsistency between what we think we should be doing and what we're actually doing, we need to be able to singlestep through our code to figure out the problem. Covey calls this "exercising integrity in the moment of choice." If we get good at self-awareness, we can consistently run with both -g and -O turned on without any decrease in performance. We can sense when our scheduler is about to switch to a Quadrant III task, like impulsively responding to an unimportant email message, and say "no" because we've internalized the higher priority of other things.
Just as with software, tracking down challenging bugs and making the code more concise, more elegant, and cleverer can be really satisfying. And the understanding that we gain in the process is truly enlightening. But at the same time, we need to guard against creeping featurism (stretching ourselves too thin by trying to do too many things) and overengineering (perfectionism, which ends up collapsing under its own weight).
The book discusses several other aspects of time management by putting them in the context of a bigger picture and is chock-full of real-life anecdotes. If you're looking for a robust and flexible conceptual model for time management, I highly recommend First Things First.
SIZE Approx :1.08 Mb
DOWNLOAD NOW
If you enjoyed this post and wish to be informed whenever a new post is published, then make sure you subscribe to my regular Email Updates.
Subscribe Now!
Posts
