Getting Things Done: The Art of Stress-Free Productivity

Category: Skills
Author: David Allen
All Stack Overflow 7
This Month Reddit 2


by thisiszilff   2020-12-10
What works for me is a few things:

(1) Separate work from life, be able to walk away for a bit when work isn't going well. And do walk away if things aren't going well. If you haven't been able to write any code for the past few hours, odds are you won't be able to write any in the next few hours.

(2) Focus on process over results. IE have a good process to minimize the amount of time you spend thinking about what you should be doing, whether you did the right thing, etc. What honestly helps in these cases is just having a task list of "I need to get XYZ done today" and then blasting through it without leaving room for thinking about things too much. I like Getting Things Done (ie because it helps separate work from life.

(3) Take the long view of your life/career. The truth is that you are going to make mistakes, bugs will get into prod, you're going to get burned out, etc, so you need to accept that you will have "bad" days (or days, weeks, moths where you just don't care about what you're doing in which case it is obviously going to be crap) and focus on the process for improving them to minimize them over the long run. I think the important question here isn't "did I make mistakes" but rather "is my process resulting in a slower rate of mistakes/less severe mistakes.

(4) Never forget to eat, sleep, drink water, and exercise. Especially sleep. when things are bad we tend to sacrifice sleep, that almost always makes it worse.

Most of it I think is summarized as having a process you can trust so that when things do go poorly you can focus on the process in those moments. The process will get you out.

by BullCityCatHerder   2019-07-21

The book that finally helped me was Getting Things Done. Basically for me the art of breaking a task down into well-defined tasks I can focus on for a few minutes at a time really helps.

by SibLiant   2019-07-21

Evernote. Been religious for years now. I liked the book Getting Things Done and I built that system into Evernote.

by Steve Robbins   2017-08-20

Only 5 projects? I wish :-) It's just all about being organised, not getting too hung up on an issue that takes a long time to sort out, but isn't actually that important. The latter can be quite hard to do as a techie - once a techie gets that "itch" to fix something that's annoying them, they're like a dog with a bone :-)

The second hardest thing is probably convincing your customers/project managers that asking you how you are getting on all the damn time actually SLOWS YOU DOWN. Unfortunately, some of them may well have nothing to do other than the project you are on, and are under immense pressure to deliver, so will badget the living hell out of you :-(

A lot of folk really rate this book - I think most of what is in there is common sense, but it's a decent read.

by anonymous   2017-08-20

I have completed the PSP course, the next one is supposed to be TSP which is meant for team dynamics as others say. I have mixed feelings about PSP (mostly negative, but the results were interesting), I arrived to the following conclusions:

  • First of all my main source of frustration is that the design templates are way too tedious and impractical. Change them for UML and BPMN, tell your instructors from the start, IMPOSE IF NECESSARY. The book itself says that the design templates are for people who don't know or want to learn UML.
  • Secondly, estimations were the only valuable part for me. The book itself says that you can use other stuff appart from lines of code and it even tells you how to know how relevant they are statistically. My take on this (counting lines of code) is that a tool/plugin that connects with your VCS (git, mercurial) must exist and automate the building of your personal database, otherwise is too tedious to track base/added/reused parts.
  • The process itself is nice, but not applicable to big projects, why?, because it just doesn't cope with iterations. In the real world, due to requirement changes you will always have to reiterate on a project. You can still apply the discipline to small programmatic tasks, this is: plan, design, review your design (have design standards and a small checklist that u can memorize), code, review your code (have clear coding standards and a small mental checklist you can memorize), test, ponder on your mistakes. Any experienced programmer will know these are eventually intuitive steps to follow. My recommendation in real practice: follow the process but don't document other stuff than your design, and if you do implement unit tests, document them well.
  • This process might actually be worth to follow and practical... for real-time system programming where there is absolutely no room for mistakes, otherwise doesn't feel worth it.
  • If you are seeking for a methodology to organize and improve focus, try GTD (Get Things Done) and Pomodoro first.
  • If you have obsessive-compulsive disorder you might actually enjoy PSP =).

My final recommendation, learn from it as a reference, might lead to better and more practical stuff. This thing is just too academic.

P.S.: R.I.P. Watts Humphrey

by John Nolan   2017-08-20

Getting Things Done

by David Allen.

alt text,OU01_AA240_SH20_.jpg

by prateekdayal   2017-08-19
Getting Things Done

So that I can read more and do other things :)

by BeetleB   2017-08-19
Over the years I've tried many planning methods, with very low success.

