“Reduce the scope, but stick to the schedule”

I’ve been trying to develop certain habits for the longest time. One of them is better consistency in writing. On this website alone, this is my 86th post, but I’ve had the site for a little less than 6 years now. And for the last few years, every now and then I’ve had streaks of 1-article-per-month. But at that rate, it’s not quite a habit.

Today I was listening to this podcast interaction between Tim Ferriss and the author of Atomic Habits, James Clear and while most of the content was familiar to me the way non-fiction dialogue is, this quote – “Reduce the scope, but stick to the schedule” struck me as extremely effective in conveying that which has been said a million other ways before – “Progress over perfection”, “Don’t break the chain” etc.

While the quote doesn’t require explanation, in the interest of extending this article and exercising the Wodehousian bean, what James Clear is conveying is simply that – If you intend to do something everyday, regardless of how Much of it you’re able to do, do it. Even if it’s for a reduced duration, over fewer iterations, lesser number of words, a smaller canvas – any lowest form of the comparative per the activity you want to perform.

So if for me that’s writing / publishing a tech/non-tech article, I should simply pick a smaller topic to write on I suppose.



The Non-Importance Of Being Complex

I think one of the biggest differences between someone who embodies a educator-mindset and someone who isn’t there yet but wants to be is –

An educator or teacher doesn’t think anything they’re teaching is beneath them or is too easy to beg teaching.

I started thinking about this when I saw time and again, experienced Python developers who I respect and have learnt a lot from talk and write publicly about topics that would be among the first ten things someone learning Python would be expected to have learnt. But this can be said for any other technical concept/subject/domain as well.

This distinction is something that’s prevented me from talking/writing about so many topics that I possibly could have. It’s not about how “basic” something is. As long as it’s something that you have learnt and believe even one person will be aided by it, it’s worth talking or writing about. This block falls flatly in parallel with the perfection-vs-progress block, except here, you’re i.e. I’m waiting to write or talk about something that is, in my mind, “complex”. Imaginary chokeholds.

But why should that be?

I can think of reasons extremely easily and none of them hold water in retrospect –

  • Anything easy is already done.
  • Anything easy would have been figured out without needing your documentation
  • Low hanging fruits are excuses for not wanting to think about or not wanting to put in the effort to learn and talk about more difficult topics
  • You’re limiting yourself when you limit yourself to easier topics

Two of these can be refuted just with a second reading.

  • So what if it’s already done? You’ve never put to the figurative paper your understanding of the topic yet.
  • So what if your document will not be referred? If you’re talking about topics purely and mandatorily to serve as look-up materials, you will always be left standing at the start line.
  • The third and fourth points are a little harder to fight. Might be merit in this. Every now and then you should push yourself to balance the easy topics with something a little more nuanced (that is not to say easy topics lack nuance).

The bottom line is something that everyone who’s ever decided to write something technical for an audience to read has been beaten senseless with –

Don’t think about the audience you’re writing for. Start with an audience of 1 i.e. yourself. Do the content justice. No topic is too easy to write about.*

(*) None of this is a guideline for journal based publications.