3 ms·

A variation of what you propose: advocates of test driven development suggest you always leave your coding session for the next day with a failing test. A comm

A variation of what you propose: advocates of test driven development suggest you always leave your coding session for the next day with a failing test. A common advice for variants of writer's block is to have some sort of ritual to get you started cranking away. The exact actions are not that important. It could be taking a shower, doing a tea, tidying up your desk, taking some deep breaths, whatever. When you do these things everyday in the same order, your 'muscle memory' eases you into a creative state. I haven't tried this, though. I'm bad at fighting procrastination. When it gets really bad, I just abuse until I feel the honest urge to get back to work (I mean honest urge as opposed to remorse). There are some things I found that help when I follow them, although I admit I don't follow them consistently enough: - Find the time of the day that works best for you. It doesn't need be the same clock time every day. In my case I have screwed sleep patterns (tending to a longer day), so I set it as a delta from my waking time. (I'm considering trying to settle into a 28 hour day, as in http://xkcd.com/320/ http://xkcd.com/320/ , but I'm digressing.) - Be proactive and aggressive about freeing such time from interruptions. - Allocate time to do other things you want to do too, including the things you procrastinate in. Doing this helps you not to feel more deprived from (other) fun than from work. When work time comes and I feel like doing something else, I make myself realise I'm practically missing the working day if I do so. Most times that will get me an honest urge to work. When it doesn't, I just go ahead and do something else all day. I can chain a few days like this, and not everyone can afford this. Eventually I come back refreshed and with no remorse. Other people (and myself, in my late teens/early 20s), would just get into a procrastination/regret spiral instead. YMMV.

euccastro 19y ago
Another thing that helps: when my last session was spent mostly coding, and I'm having trouble getting back into it, I will just take pencil and paper and sketch stuff away. Often, I'm blocked because I don't really understand well enough some part of what I'm doing, or of where I want to get to. Drawing or (otherwise) restating the problem gets me back to the state where you spend hours just knowing what to do next. And viceversa, if I've spent too much time 'designing' or otherwise thinking about the problem, I unblock by going off and making something I can run. I may eventually throw away that code, but it got me going forward. So I don't have much of a methodology. Thinking about doing and actually doing are things I do to procrastinate from each other, if you want. One technique that does help: I keep a stack.txt document, where I write my current tasks (a short phrase each), organized hierarchically (I use indentation because of a Python background; a Lisp native might use sexprs instead). When I stumble into a subtask that I need to do sometime, but which I can get away without for the time being, I 'fake it til I make it', and I enter a reminder of the proper solution in my 'mind stack' as a subtask of the current one. Whenever I think of an unrelated task that I want to do later, I will enter a reminder at the end of the stack. [Edit: OK, so it's a tree, where each path to a leave is a stack of context about what you're doing.] That avoids two problems that used to get me lost when hacking: getting lost in subtasks and losing context of what I was doing, and trouble deciding what to do next (it's easier to decide with confidence if you can see your options written together).

euccastro 19y ago

Another thing that helps: when my last session was spent mostly coding, and I'm having trouble getting back into it, I will just take pencil and paper and sketch stuff away. Often, I'm blocked because I don't really understand well enough some part of what I'm doing, or of where I want to get to. Drawing or (otherwise) restating the problem gets me back to the state where you spend hours just knowing what to do next. And viceversa, if I've spent too much time 'designing' or otherwise thinking about the problem, I unblock by going off and making something I can run. I may eventually throw away that code, but it got me going forward. So I don't have much of a methodology. Thinking about doing and actually doing are things I do to procrastinate from each other, if you want. One technique that does help: I keep a stack.txt document, where I write my current tasks (a short phrase each), organized hierarchically (I use indentation because of a Python background; a Lisp native might use sexprs instead). When I stumble into a subtask that I need to do sometime, but which I can get away without for the time being, I 'fake it til I make it', and I enter a reminder of the proper solution in my 'mind stack' as a subtask of the current one. Whenever I think of an unrelated task that I want to do later, I will enter a reminder at the end of the stack. [Edit: OK, so it's a tree, where each path to a leave is a stack of context about what you're doing.] That avoids two problems that used to get me lost when hacking: getting lost in subtasks and losing context of what I was doing, and trouble deciding what to do next (it's easier to decide with confidence if you can see your options written together).