In the past two weeks, I have made significant progress in my Python course and had my second meeting with my mentor, Bill. This post will analyze some aspects of our learner-mentor relationship and also provide a detailed progress update with wisdom I have gained from Bill. Note that I explain all of the concepts I discuss in the progress update/log attached at the bottom of the post.

1. What went particularly well during your mentoring sessions?

First, I have noticed how comfortable and relaxed the environment of our meeting sessions is. Not only do I feel calm and open – ready to freely share my thoughts and questions without trepidation – but I find myself becoming more passionate and enthusiastic about the topics we are discussing, especially as they become increasingly complex. Furthermore, Bill’s explanations (described in section four) are extraordinarily enlightening and easy to understand, which serves to further my interest.

After only two meetings, we have fallen into a type of routine. As perfectionistic and controlling as I am, I come prepared for each meeting with a simple meeting plan made of questions I have. I start by sharing my screen and outlining what I have accomplished. Then, I ask my questions, and amazingly, Bill always provides detailed, informative, and engaging answers.

How? To start with, after describing a concept, Bill would frequently ask if I understood. Depending on my answer (sometimes, he would do the following regardless), he would further illustrate his points and explanations through examples. This leads to his method of describing concepts: A frequent use of visual aids, whether they were diagrams, videos, webpages, a text document, or even a whiteboard – a huge help. Finally, Bill related concepts to what I have already learned and took great care in knowing every detail. In one instance, he brought up polymorphism (details in question four), a topic that I had not even mentioned, but which he noticed was on my screen (for only a few seconds) when I projected it.

2. What learning challenges emerged?

Thanks to the flow of our meetings, I have had very few learning challenges in the past couple of weeks. The time management issue that I described in my first post has largely been solved, a direct result of the solution I put forth – time blocking. I have consistently been able to achieve at least 30 minutes of Python per day, a feat made much easier by the aforementioned passion and increased interest in the topics I am now covering.

A practice I naturally fell into to hold myself accountable was to list out my goals to be completed by our next meeting – which I laid out at the end of the session. Whenever I feel unmotivated, lazy, or tired, I automatically remember the promises I have made to Bill, as well as the shame I would feel on missing the valuable advice I gain from each session. Indeed, what would be the point of meeting and wasting Bill’s precious time if I make no progress whatsoever from our last encounter?

3. What logical challenges affected your communication?

The ideal scenario would be to meet Bill in person since virtually everything – speaking, demonstrating, etc. – is easier. However, this is impossible considering the pandemic situation.

Even so, communication has been exceedingly easy and unchallenging. With Zoom as our meeting platform, we have not experienced any audio, video, or technical complications whatsoever! Bill and I have been able to share our screens, and even recording the session has been impeccable as well. Lag and background noise are virtually nonexistent. At one point, I had a question regarding debugging in Visual Studio Code (described next), the platform Bill recommended I use day-to-day with Python. He simply asked me to share my screen, open a program (I opened a Tic-Tac-Toe game – details in my log entries/progress updates), and gave clear instructions, which I followed. In a couple of minutes, my question was answered.

In short, in terms of logistics, my meetings with Bill were nothing but flawless.

4. Wisdom and progress.

Having covered object-oriented programming (OOP), I had a major question: When exactly do we use OOP? And why use it over functions? Apart from the obvious – classes (used to create objects) offer more structure, making it easier to have a high-level view of the different “roles” in a program – Bill offered two thought-provoking arguments. Firstly, almost all programs involve users, ranging from applications and websites to operating systems. Classes allow for “encapsulation,” building an extra layer of security and privacy. Put simply, the idea is to bundle everything related to an action/data into a single unit, so that everything else is hidden and restricted when that unit is called. An analogy is a finance company – different departments handle what they are responsible for and are not allowed to directly access data from another. Especially when it comes to sensitive information, allowing information to be retrieved anywhere is not a smart idea. In Python, there are specific modifiers (symbols) used to determine the encapsulation of data.

Another reason is polymorphism and inheritance, which Bill visually represented on a whiteboard. The concept is simple: A base class can be created (essentially a template), and new classes can inherit the attributes and methods of the base class. Then, the contents of these attributes/methods can be modified, but they can still be called under the samename. For example, a base “Shape” class might have a “calcArea” method (known as a virtual method), which new classes “Rectangle” and “Circle” derive/inherit from it. You can modify (override) the formula under calcArea (namely  and  for circles and rectangles respectively) but when you ultimately call “calcArea()” for an instance of a Rectangle or Circle object, you use the same method name even while returning two entirely different results.

In response to another question of mine, Bill outlined the OOP design approach, which will be helpful when I begin my COVID-19 simulation. He pulled out a
diagram on the web (shown on the right) known as a “use case diagram,” which depicts the different roles and responsibilities programs have. It can be thought of as a restaurant (the system) and its clients/people (“actors”), and how they interact with each other. Depending on the program, the different actions labelled in the diagram are either functions or classes. As a piece of advice, Bill suggests when starting to try to quantify and outline how many actions, actors, roles and concepts are needed in the program.

For the COVID-19 SIR model simulation itself, Bill and I discussed my plan. Since our last meeting, I had researched resources I can use, and settled on Matplotlib as the graph visualization library of choice. As per a simulation on YouTube and similar ones online, Bill recommended that use multiple graphs – for example, a classic trend graph along with a scatter plot to represent the population, like in the video above. However, he also made sure to emphasize the importance of starting simple; if I want to make the program more complicated, I can do so afterwards if time allows and I am having fun!

Finally, Bill helped to settle a nagging question I have had ever since starting with Visual Studio Code. After sharing my screen and opening a program, Bill told me where to click – it turns out that all I needed to do was add breakpoints beside the line numbers. Then, when I run the debug option the program will run only up to the breakpoint and stop, where I can then see all the variables I have and step through the code, line by line. It is genuinely wonderful how Bill helped to solve a confusing problem in just a couple of minutes.

That concludes this third post on my journey with Python. For a detailed progress update, see the attached below, where there are two new log entries!

(In-Depth Log) P.S. Now with a Table of Contents and even more images!