How do you force yourself to do boring tasks?

Many people think I'm a work-a-holic. My dirty little secret is that I'm actually very lazy (my wife knows :-). I can't say I have a good strategy, it's just that when I do get into a rare flow state (a few times a week) I can stay there for quite a while and little can distract me (thank you ADD!).

But here is what I would say: pick the smallest of tasks that is part of the larger work and convince yourself it's okay to only get that part done today. Also convince yourself that it's okay to do a 'Mad Dash' on it - focus on making progress, not making perfect. Save the edits and polishing for when you are in the zone.

This is how I get myself to the gym a few times a week. So many times I've told myself it's okay to just go for 10 minutes (and then sit in the hot tub :-). But once I'm there I almost always do my full regimen (which is only 45 mins).

So maybe that is my strategy: only focus on 'getting started', not on getting done.

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 continuing is easy

> I've never wrote any documentation before, and always struggled with writing descriptive content.

Respectfully, I don't believe you think it's boring, but that you don't know what makes the task successful. To compensate for this you've used the very common strategy of mentally categorizing the task as "beneath you" ergo "boring".

In this case, there's plenty of great suggestions already here, but the most important one is to become aware of this mindset and work to overcome it. Writing, of any kind, requires some measure of creativity. Documentation can be tedious. But is this any different from writing software! You need a strategy that taps into what you enjoy and already have, that makes the tedious bits effortlessly fall into the background.

In my case I ask myself this question "how can I make this task interesting? (but also accomplish it on time)" and then simply make a game of it. But that might not work for you.

I know one person who looks at documentation as "programming other people to be able to work with the tool he developed". If people read the documentation and can't use the tool, then it's a bug to be squashed and the programming language to use is "English".

Improve your attitude. Seems like you're letting your incorrect assumptions hold you back.

I had to write documentation for a DSL a couple of years ago. I studied what made good documentation, what were considered the best docs, the different modes/parts of documentation etc. There are some very good talks on that. It was really fascinating. I realized how much I didn't know about it — doesn't sound like you reached that stage yet. Recognize that you are a total beginner, with everything to learn. Good luck!

e.g. I don't know anything better than The AWK Programming Language. It's great on so many levels - how it explains what AWK is and does (often omitted in github docs!), how it starts you off using it from page 1; how in <20 pages it's gotten you using all the main features; the friendly, helpful tone; the later chapters making advanced/useful tools/programs, etc etc. That and K&R C were my exemplars in great docs. Until I started learning about documentation-writing I didn't begin to appreciate just how good they are. Can't be an accident that bwk had a hand in both! https://archive.org/details/pdfy-MgN0H1joIoDVoIC7

Cut down on caffeine. Possibly take a vacation.

I've discovered is that when I'm on caffeine, my stress levels are extremely high (around 90%) and energy levels are equivalent to at 1 AM (as measured from a smart watch). This gives me an ADHD-like effect of being hyperfocused but unable to do important things. By comparison, on a normal day, under harsher conditions, I'd have much lower stress levels (30-55%) and a lot more energy.

The brain interprets the physiological response based on context. It's a bit complex to explain in a comment, but look up the Schachter-Singer Theory. So you might have the fight/flight/freeze response, which results in procrastination. Some people condition themselves to fight (anger/insults/action). Some condition themselves to freeze (inactivity).

Spend too long in this phase, and you condition yourself into inactivity. But the actual pressure from not completing the work makes you stressed and it becomes a loop.

- see a professional to determine if there’s anything like adhd in play that may be making it harder for you

- break things down into smaller tasks

- just try to get one of those smaller tasks done, dont worry about the rest

- if the smaller task is still too big, keep breaking it down

— start things like documentation with outlines of what you want to communicate

- after you’ve got an outline, you don’t need to write it linearly. it’s ok to jump around and follow where your attention brings you

- create a slow distraction environment so you’re less likely to go off task

- see if there’s a buddy that you can pair with to get it done

- it’s better to just get something done than nothing, don’t worry about being perfect, you can come back and update it later

- ask around for what people struggle with understanding, this will help you prioritize what documentation to write

- pictures say a thousand words. try making some diagrams, and annotating them

I have a hunch that the fatigue you're encountering is caused by having to make decisions all the time.

I have found it can be helpful to split the task up differently than I otherwise would. In your case for example, I would try writing out all the paragraph headers first, then writing the sub-headers, then the first line for each one. It keeps the tasks short, which means fewer decisions and more process.

