Comment by yeukhon

I echo the author's point in "Review the code with its author in mind".

Without comments, sometimes it's really really difficult to navigate the code. I have been adding more comments than ever: don't assume every line is obvious, write a comment to explain what the next few lines really do.

    # base case: stop dividing when we find the largest square.
    if width == height:
        return width, height
    else:
        # otherwise, we know that we can break the land into several
        # pieces, some are already square-sized, but there must be
        # left over, which is the difference of the width and height,
        # and can be divided again.

        remain = abs(width - height)
        return largest_square_plot(remain, min([width, height]))

^ This code is only for me to read so I didn't really care much about grammar... but a year from now I shouldn't have trouble understand the code in a minute or two.

Some of my function/method has a pretty long docstring which may include explaining the rationale, and perhaps even some ascii diagrams. If you have trouble understand a piece of code after a few passes, that's a bad code. Also, use more newlines...

> I check every Github email I get; I make sure that I don’t get notified for everything that happens in the repo

Not sure about others, but I am tired of reading PR notifications in my mailbox. I don't know how kernel developers can live with this.

I have been thinking about just build a bot.

* receives PUSH from GitHub

* adds events to a queue

* notifies based on priority

* pings me once in a while to remind me that I have outstanding PRs to review (as reviewer and as author of the patch).

If someone needs me to review right away, he/she can reach out to me directly in chat.