I tried GTD ( for 7 years before declaring it a failure. It does have some good ideas that I still use, but the TODO management didn't work for me. I think it'll work only for people who have fewer goals than I do. It doesn't handle large lists very well.

Some things I kept from it:

1. Filing cabinet - Instantly useful from day 1.

2. Calendars are only for hard deadlines. Don't put stuff in there that you merely want to do. I know this is the opposite of the submission here. For me, planning everything in the calendar, including things I could ignore, led to a mess. Keep it for things you really cannot ignore.

In general, any obsessive time based planning like this submission fails for me. GTD is not time based. I prefer planning my tasks for the week, not for the hour.

I like the idea behind Kanban, but I do not think it fits most of our personal lives. Very good for certain work environments, though.

Pomodoro technique: It's good, but not really for task management. It's just a good technique to stay focused. Worked for a few months until I got used to it. Now it does not keep me focused and I can easily get distracted by the web, etc.

These days I'm trying this:

I think it works better than GTD, and fills the gaps in it. If you do not want to buy the book, a condensed, down to Earth version is available as the 1 Minute Todo List:

Personally, I feel the book is better than the PDF at explaining the rationale behind the 1 minute todo list. Reading it was very calming. It explained all the problems I had had with GTD and similar techniques.

Basic ideas:

1. If you cannot examine your todo list inside of a minute, it is too long. So spend a lot of effort ensuring your daily todo list is not long.

2. Urgency and importance are not the same. We're hard wired for focusing on urgency, so do not try to make a TODO list purely based on importance.

3. Every week, identify everything that must be done in the next 10 days and put it on your list that you'll examine daily. Things you decide not to do in the next 10 days, keep in your "list to examine weekly".

4. Every day, multiple times of the day, look at the short list and do tasks from among them. If new tasks come in, add them, but keep the list short (no more than 20-25 items). If your list is getting too long, identify things to move to the "list to examine weekly" and get them out of the way.

5. If something needs to be done today, put it on the top of your list!

6. You'll also have "the list to examine monthly" as well as quarterly.

Very simple idea - works a bit better than GTD.

I think my biggest problem is that I need to reduce the goals in my life and focus on only a few. I have more goals than time in my life, and I keep jumping from one to the other. No task management system will work until I do this. Tough decisions need to be made!

by Jtsummers   2017-08-19
Mythical Man-Month, Fred Brooks [0]. Very informative series of essays on his experiences and lessons learned with IBM. If nothing else, helps to properly frame my expectations on projects with respect to resources needed to properly coordinate with others, and the pros and cons of adding people to projects at different stages (and in different roles).

Getting Things Done, David Allen [1]. Useful toolkit for getting things out of my head and onto paper (or org-mode or OmniFocus) so that I can properly focus and prioritize my time on the things I need to get done.

Communicating Sequential Processes, C.A.R. Hoare [2]. Strongly influenced the way I think about programs in general, but specifically in the embedded field where I work. (NB: I've not actually read or worked through the full text, but mainly taken what was needed to properly communicate ideas in my designs or to analyze designs and systems others have produced. This is a task for myself for early next year.)

Moonwalking with Einstein, Joshua Foer [3]. I've always had a good memory, I actually picked this up to give to a girlfriend who had a terrible memory and read it in a couple days before giving it to her (she was out of town when it arrived). Helped to explain methods that I'd somehow developed over the years, and gave me concepts and a better understanding of other methods of memory acquisition (for either short or long term purposes). If you really want to improve your memory, there are probably better resources to learn specific techniques, but this was an informative and entertaining overview. WRT work, we have to keep large systems in our minds all the time, and potentially dozens of different systems written in different languages. Memory is critical for this, even if it's just the memory of where to find the information and not the information itself.

Fluent Forever, Gabriel Wyner [4]. This one is my current read. Goes back to Moonwalking with Einstein. While the book is itself about language acquisition, it's actually given me quite a bit to think about with respect to general learning and memory acquisition (in this case, specifically for long term retention and recall). We have a couple training programs (we need more) for our new hires on development and testing. There are some concepts in here and in related readings that I think would greatly improve how we teach these folks what they need to know and in a way that would improve their retention of that information. We have a lot of people retiring in the next 1-3 years, so this is actually quite critical right now, though management is quite lackadaisical about it.







The Toyota Way, Jeffrey Liker [5]. I grokked Lean from this. Hardware focused, but the concepts can be (and have been) generalized to other process focused fields. This has helped with understanding what business processes really need to be codified, what feedback mechanisms need to be present for improvement, the criticality of bottom-up feedback and improvement (employee investment in the company/product cannot be overvalued if you want quality and good craftsmanship).

The Little Schemer, Friedman & Felleisen [6]. Going back to the comments on Fluent Forever. The structure of this is fantastic for conveying and helping students retain information. The Socratic method is very useful, and structuring courses and introductory material in this format is useful, this happened to be my introduction to it (well, I'd heard it before, but my first time really encountering it in practice). It's a useful tool for solo-study of a topic (pose your own questions and construct answers), and as a method of guiding someone to a conclusion or better understanding. Also useful in debugging software or decoding software you didn't write, after a fashion.