11–20 of 60 posts
Divide it into smaller specific goals. I don't "read books", I "read chapter X of book Y", it's much easier to get idea of how much is left and you can finish it in a reasonable amount of time.
I also don't "clean" in one go, I have smaller tasks spread out over the week. Typically missing one thing won't make much difference, which is also nice.
I've sometimes used this method: break the work into pieces, and invent little rewards for the completion of each piece, e.g., next cup of coffee, walk around the block, read one story on website, get snack, etc.
I bribe myself with small chunks of nice chocolate as well sometimes
Editing is easier than creating (blank page paralysis). When I wrote my masters thesis I auto-generated 50 pages of Lorem Ipsum, properly formatted, and started editing it. “The title is clearly wrong, I’ll change that. Oh look, the first heading is also wrong, let’s put something else in here. Now the paragraph doesn’t match the heading, better fix that” By the time I get to the paragraph I’m mentally invested and c…
It doesn’t just apply to writing human readable text, either. It’s great while developing software as well. I’ve learned to try and get some minimal deployable unit complete, then start filling it in. The sooner something is deployable, the sooner you’re iterating on it rather than having some huge first iteration before you get feedback.
It may not be useful at first, but it’s great for finding integration problems early, nailing down interfaces so that others can build off of it (e.g., start with an in memory representation before writing a persistence layer, so it “works”, with a bug being that it loses all info after a restart)
It also means that you can get metrics and monitoring in early, so you’re not having to tack that on at the last minute.
Once I internalized this, I found it made it a lot easier to fit in with writing user stores pretty well. Once you’ve got that first deployment done, you’re a able to have a feedback loop, so instead of designing some big system up front, you can get something small out and validate that it meets it’s need. and that there is a need.
Amphetamine salts, how else?
Either, do it and spend the time after doing something I like, or try to spin the boring thing as possibly interesting.
Like documenting a potential usecase and seeing how that would actually happen. Though I end up messing with the code/configs instead
I've sometimes used this method: break the work into pieces, and invent little rewards for the completion of each piece, e.g., next cup of coffee, walk around the block, read one story on website, get snack, etc.
Don't sip before getting started though!
For getting in the task, I've noticed doing a little superficial manual linting on a code works quite well for me to get inside it (I've recently inherited some non linted code). I guess doing some (semi) automatic, mindless task can help to get started.
For documentation, maybe doing some boilerplate labor could work. If you don't have rules to follow when working on documentation, maybe create some so you have a framework in which you can build habit.
Maybe having a checklist on what step to follow when writing doc would help too? Like "read the function, add the doc string, the description of the parameters, followed by the return values, etc.
Food for thoughts, untested, not a lawyer, not a physician, etc.