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.
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.
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.
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
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.
This seems like a fantastic specialized tool to have in the mental tool box.
e.g,. Have it write 75% of an essay and modify from there
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.
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".
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..
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.
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
To provide another example for documentation I found to be similarly well-written is the guide on dtrace.org [1].
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.
- 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 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...
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.
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.
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.
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.
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.
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 bribe myself with small chunks of nice chocolate as well sometimes
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.
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.
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
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.
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.
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
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.
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.
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:
and use Mac's OmniFocus for the lists, as such.
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
https://www.amazon.ca/Work-Clean-life-changing-mise-en-place...
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 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.
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.
Get a wiki tool to let you paste the output in.
Write such connecting verbiage as is needful for the new user.
* 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.
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.
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.