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.
Ask HN: How do you force yourself to do boring tasks?
51–60 of 60 posts
Re: Ask HN: How do you force yourself to do boring tasks?
#52I 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.
Re: Ask HN: How do you force yourself to do boring tasks?
#53Improve 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 https://archive.org/details/pdfy-MgN0H1joIoDVoIC7
Re: Ask HN: How do you force yourself to do boring tasks?
#54Go 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.
Re: Ask HN: How do you force yourself to do boring tasks?
#55I 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
Re: Ask HN: How do you force yourself to do boring tasks?
#56Cut 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.
Re: Ask HN: How do you force yourself to do boring tasks?
#571. 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.
Re: Ask HN: How do you force yourself to do boring tasks?
#58Improve 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…
+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].
Re: Ask HN: How do you force yourself to do boring tasks?
#59If 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.
Re: Ask HN: How do you force yourself to do boring tasks?
#60Editing 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…
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.