Fog Creek Software
Discussion Board

Getting Things Done: best brief tips

Inspired by previous posts about the book "Getting Things Done".

Please provide your top 1 or two TIPS. Try to keep it brief.

I'll start:

Have ONE short label for each project.

If you store different types of materials for the project, you ALWAYS use that label.

Email:  subject: [Myproject] this is the subject
Brochures, catalogs, CDs in file folder with name MyProject
File folder on your computer called MyProject.

Sunday, August 8, 2004

Just Do It.

Sunday, August 8, 2004

It takes a certain amount of ignorance and excitement to get things done.  I'm reminded of that reporter who died in Iraq from an annurism(sp) in his lung?  (Can't think of his name or the exact cause of death but that's beside my point.)  The guy seemed so excited about everything he did.  He was just happy all the time you saw 'em.  Even when he was in Iraq.  He was just excited to be doing his job.  (I would have been exicted to work with Soledad O'Brien too!)

Anyway ignorance and excitement is what it takes.  There really are no "tips" you can give a person.  I can't tell you to be excited.  I can't tell you to code all day long and ignore the side effects of your poor design (ignorance).

So the best tip I can give is to be ignorant and excited.

Sunday, August 8, 2004

As a stronger alternative to Nike's suggestion: JFDI - my favourite methodology ;-)

Sunday, August 8, 2004

The thing that's helped me the most is keeping a list, on paper, of things to do. Then I just go through them and check off everything as it's done. Having that list right in front of me motivates me to get through it and check off those items, no matter how small they are.

This also helps me keep track of what I've done.

Sunday, August 8, 2004

Hmmm... doesn't look like any of the responses are reponses to the original post, which is about a specific book (more info @ & various threads in this forum).

Here's a tip for software people, very much in line w/the theory of FogBugz: every task goes into the bug database. though i don't tend to follow that one at the early, less defined, stage of the project but rather use paper to-do lists. later on everything which takes more than 5 minutes goes into the db when it's requested.

Sunday, August 8, 2004

I posted this in the previous thread, but it is worth repeating:

Start roughing out a project by grabbing a manila folder, opening it up and doing your "mind map" or whatever right on the inside of it. Grab a manila folder, a pen, and some blank paper. Brainstorm the project on the manila folder, then move on to the next portions - object diagrams, db layouts, and UI sketches, etc. - on the blank paper. Put the sheets into the folder, label it, and now you have a fully planned out product and all of your thoughts on it nicely captured. It's out of your head in a system that you can trust. As you add additional items to your folder and work on that project you have all of your original thinking on it right there with you.

Also, the basic "Do any item that requires less than two minutes immediately" is a good rule to follow.


Sunday, August 8, 2004

Two quick thoughts ...

1) One short label.

This reminds me of one of the reasons I prefer wiki (and my own wiki-like desktop PIM for keeping my notes in.

The fact that you have to give each page a unique, unambiguous name, is really good to help you remember things. Hyperlinks between all pages is pretty damned useful too, of course. But I'm becoming increasingly aware that the "one unique and meaningful pagename" is an unremarked stroke of genius.

2) Checklists

The problem with all checklists for me, is that usually what gets put on them are the things I *need* to do, but don't particularly *want* to. Just keeping track of these doesn't solve the main problem : motivating me to do them.

In contrast, the things I actually want to do, I don't need reminding.

phil jones
Sunday, August 8, 2004

"Just keeping track of these doesn't solve the main problem : motivating me to do them."

This is the reason why the GTD method says specifically NOT to make lists of a bunch of steps to the project, but to only write down the Next Action(s) for the project. If you only write down the very next things that you can do, you remove the demotivation of looking at a list of things that you can't do just yet and that you aren't sure about.


Sunday, August 8, 2004

Yep, the Next Actions List is probably the single best thing I took away from that book. It's something I did when I was at the peak of my organizational skills and worked at a job where nothing could be overlooked, and it's something I do again now that I read the book.
Sunday, August 8, 2004

I am in my 9th semester at university, and have taken a new approach this semester which seems to be working very well (at least for me).

I used to set myself goals based on accomplishments. ie I will get to the end of this topic by this afternoon.

I found myself doing things like skimming the topic to get it done, rushing through it. skipping the questions etc. I did this for 8 semesters.

This semester I switched to a new method.
I have some graph paper, and on the paper has six bars with the subjects I am studying (plus including a bar for my project, and for another personal project). Everytime I spend some time on something I color in an hour (1cm) on the corresponding bar.

At the end of the week I work out my 'average time spent per subject for the week' and the individual 'average time I spend on this subject since the beginning of semester'.

Like I said, this obviously suits certain aspects of my personality. But so far it has really worked. I am more motivated, I don't feel the need to rush through a topic, so I am learning more.  All good things.

Aussie chick
Monday, August 9, 2004

AussieChick, you should read "How to work the competition in to the ground and have fun doing it" by John T Molloy. I think that's the title anyway. He had also describes a metrics based system for measuring the work you do, not too dissimilar from the article frequently linked to from here, but much more detailed. I think the first time I read their article I felt they'd ripped off this book.
Monday, August 9, 2004

Anything that helps me get over my procrastination. I working hard at making myself *want* to write the documentation for my program.

Also apologies to the OP. I reread the title, it did say 'Brief tips'. I am sorry I don't do 'brief' very well at all.

Aussie chick
Monday, August 9, 2004

How to work the competition into the ground By Molloy
Looks interesting

Tuesday, August 10, 2004

It is. A little odd for his books, usually he publishes studies (his famous one on clothing, for example), but a good one.

Essentially he asks you to keep a time log, and note when and what kind of interruption you have, if it's necessary or not, and how long it took you to get back to work after.

After a week or so of keeping this time log and not before (so you don't jump to the same conclusions that kept you in this unproductive mess), he asks you to analyze it and look for trends.

Then you can adjust your work habits accordingly.

There's more to it than that, but that's the general gist of it. Should be enough to help you make a decision on whether or not to buy it anyway.
Tuesday, August 10, 2004

>Anyway ignorance and excitement is what it takes. <

Sounds like unsafe sex to me...

Data Miner
Wednesday, August 11, 2004

*  Recent Topics

*  Fog Creek Home