Welcome to my fourth post! During March, I managed to complete several large and important sections of the course — I will be able to finish the rest of it by the end of this week. This post will primarily include answers to reflection questions, additional wisdom I’ve gained from my mentor, as well as the routine progress report in the form of a log entry.
-
What has been your most difficult mentoring challenge so far? Why?
My most difficult mentoring challenge with my mentor, Bill, is something I did not expect, and in fact, dismissed in Post #3. These are the logistical challenges — meeting through Zoom. Although meeting online has its benefits — it is convenient, efficient, etc. — the two meetings I’ve had in March have shown otherwise.
To start with, we have had some technical issues, with both of us receiving various, “Your internet connection is unstable,” messages. Zoom has crashed several times over the two meetings. Additionally, the audio quality is shaky, often breaking up, and background noise can frequently be heard coming from both ends.
Though this is less of a problem from Zoom itself, another issue I’ve had is not being able to see my mentor’s face since the device he uses (or the place he is at) does not have a camera. For the first few meetings, Bill seemed to have managed to find a solution, but it seems that he has not been able to more recently. Not being able to see a face is worse when I am speaking, for I get less visual/real-time feedback, hindering the experience.
All in all, however, the meeting experience has been quite good — I have managed to communicate all my questions and Bill has been able to answer them.
-
What is working well? Why?
Beginning with my part, I have continued to come prepared to each meeting with a plan and the questions I have for Bill. The former meeting had more questions regarding the content I was learning, while the one we conducted this Wednesday involved high-level overviews of the process and more job-related questions (more on this later). Bill, as always, provided excellent, clear answers with large amounts of detail. Indeed, even when he did not know a specific concept I asked him about (Python is not his primary language), Bill simply went straight to the documentation, digested the information, and explained it to me — he can always understand better than I do with his vast experience.
When presenting my progress, I easily shared my screen and walked through the concepts I covered since the last meeting — Bill would occasionally comment and offer advice. He was very encouraging, cherishing my learning (even congratulating me for my progress at the end of the second meeting) while simultaneously demonstrating his enthusiasm and passion for what he does. As I’ve reported before, we have continued the practice of me laying out my plan for what I would like to achieve before the next meeting, and again, the sense of accountability has served to motivate me.
Bill’s method of teaching also works like magic. Slowly but surely, he has given me the tools to create the COVID-19 simulation; currently, I know enough about Python, the process, what to focus on (described later), and what to do when I don’t know about something to feel prepared to go through the entire process once and for all. There are several ways Bill has done this: First, he has taken care to answer each one of my questions, and for many, he has elaborated more in specific directions based on what he believes will be useful to me. Second, he has emphasized certain ideas that are crucial to understanding when developing a program from start to end. Finally, when describing complicated topics, he makes sure I understand by giving examples and often illustrating them with images.
-
What can be working better? How do you make sure this happens?
Something I feel can be working better is related to screen sharing and taking advantage of media. In a previous post, I described Bill’s use of the screen sharing feature, which made understanding the concepts he described much easier. While I still do share my screen every meeting, he has not needed to do so — it almost feels like a missed opportunity and would certainly heighten the quality of our meetings. Indeed, I can recall several times where I simply stared at the blank screen (without his face either, although there is nothing we can do about that) while listening to Bill talk.
The roots of the issue, I believe, are my questions. Recently, they have been less about problems I don’t understand, and although sometimes illustrations may be helpful, they are not necessary. As a result, asking more questions such as, “How can I accomplish this using Python?” and, “Can you illustrate this concept to me? I don’t understand it,” instead of, “What is a strategy you found useful when first coding?” will more likely result in Bill sharing his screen. I should simply ask less of the former, especially since the next month will focus all on the COVID-19 simulation.
Another principle I should follow is the idea that “Ask and you shall receive.” The reality is that oftentimes many of our problems can be solved if we just ask — after all, we have nothing to lose and everything to gain; if you do not get the answer you want, you only end up in the same place you were before asking. Thus, whenever I feel that my questions would be best illustrated by Bill sharing his screen, showing diagrams, videos, or even drawing something on a digital whiteboard, I can ask with a high probability of him saying “Yes.” This can also apply whenever I need something from Bill — I must not be afraid to ask.
-
Wisdom/answers from Bill!
When completing a Blackjack project for the course (see progress report), I was very disorganized — I could hardly keep track of all the classes and methods I created. Naturally, I posed a question about how I can be more organized to Bill. He suggested that whenever I create a program, I should divide it into different sections (e.g., main classes, functions grouped by purpose, etc.) with each in a separate file. Not only does this make it easier to make sure each segment is working as expected, but it is also easier for collaboration when working with others. We can then also take advantage of modules and packages (described in the progress updates from Post #3) and then simply import each when the time comes, bringing it together into one main file.
In the next meeting, Bill also re-emphasized the importance of understanding the concepts and tools you have access to well and knowing when to use them (for example, in the case of advanced modules and packages — described in the progress report), stating that the programming language and the coding itself is just a small part of the implementation, which is only a stage of the overall development process of solving a problem. Indeed, you can quite quickly learn new programming languages after learning your first, and many problems will require several to carry out different areas. But what is the process exactly? Put simply, when I begin the simulation, I should make sure to understand the problem (Bill explains that the requirements of programs he creates are often very complex and can change), develop a clear solution, and then finally use Python to implement it. When working on the solution, I should start by coming up with a high-level overview of my solution — what classes I will create, what each does, the major formulas I will use, how I will fulfill my requirements, etc. — and then move on to the specifics — exactly what methods will I have inside each class, the modules will I use, how I will bring everything together, etc. This can also all be applied if/when I get my first job in this field!
During the first meeting, Bill also helped me to understand concepts — for example, decorators, errors and exceptions, etc. — that I was somewhat confused about. For the former, Bill explained that decorators are simply a way to modify an existing function by passing it in as a parameter to another function, which has another wrapper function inside that actually makes the modifications (details and illustrations in the progress update). The wrapper is returned, then assigned to the original function, thus modifying how it works. Python can make the entire process simpler using the “@“ keyword. Decorators are most often used as a way to easily modify/customize “templates” from other sources.
For the latter, Bill explained the importance of making sure that a single error does not resulting in the entire program crashing. Often, several “general” try/except statements are placed just in case to try to catch unknown issues. Exceptions handling can also play a part in complicated logic where they can be used instead of if/else statements because they have the ability to “catch” scenarios anywhere/anytime, even outside of the local scope/file, where instead if/else loops must have the “requirement” caught immediately. Regarding bugs in programs, Bill states that a complicated program will almost always have bugs (it is very difficult to catch all possible bugs), but as long as there are not any major bugs, it meets the requirements of the solution (given to you at the start of the development process), and it is sufficiently tested for user usage, it is fine. The development process in question commonly involves following the Agile philosophy.
Finally, my goal for our next meeting, as according to plan, is to have understood and outlined my requirements for what the COVID-19 simulation should include and created the solution itself. Bill has been an outstanding mentor who has again proven invaluable on my journey! Once this project is over, I will find a way to show my appreciation. The progress report is attached below.