For a time, I tried to cultivate an interest in Go. Not this Go, but this Go. The interest didn’t last long – like chess, I had a hard time getting up to even a fairly basic level of competence. And I quickly developed another enthusiastic interest to replace it – sometimes, an interest just doesn’t work out, and it’s nobody’s fault, and you have to just move on and not get too sad, because there’s plenty of fish in the sea.
But one memory from this particular interest sticks out. I was reading a list somewhere on the Internet about Go etiquette, specifically the etiquette of playing with a more advanced Go player. Some of it was obvious – or at least obvious if you thought about it – like showing gratitude that they’re playing with you and remembering that they’re doing you a favor.
But there was one piece of advice that was less obvious: Don’t spend too much time making a move. Basically, this came out to “don’t waste their time,” but what it also came down to was, “your thoughts won’t help you.” They gave an example of a move someone had thought for 5 minutes before making, as if it was an obviously horrible move. It was not at all obvious to me why it was horrible, and I realized it was a Dunning-Kruger type of situation.
Basically, beginners at Go will often think very hard about their moves, trying to make the most out of their time with an expert, trying to not lose the game. But they don’t know how to think very hard about their move – their thoughts are unsupervised, and likely to miss something an expert would find very obvious. Their thinking time will be trying to avoid an outcome that is unlikely, and miss an easily-avoidable doom.
Rather than thinking beyond their actual skill level, their time is better spent getting through the game, and spending a more proportionate amount of time thinking. They will learn more this way, certainly more per minute of time spent – and in the meantime, they will avoid annoying a potential future mentor.
When I read this advice – and this was over 10 years ago – a light-bulb went on in my head. I realized this wasn’t just about Go, but about any skill. Perfectionism in early stages can be a self-defeating game.
A sign in my high school orchestra room boldly proclaimed: “Practice doesn’t make perfect; perfect practice makes perfect,” calling out people who just blew through exercise after exercise or song after song without actually trying to improve or find problems to fix. And that is truly a problem. But the opposite problem is also possible, where you work too hard on fixing all the problems in something, where you try to make your practice too perfect.
For another example: A friend of mine was once trying to learn German from scratch, using DuoLingo. I wanted to help her, saying, “try pronouncing these words aloud” or “read along with the lyrics to this song,” just trying to get her used to how letters corresponded to sound, and pick up a few words, and gain some familiarity with how they might be used, but she wasn’t interested in that, because she wouldn’t be able to perfectly understand everything.
Instead, she was stuck, completely stuck, on repeatedly saying very simple phrases into DuoLingo, trying to make her accent 100% perfect, saying, over and over again, for hours, “Das Frühstück hier ist lecker, oder?” until the phrase, with her particular pronunciation of it, was entirely drilled into my brain. She couldn’t hear what was wrong with her pronunciation, and she didn’t believe me that she was focusing on the wrong things. She didn’t believe that her pronunciation would get better with time, that her time was better spent moving on and learning more things to say. Besides, I said, it’s a far more practical skill to speak German with an accent than to say one or two phrases flawlessly.
But more importantly, you can’t get flawless pronunciation without learning more German. Needless to say, my friend’s approach made the process completely unengaging, and she soon gave up. But even if she had persisted, she would never have gotten it. Accents need to “click,” and that simply was not going to happen with only the one sentence she kept repeating in her repertoire. If it did, it would be imitation, and she would have no understanding of how those sounds changed in other contexts. She was insisting on starting with an imaginary, useless skill.
So how does this apply to me?
Well, this blog is finally moving again. And one of the (many) things I had to overcome in getting it moving is spending too much time trying to make each post “just right.” It’s not so much quantity over quality per se, but recognizing where there were diminishing returns, at my current skill level, to the work I was doing, and where posting (or not) and moving on to the next post would get me much better bang for my buck. They say that you need to write a million words of garbage before you’re a good writer, and so far my blog only clocks in at around 80K, which I think means I’m not quite there yet. But even when I’m further along, I’ll need to use my time where it’s most productive, rather than just spinning my wheels or trying to play 4D chess with my flawed mental model of my reader.
It’s all about the time management.
Which brings me to a related time management principle for me: Having lots of projects in flight at once. This one probably is more specific to me and people whose brain works more like mine (not just ADHD but perhaps even my particular flavor of ADHD), and it comes with the caveat that it only works for me when I have a well-maintained organizational system, but it’s a principle I’ve found super useful personally.
The reason to have multiple projects in flight at once, to be clear, is so that you can choose a project based on where you are at the time, and therefore always be making progress.
This has led to conflict in work environments. I remember when I was working as a web (frontend!) developer between junior and senior years of college, and there were dozens of tickets. I would pick off easy tickets sometimes in favor of the higher-priority harder tickets, especially early in the week, early in the day, or when switching to a new part of the codebase. I would do this fundamentally as a warm-up, a way to still be productive while I was gearing up and building up momentum.
My supervisor at the time called me out, told me I was supposed to focus on the higher-priority tickets. I told him that I saw them, had looked at them, didn’t know immediately how to do them, and instead of actively wracking my brain trying to figure it out, I sort of let myself process them in the background while doing some easy tickets. I told him that the alternative was taking just as long (maybe slightly shorter but honestly maybe even slightly longer) with the harder tickets, but not getting any easy tickets done in the meantime. Additionally, wasn’t I getting the harder tickets done at a reasonable enough rate?
I don’t know if he really believed me, but at the end of the summer they wanted me to take a break from college to work with them during the year, so it couldn’t have gone too poorly. I’ve since gotten better at managing my focus in a work setting, designing plans and TODO lists that work well for how I focus, and communicating pro-actively with supervisors.
But regardless of how well this principle applied (or didn’t) at that job, or at jobs since then, it applies super well to this blog.
I currently have, at the time that I am writing this paragraph, 4 on-going drafts for blog posts (3 non-technical, 1 technical). I have notes for 18 essays, notes and/or additional drafts for 7 fiction projects, and notes (ranging from spattered ideas to relatively complete outlines) for 23 tech blog posts.
When I have an idea – sometimes a new one, sometimes a thought that fits into an existing one – I can write it down in the appropriate place in my notes. When it’s time for me to write – I have goals on how many posts to finish per month – I can go look through the notes for one that is ready to work on turning into actual prose. And when I do, I can be picky: I can find something that I’m in the mood to work on right now.
If none of them really are ready to start cranking out prose, I can start developing one of the outlines a little more, which is often necessary. Every once in a while, even if I don’t plan on writing prose yet, I find myself thinking of good ideas, and start scrolling through the lot of them, tweaking notes, adding in detail, until they’re ready to mature.
This has been a really good system for me, and has allowed me to split up what can seem like super monumental tasks into actual achievable chunks. If I can’t stay focused on a single piece long enough to write it, I can put it on the back burner, come back to it, and still be producing content in the meantime, sometimes from newer ideas, but often from pieces that I previously put on the back burner.
I’m looking forward to seeing how well it works for fiction. I’ve still not fully dusted off my fiction projects, though I hope to soon. But I hope that the non-fiction, essay writing type of stuff – and maybe even the tech writing – still count towards that 1 million words, and still help me become a better fiction writer when I get back to it.
In the meantime, I’ll keep crankin' out the posts.