Once I'm in that flow, and don't have to stop to make any decisions, it's a great feeling and the work is much more fulfilling. Here's an Alan Watts quote that comes to mind: https://gist.github.com/elliottkember/a00076db27b0008b0cc622...

I have issues getting started on things. What I find useful is to set a 10 minute timer (or five or fifteen, though I wouldn't go higher than ten myself). Then during that time you work on the problem. When the timer goes, you stop.

The point of this is that 10 minutes is short enough that most people can deal with it, but you can get something done.

You may find, once the alarm goes of, that you want to continue. This is okay, but crucially the goal here is not to trick yourself into working longer, so it is also okay to stop when the timer goes. Don't stop before the timer goes, unless you are dying or the building is on fire.

If you do 10 minutes a day, you will make some progress in a week, and there is a good chance that you want to work more on it at least some days, though that is, again, not a requirement.

As for writing, write a sloppy first draft, then refactor it into something that is better on a second or third write through. Reorganize paragraphs as needed.

Plan to do the smallest 'next' thing. Don't think about the size of the entire work, which can be daunting and discouraging. Always only think about the first smallest thing you can do. For me this will often be a meta-thing, like prepare my physical space with what I need close-by, or make an empty directory for the files that will be there and one empty outline.txt file, etc. Basically even while procrastinating, reduce the barrier to actually starting.

Also don't think you have to follow any particular approach or methods. Write in whatever sequence you find yourself drawn to, and whatever means you choose (dictation, phone/tablet, at coffee shops, etc). To alleviate boredom, find some ways to add subtle humour into your writing--maybe only you'll know but that's enough if it entertains you while writing.

> The task is so boring that I just can't put any effort into it. I've never wrote any documentation before, and always struggled with writing descriptive content. The last time I did it was for my internship report and it was so daunting.

Try to make the writing exercise less about yourself. Who is the documentation for? A new hire or someone else whose never worked with this product before. Try to make the documentation exercise more about them.

If you were asked to ramp up on this product, what information would you want to know? How can you help others be successful?

A good technical leader isn’t just about to churn out code and make trade offs in design. A good technical leader is able to take a complex space and drive clarity for others.

You have an opportunity to disambiguate a topic here to help others. You get to choose what’s the right level of detail to provide.

1. A Medium article I read (sorry I couldn't find it) believed 'unproductive over difficult tasks' is because of not knowing where to start. And it's often hard to tell if it's the difficulty or the boredom stopping you from proceed. If this is the case, try to separate it into smaller tasks.

2. If your tasks are boring due to repetitiveness, looking for a way to automate it. It can be very satisfying teaching a computer with your profound experience and then watching it does your job for you.

3. Honor your tasks and aim for the stars. Taking writing docs for a software as an example, think about how to organize it so one can find the exact reference in a single search, how to keep it updated with least effort in the future. Great ideas and side projects can come from it, and you may have fun in them too.

I saw this a while back and it's really helped:

How to fight procrastination

Behavior = Motivation + Ability + Trigger

If you're lacking motivation: build motivation by remind yourself "why" (even if it's just "so it's done" but could be "do my taxes so I don't go to jail"). Add personally meaningful reasons to the tasks. Remind yourself why you took on the task.

If you're lacking ability: break down the task, make a timeline, build the timeline backwards from the due-date.

If you're lacking a trigger (like a task that can be done "whenever"): Create a cue. A cue is what+when+where. Take <15mins to decide which subtask to start with. If you still can't decide after 15mins, pick one at random.

I have difficulty with tasks that have no clear ending, like documentation. Sometimes it helps to tell people I'm having trouble with it:

Task: "Research and prepare for upcoming feature"

Me: "I'm having trouble with this research task, it feels like the task is to discover and document everything that will be needed to implement the feature, and the easiest way I know of doing this is to actually implement the feature and write down what was needed. I don't know where this thing ends."

Boss: "Just make a list of the existing project dependencies and put it in a Word doc and send it in an email." (Yes, this barely matches the original task description, but this happens often.)

Me: "Ok, I can do that."

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.

Personally I find it hard to get bored. When I'm facing serious work inhibition (anything worse than compulsive HN use) I take it as a serious sign to look for change.

Documentation is a big part of the "definition of done" for most projects, I've seen it make the difference between an open source project that gets users and one that doesn't. Probably the work that you want to do to finish a small project is 1/3 of the work that it takes to make it into something that connects with other people.

Outsource it if you can.

Otherwise I keep my brain entertained by multitasking while doing the boring thing : I’ll play a turn based RPG, or have German lessons or a Knuth lecture playing. Or music.

Theres a fine balance between distracting enough to keep your mind stimulated and engaged, and too distracting so you’re getting nothing done, so keep varying the task until you find one that clicks.

Also time your work, for me these boring tasks are better to do slowly in the evening when I’m tired, so it becomes almost a meditative / wind-down work

Your brain likes finishing stuff. You get a small award of dopamine whenever you do.

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 have three personal strategies:

1. Make a deal with myself to do some of the boring task (say an hours worth) before switching to something rewarding 2. Procrastinate until the consequences of not finishing the boring work are technically or socially expensive then rush into it desperately 3. Do it as a sort of down time or palate-cleanser, or a break from more challenging or stressful work

If you're anything like me, the hardest part is to get started.

Look at "Getting Things Done". Perhaps you need to dig deeper into what should you do next to get that documentation written?

For example, maybe it's just coming up with the outline. Or one smaller section. Or showing some example codes perhaps.

And as others have said, reward yourself with a treat if/when you complete (some of, all of) the task.

Maybe not a tip, but a perspective. Someone posted it here, and I've tried to make it my life.

https://jacobian.org/2021/apr/7/embrace-the-grind/

Here is my trick when it comes to documentation or even writing - I record myself doing a voice or video explainer - less daunting than blank page. Assume the audience are not techies... then transcribe it which end up being like editing & fun at the same time.

I try to trick or bribe myself mostly.

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

Force myself and time box it. Set up my workspace, pour myself a coffee, listen to classical music, and give myself a hard deadline. Not easy, but I find having the right set up gets me in that mentality to get it done.

This is my method.

- I make a list of things I need to get done.

- I risk and priority rank the list.

I then entirely ignore the risk and priority for each item on the list and instead do an extra 10 pushups, leg lifts, kegels and sit-ups for each item every day.

When I run into this I’ll try to block out some time to just get started on a small part.

Usually once I’m working on it I’ll keep going.

It also helps me to change my scenery, e.g. spend the afternoon at a cafe while working on it.

Go all in on the boringness. You can't fool your brain no matter how many Spoon-full-of-sugar songs you try to sing to make it go down easy.

Screenshot the usage of the software.

Get a wiki tool to let you paste the output in.

Write such connecting verbiage as is needful for the new user.

Get paid for it. If I’m billing $100-$150 / hr I don’t need my work to be entertaining.

For documentation, an approach that works for me is to think of all the questions someone might reasonably have about the software, and start with those as section headings:

* What is this?

* How do I install it?

* How do I use it?

* Is there a change log?

* What license is it released under?

etc

At some point when doing that, the content starts to flow and it gets easy to just naturally edit the whole thing into a doc that makes sense.

Amphetamine salts, how else?

Marijuana's the flame, heroin's the fuse, LSD's the bomb.

I get so bored, I write software to auto-generate that stuff.

If you look through the answers here, I already see much useful advice.

I just wanted to add this: I really don't think writing good documentation actually can be really boring -- and, if that was your impression up to now, I'd guess you haven't invested much into learning about good documentation yet.

On that note: I've had my share of encounters with people who thought "documentation" consisted of writing docstrings or -comments that repeat the name of each function or method in "human readable form". Yes, that's very boring. It's also not helpful at all and thus a giant waste of time.

Good documentation, on the other hand, makes you want to read it (okay, make that very good documentation[1]). It gives you a good TL;DR overview if you only glance at it, but it will also explain all the intricacies and mental models of a system in an understandable way if you spend more time with it. And -- in the case of source code -- it helps you solve the problems you likely encounter.

This isn't easy at all: If you as a programmer encounter a problem, you'll likely only look up related methods (from your perspective) and expect the information to be there. But only documenting single functions/classes/methods will make the documentation as a whole nearly unreadable, because there is no obvious thread tying everything together. So, I'd say, writing documentation is at least a task that is on par with designing and coding systems from a creativity and difficulty perspective. In fact, that there's no "automated" component (i.e. a complaining compiler) makes it more difficult: You're writing only for people, not people and computers.

Keeping that in mind, I'd say that a) it's worth to get better at documenting things (like with everything else, practice makes perfect) and b) I'd wager you won't find it all that boring if you strive to do so.

[1]: There's another comment on The AWK Programming Language somewhere. I would agree that this is a prime example of very good documentation.