Active and passive procrastinators approach work differently
Active procrastinators who postpone work for later are mostly in control of their time, are better managers of their time and use it purposefully without worrying too much about missing deadlines. They deliberately delay tasks and feel challenged by approaching deadlines. They comfortable with fear. And a little bit of panic or threat is not an issue.
Active procrastinators will always deliver. They are better at planning but not so good at getting stuff done early when they have lots of time. They work better under pressure though. You could argue that, it’s their way of justifying putting things off.
I am wondering now, and might try to track this, if most of my problem solving thinking comes during physical activity or during rest.
physical or semi-mental attention activity such as driving, running, gym, exercising
These require part conscious awareness but not full where most computer game that I play require enough focus that intrusive thoughts are less prevalent.
resting: watching tv, attempting to sleep.
Also missing: while trying to fix an urgent, high priority issue.
I'm a runner, and several times a week I run for 45 minutes to an hour over lunch. I've found I tend to figure out the most difficult and intransigent problems during those runs. It doesn't even matter if I'm running with my usual partner and talking to him or by myself.
Some part of my brain sits back, relaxes, and thinks.
I often start writing the system documentation as soon as the architecture is starting to take shape. This is sort of rubber ducking, describing to some imaginary future software maintainer the overall structure of the system, then going into the interfaces and information flow between the modules, first at a high level, gradually moving down to specific interfaces ready to be coded in one language or another.
When the design is shaping up, it goes in parallel with writing the user documentation (which may be a user of an interactive UI, or the user of some external programming/communication interface), with a number of case studies to show how to solve user tasks. Again, I start at a general, somewhat abastract level, usually textual description only (much faster to change than graphics!), continuing to specific descriptions of (say) each GUI screen with its input and output fields, and as soon as possible thereafter, I generate screen dumps for the documentation, to verify that everything written in text matches the acutal screen dups - no controls missing neither from the screen dump nor from the text. For programming interfaces, the screen dumps are replaced by application code stubs.
Most developers delay most of all documentation "until they know what the system will look like". I can assure you: Doing the case studies, application code samples and interface definitions before you start coding, you will always run into situations where you discover that there are better ways to do things. Or more often: That some cases are very cumbersome to to with your first proposed solution. You realize that there are issues where you have noe solution at all. When you develop that partial solution, you discover that a refactoring will be required - before you have implemented anything to refactor.
It is sort of formalized rubber ducking. But if you just talk the rubber duck, or to humans, you still have to do the documentation afterwards . And you rarely get into detailed case studies where you detect unsolved problems, missing or superfluous data. You discover a lot more by writing/drawing than by just informal chatting.
because the best moments are, when I distract your my mind for a couple of minutes and then start with a fresh mind, no matter what I did in that break time
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
More often I find solutions come while trying to get to sleep (or when waking in the night). However I have also "dreamt" solutions, though not often. I did go through a phase (many years ago) of "dreaming" in JCL (IBM Mainframe Job Control Language), but with the only verb being "EXEC" they were pretty boring dreams...
Anything that is unrelated to elephants is irrelephant Anonymous - The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944 - Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
It works but the duck is always a reflection of yourself - I think it's better to use a colleague for that. At worst they are a rubber duck, at best they can give you insight with a question or an observation you didn't think of.
The reproduction of ideas is like the reproduction of life: alone it works, in team it works better.
GCS d--(d+) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X