Hi everyone!

I saw that a lot of people write meta blogs recently. As my blog count approaches 90, I feel like it may make a lot of sense to write another one that kind of focuses on the philosophy behind my blogs and explains potential readers what they should expect from my blogs and how to approach them. So, without further ado...

Tldr.

1. Read my blogs if and only if the general setup itself appeals to you. Don't feel obliged to do it to get better at competitive programming.
2. Don't be driven away by seemingly dense math notation if the topic looks interesting. Ask questions if something is difficult to comprehend, I will explain in a more detail and it will help others too.
3. Be ready to fill some possible gaps in the story yourself, as an exercise.
4. Be open-minded about analyzing setup in general, rather than working towards predetermined goal.
5. Be prepared to see too little explanation on how abstract nonsense from my blogs connects with concrete applications.
6. Give feedback, it motivates me a lot and helps make future blogs better.
   

Be interested

First thing you should decide for yourself when reading my blogs is to understand if it is of interest to you. And I want to be as transparent here as possible, my blogs are not designed to be useful for competitive programming. I mean, of course I have some blogs that might be, but only in very rare circumstances I have a goal of helping someone perform better in competitive programming when writing a blog.

My main motivation is to share something that I found interesting or fascinating in one way another, and I mostly expect the same motivation from any potential readers. So, in my opinion, most of the time you can decide on whether you should read my blog or not by reading the title and skimming through first 2-3 paragraphs. Does the setup and the problem at hand sound exciting to you? If yes, please tag along for the journey! If not, you probably won't miss anything important by skipping it :)

Don't be afraid

One piece of feedback that I often get is that my blogs are scary, and many potential readers think that they require some very advanced math to comprehend. For example, it seems that many people assumed that my blogs on combinatorial species require some advanced knowledge in category theory. In reality though, while there were some links to category theory stuff in the blog, they only scratched the very surface and very basic definitions of the subject, which I myself only got to know while writing the blog, and all of it was defined in the blog itself, so it was not a requirement to be familiar with the concepts in advance.

I may have a lot of links to advanced stuff, e.g. Wikipedia pages, in my blogs, but their purpose is mostly to provide additional context and some connection to a grander picture, as well as some opportunities for further learning to a curious reader, rather than to indicate some kind of prerequisite for reading the blog. I try, especially in later blogs, to be more or less clear about the hard prerequisites for reading my blogs (and try to keep them low whenever possible).

If you really struggle with understanding something, but the topic is interesting to you, feel free to reach out to me directly, I may try to explain some stuff in a more clear manner, or even improve the blog a bit :)

Be ready to think

Another piece of feedback that I often get is that my blogs are often terse and lack examples. While I try my best to act on it in my later blogs, I think that in learning it is generally very important to be able to come with your own examples and think through tersely described explanations to fill some gaps on your own. I recognize that it might be unpleasant to do so, and I'm trying to ease your pain, but ultimately I think that the best way to really understand something is to read some very high-level description and try to reinvent it based only on that little information that you have.

I think, this is the best way to develop your own intuition, and carve a better, simpler path to something that others take for granted. I spend some crazy amount of time doing just that, trying to reinvent the wheel, to come up with my very own examples and ways to define and do things and this is exactly how I managed to come up with the stuff described here or here or here or here or here or... Well, you get the idea. I learnt and found out so much in exactly this way, I couldn't recommend it enough :)

Accept that the journey is more important than the result

I once received a piece of feedback that there are essentially two ways of explaining things:

1. From result to research. This is western approach, when we start by clearly defining the end result towards which we are working first, and then explain how we reach it.
2. From research to result. This approach is more common in the eastern part of the world (say, in Russia). In this way, we do not have a pre-existing result that we're working towards, but rather we start with a generic, somewhat obscure, setup and just analyze it in detail, to learn what results follow from it.

While the first is argued to be much better for understanding, as it is easier for people to connect what we're doing right now with what they're going to get in the end, I vastly prefer the second approach. There are quite a lot of reasons for it:

• It is what you naturally do when you approach new open-ended problems. You do not know in advance what you will get when dealing with the problem, you do not even know if you will find out anything at all. You start with a setup, and you find the conclusions about it, you analyze its properties, until you eventually find out something of interest. Thus, more often than not, I write things in this way simply because it corresponds to how I found them out in the first place.
• Generally, proving the known result and finding out a new unknown result are vastly different things. A lot of textbooks just give you the theorem and provide with the simplest or shortest proof available. While such proofs may be shorter and easier to comprehend, they throw away what I think is the most important part: reproducibility. You should generally be able to reproduce the result even if you forgot some details about it. And motivation behind the proofs play tremendous role here. If you understand the motivation, you're likely be able to reproduce the proof just using the same natural reasoning. If you don't, most likely you won't be able to reproduce it.

And I can't stress enough how important it is, in my opinion, to provide motivation for any step that you make. When you start with a setup and do not know the result beforehand, motivation most of the times is very simple: you just do what you think is natural to do to analyze the problem. Structuring the blogs in such a way, generally, allow me to avoid a pitfall of many textbooks when they have a sequence of lemmas that eventually allow you to prove the end result, but for each of them, you have no idea why would you ever make such assumption of you were to analyze the setting on your own. Yet, I hear the feedback, so you may notice that in my later blogs I try to provide some additional insight as to what are the core results and applications that we're going to derive.

Think abstractly

Okay, this is a bit of my personal preference towards abstract nonsense over concrete stuff. I feel like, generally, concrete formulations often have a lot of diversions. You may be able to solve concrete instance of the problem, but if it is some kind of approach that may be applied to many similar problems, it is important to understand what is the actual underlying structure of the things at hand that allows them to behave in a similar way.

And it is much better when we're able to unearth this underlying structure that connects different instances of similar problems together. While it may seem that analyzing concrete examples may shed some light on what's going on, my personal experience tends to say that it is too easy to get distracted into a very specific way of doing things and miss the common structure if you work with concrete stuff too much. This is also the reason my blogs lack examples that often. I don't work with them much on my own, and even consider them harmful to some extent :)

Give feedback

I can't thank enough all the people who reached out to me to tell when something in my blogs was difficult to comprehend or plainly wrong. While I may not always be able to right all wrongs, I take feedback very seriously, crave for it (well, yes, I am an attention and validation seeker alright) and try my best to act on it. So, if you see any issues in my blogs (or contrary to it, like it and want to praise it), please feel free to tell! This will help me in writing future blogs, and give me some motivation, as I would know that the blogs are of interest to somebody. I must say that these days it especially warms my heart when someone I barely know approaches me in real life and tells that my blogs helped them in one way or another :)