His technique is pretty much the standard for task management.
Every week, I submit the following weekly report to my boss.
Last Week:
- Meetings:
- Planned:
- Unplanned:
- Blocking Issues:
This Week:
- Meetings:
- Planned:
Each week, I create a list of commitments/tasks that I plan to perform. In "Last Week", I simply report [DONE] or [NOT DONE] and explain why a given task wasn't done. I strive to complete all my commitments and view NOT DONE as unacceptable.
I have a task to check my weekly commitments every morning. Each day, I paste in a 9-5 template where I plug in tasks around meetings from my weekly commitments.
I save all my side projects for later in the day as a reward for completing my other tasks.
Any plan that relies on a schedule also relies on your ability to make a good schedule. If you plan your tasks for the week and are far too ambitious, it'll be demoralizing when you don't complete everything. If you're not ambitious enough, you'll always be on schedule but things will take too long because you're not pushing yourself. To plan a reasonable schedule you need experience but if you have the experience you don't need the schedule. The schedule would be beneficial if you're working as part of a team (because other people won't have the experience to know how long a task will take you), but if you're working alone and you say "this task will take one day", that doesn't change anything - it still takes a day.
I'd only keep a "to-do" list if you have trouble focusing, not as a way to say "here's what I want to accomplish by a certain deadline". | |
SilkWizard wrote:
This is a very cool article in that it goes beyond the easy answers I hear time and time again of "schedule" or "just do it." Thanks for that.
Re: Design
It's true I've been bad at getting things done, but I've certainly developed a ton of experience with the process of development to the point where I can support the idea that having the design down on paper ahead of time can make a big difference.
For me at least, programming is easy, design is hard. At first, design requires a great deal of abstract visualization to come to an understanding of what the finished product should work like. Then, design requires a great deal of patience as I painstakingly work out exactly how these details will work. I suspect there's only one cure for this: hard practice and experience.
I started my GSDC'10 with the idea that, if I were to base it predominantly on the Lode Wars model, the design concerns would be minimal. However, two problems emerged:
First, that my creative drives demanded I deviate from the original design - no longer were these alien adventurers digging through dirt, but rather configurable mecha. This brought a whole new slew of design hurdles, and the one I found myself stuck on with this: how do the weapons attach and are activated by the player? I had many possible solutions, but none of them seemed particularly comfortable.
Second, that just because I know exactly how a game of Lode Wars functions from beginning to end doesn't mean I understand how the underlying design holds the thing together. Consequently, I still had a great deal of design work to do even with a working model to base it upon.
Well, anywho, I do need to work on becoming self-motivated. Not just for my endeavors here on BYOND, but for my endeavors just about anywhere in life.