Mentoring Arun : Vol 3

Arun talked about how he found the Radical Candor talk (see the previous blogpost) very useful and how he had his first short radical candor talk with a junior at his work place. He mentioned that he found it useful to understand the other persons perspective and he mentioned how the other person pointed out things that could have helped them. I then asked Arun if he could improve the onboarding document that their company has for new employees based on their discussion. When a discussion has meaningful outcomes, especially outcomes that can be applied to an entire group of people, it's a good idea to document them instead of letting the information sit in peoples' heads.

He then mentioned that he found the Randall Koutnik talk (see the previous blogpost), specifically that it helped him understand how to break down work before delegating it and how he could take the capabilities of a younger employee into consideration when breaking down the work for them. If you haven't watched the talk, I highly recommend it. It's a talk I watch a few times an year because it helps me judge my professional progress and it helps me work with junior employees effectively. 

Arun has been reading the Software Engineering at Google book, which I have not read personally but I've heard very good things about. I asked him if he is reading it together with a group of people, maybe his work colleagues. I told him that we have a software architecture reading group at work, which I have found very illuminating, because it is illuminating when everyone in the group interpret the same text differently. You learn a lot more from discussing a book than reading it solo, in my humble opinion.

One of his long term goals is to understand CPython better and towards that goal, he looked into PyEval_EvalFrame but he isn't sure how deep he should go and where he should stop. I wanted to take a step back so I asked him why he wanted to understand CPython better and he mentioned that he wants to get good at CPython. I asked him to read the entire Python Standard Library from start to end because that's one of the steps towards mastering CPython (or any other tool that you use day after day). Going further, reading code and trying to understand the documentation might work for some people. For others, it might be better to actually write code that uses the various pieces you want to understand. Towards that goal, I asked him if he can make time to write Cython code. Writing Cython code is much easier than using the Python C-API but it is highly relevant. Going further, I told him to write examples using the Python C-API because that's how you can start understanding the minimum C-API you need to learn to start using it. Personally, this has been my approach. It's pragmatic to learn just as much as is needed to get things done. It would be nice to spend time learning about all of the esoteric aspects of the tools we use but we live in the real world with time and monetary constraints.

Arun mentioned that he is proposing a new feature, his potential first big contribution to the project. He proposed the feature in an open forum so I was able to read the proposal. I asked him if he has read PEPs and if he could update his proposal to be more like a PEP. I love reading PEPs because they are a labor of effort. The authors spend a lot of time discussing the underlying problem, justify the fact that this actually is a problem that the project should care about, point out the potential upside of fixing the problem with a new feature. Only then, towards the second half of the PEP, do they propose a solution. Not THE solution. A solution. It's important to understand that when you propose a new feature as a GitHub Pull Request, the project maintainers might have a difficult time imagining a different approach to solving the problem, and might review the solution at a superficial level. Instead, by focusing on the underlying issue, you allow the maintainers to form solutions in their minds, which they can then try to consolidate into the proposed solution. You can see this happen with PEPs because they go through multiple iterations where parts of the original solution are discarded based on peer review and in some cases, an entirely different approach is accepted when compared to the solution originally proposed when the PEP was drafted. It takes time and energy to write, in detail, about the problem, but from what I have seen, it's a habit that pays off for the writers in the long run and it helps the project stay lean and robust.

Finally, we talked about working from home and staying motivated when working from home. A lot of us (most? all?) have experienced days when we can't get out of bed on a weekday. I mentioned to him that I have a stack of mindless tasks that I undertake on such days. Tasks like closing issues that were solved but we forgot to close, responding to issues that are lacking necessary information, updating dependencies to new versions, adding type hints, etc. More importantly, I pointed him to Spaceship You by CGP Grey, one of my favorite YouTubers. In the video, CGP Grey talks about strictly separating the place where you work, where you relax and where you exercise. Watching YouTube videos at your desk is a no-no. Working from the couch is a no-no. Not having a specific exercise zone is a no-no. If you're sitting at your desk and staring blankly at the monitor, get up and go for a walk. Lie down on the couch and watch YouTube. And some time later, try coming back to the desk and see if you're able to get to work. This requires constant effort and a lot of discipline but I think this is a superpower that people that mostly Work From Home have. The discipline that they develop is, in my opinion, something that most office-goers don't have to the same extent because they rely on the physically separate spaces. Seriously, if you have the time, watch the video. Like the Randall Koutnik talk I mentioned earlier, it's something I watch a few times an year to remind myself what the right thing to do is.