Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: How do you force yourself to do boring tasks?
62 points by throwawaydoc22 on Dec 29, 2021 | hide | past | favorite | 58 comments
I've been struggling with writing documentation for a piece of software that I've been working on during the past months.

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.

Any tips? Thanks.



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.


>This is how I get myself to the gym a few times a week.

I don't have a gym membership, but maybe that is a price I should consider paying, as I might be more motivated to not waste money I've paid.

While I am able to go outside for long, brisk walks fairly often, I completely neglect the equally important stretching and resistance training (weights) exercises because I find them so boring. Even if I keep it going for a few weeks, I inevitably stop because at home, there is always something I find more appealing to do than even 20 minutes of boring stretches and weights.


This was a huge help for me. It's amazing how my attitude to going to a trainer changed when I paid up front. I was actually getting upset one day when I thought I had gotten less than the hour I paid for. With video workouts and monthly gym memberships, I had never thought of ending a workout early as losing value.


This is great advice. Just getting started is also the biggest thing for me. Once I get started, it's usually easy to just keep going


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


If I could upvote this more than once, I would.

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.


Interesting -- I wouldn't have thought of that.

However, I usually use an approach that isn't all that different: Initially, just make some notes explainig what the document you write should contain.

I use org-mode style nested bullet point for this. This is also nice because you'll have to start with defining "goals" for your text: What should it explain? Which points are most important? Are there "gotchas" you should keep in mind?

After that, I start expanding on those bullet points. Also, there will be a couple of iterations of "refactoring" until I'm sure what the best way to structure the text will be. Having written down the basic goals first -- and thus having a more complete overview in mind -- helps with that, too.


> auto-generated 50 pages of Lorem Ipsum

This seems like a fantastic specialized tool to have in the mental tool box.


Right now they could probably use gpt3 to generate like actual text that's probably 75% of the way there.. get a lot further than lorem ipsum ... and easier to edit.


You just made me consider how gpt3 might impact things like school assignments.

e.g,. Have it write 75% of an essay and modify from there


Back in ‘07 lorem ipsum was all we had (easily available) :)


> 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".


I'd disagree... I often feel a task is 'boring', or maybe 'complicated' and it's not that It's beneath me, it's that it feels like it'll overwhelm my ADHD brain, so I procrastinate till the last minute, at which the adrenaline makes me do the best job i ever would have anyways... but boring is why I don't do a lot of things I should...

even as a kid my biggest fear when doing anything was being 'bored'... I have a very talkative inner monologue and I guess we don't like having to talk to each other, when you're not 'bored' you're too busy to be contemplating stuff.. Probably why I also spend a lot of time needing new input from reddit or hackernews...

Though I have been meditating more, and when I found out I had ADHD at 38, meds helped greatly...

My advice for tasks like this though is set a deadline, and if you miss the deadline it's fine..but it'll put you into oh shit it's due mode, and you'll get the procrastination inspiration to finish it.

Alternately schedule on the calendar dedicated times when you'll either work on it or stare at the computer monitor and work on nothing else and no interruptions... maybe you can use a journal and free-write shit or doodle if you are doing a creative task like writing and are 'blocked' ..it sometimes helps get unblocked to just stare at a doodle as your subconscious churns..


Thanks, I like the idea of looking at documentation as "programming other people to be able to work with the tool he developed".

When I said boring, I didn't mean it to be "beaneath me". On the contrary, I actually find it quite challenging, but not the kind of challenges that I enjoy. For some reason, I simply hate doing it.


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


+1 on "The AWK Programming Language". I'm a big fan of the book (in fact, I just purchased a copy that is as old as I am from ebay, just to own it. I originally read the version on archive.org).

To provide another example for documentation I found to be similarly well-written is the guide on dtrace.org [1].

[1]: https://dtrace.org/guide/preface.html


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.


If you are not the kind of person for whom inventing artificial rewards works, you probably can do the opposite, leverage Pavlov and associate the cup of coffee to getting started.

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.


This works for me too.

I bribe myself with small chunks of nice chocolate as well sometimes


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.


> Your brain likes finishing stuff

Person with adhd here. No it does not. It’s quite content to give me that dopamine at 80% and then let me wander off to the next interesting thing.


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.


> Look at "Getting Things Done"

Is there a link you could share? seems like a pretty vague thing to google, and it’s not immediately clear if you’re referring to a book, blog post, video, etc.


Probably the book/system by David Allen. It has a cult-ish following. The google results aren't very vague about it:

https://www.google.com/search?q=getting+things+done

I tried the book. It seems nigh unreadable due to fluff and the author's ego. (I think some reviews say the first edition is better.) However, the system seems good for what it is in principle. (It looks like a well-thought out to-do list system with things like pruning the list not left to chance. It's not a miracle or a silver bullet.) I learned with this:

https://hamberg.no/gtd

and use Mac's OmniFocus for the lists, as such.


Thanks! I haven’t ever heard of it before.

Could any cultist comment on if it has useful suggestions for maintaining said system?

I’ve got a cycle of organization/chaos, where I organize myself, but then over time start to lose the motivation to maintain it and it deteriorates into chaos…until I get fed up with the disorder and build up some method of organization.

It’s mostly adhd/o.d.d. fueled, and I’ve been struggling to find a sustainable way to find some sustainable quasi orderly middle ground


I tried to use GTD for quite a while. I abandoned it in favor of Timeboxing, using Work Clean for the precise implementation. I used org-mode to put it to use, it's flexible enough even though GTD was a big influence on its design.

https://www.amazon.ca/Work-Clean-life-changing-mise-en-place...


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?


They sure do make a big difference! Couple with a low distraction environment so that the benefit is used on what it’s intended to be used on, and not on something more interesting.


Cocaine?


Tends to wear off too quickly - amphetamine salts are cheaper, definitely last longer, and even come in extended release forms. they can also be prescribed, so that’s nice.

cocaine’s more fun though, I’ll give you that. and would probably make for a good reward system. Write a paragraph, do a line. I wouldn’t recommend a 1:1 write a line to do a line ratio.


Easier to get cocaine than a prescription for amphetamines.


If you can get it done in half an hour and it pays for the fuel.


Wasn't the commenter implying Adderall?


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.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: