Week 3 - September 21st to September 27th, post-Sprint

What I Did This Week

- Learned a bit about how Freeseer exports .csv files, and for that matter, what .csv files are for. (1 hour).
- Read the w3schools guide to SQL in order to better understand how Freeseer stores talk information in a database. (2.5 hours).
- Learned about .rst files, enough to make some changes and create pull request #599, which included some additions to the Quick Start guide. (2 hours).
- Learned how to squash commits and write long commit messages in the styles recommended by the Best Practices. (0.5 hours).
- With Michael Tom-Wing's help, wrestled with Git for a while in order to successfully squash the commits made for pull request #599. Also spent some time reading about QCompleter in order to understand TalkEditor.py. (1.5 hours).
- Took a closer look at TalkEditor.py functions select_talk, talk_selected and apply_changes to understand them better, with the ultimate goal of figuring out how to fix issue #501. (1.5 hours).
- Wrote this blog post. (2 hours).

What I Intend to Do Next Week

- Understand more of the functions in TalkEditor.py, with the goal of fixing issue #501. Try to find an excuse to ask for help in IRC or the mailing list, in order to help overcome my fear of initiating interaction with others -- after all, you're not a very frightening group of people, I just get very irrationally anxious.

Problems

- I still haven't figured out how to fix #501. I believe that this is because I still don't know enough about how QTableView works and which methods in TalkEditor.py come into play when you click on a talk in the table, and exactly what those methods do. It could be that there's no shortcut, and I just have to power through and learn how all this stuff works.
- As mentioned in "What I Intend to Do Next Week", I get very anxious about initiating interaction with others, and as a result, I don't believe that I have communicated enough with the rest of the team. I am hoping to look for an excuse to ask a question when I look at TalkEditor.py.

Discussion

I'd like to start off with a joke from Annie Hall, a movie I borrowed from the SFU library this week. Alvy (Woody Allen) and Annie (Diane Keaton) are going to two different therapists and talking about their relationship with each other. We see their respective therapy sessions on the left and right half of the screen.

Annie: "We have sex constantly -- two, maybe three times a week."
Alvy: "We hardly ever have sex -- two, maybe three times a week."

What the heck does this have to do with UCOSP and Freeseer? I've mentioned before that I have trouble getting up the courage to mention when something is confusing me and ask for help. However, one of the ideas that the mentors have tried to drill into us, and rightly so, is to communicate early and often about whatever we're working on. I am aware that it is completely irrational of me to be worried about bothering my mentors, because they're there to help, and they have yet to show any annoyance at my asking to help them. This is a fear that I am gradually trying to overcome, but I do think it will take time. As a result, I had this nightmarish vision of myself being evaluated at the end of the semester:

Me: "I communicated with my mentors constantly -- along with my blog posts and the weekly Hangouts, I lurked on IRC, responded to feedback on my pull requests, and occasionally asked questions about things I was confused about."
Mentor: "Ben didn't communicate with us nearly enough -- apart from his blog posts and attendance at the weekly Hangouts, all he did was lurk on IRC and respond to feedback on his pull requests, and only occasionally ask questions about things he was confused about."

Joseph Yeung advised me at the Code Sprint not to worry too much, which I find is good advice, especially in social situations where I have to initiate conversations with other people -- if I'm not worried about how I come across, I come across just fine. Nonetheless, I do experience anxiety at the prospect of initiating conversations with people, even on the internet. I'm nervous thinking about the Hangout tomorrow, and that's something I've done, like, three times already, so it's not like I haven't had enough practice at it.

I have looked at what I've done over the past week. At the Code Sprint, Joseph suggested that one way to look at this course is as 2 to 3 weeks of work at a full-time job, except that each 8-hour day is spread across a week. With that in mind, if I had done everything I did this week in an 8-hour day, I would consider that to be a fairly productive day.

If I may extend this metaphor, I think it would be appropriate for me to being up the few jobs I have had. Unlike my colleagues in this course, I have never done an internship or had any experience programming in any real projects before this one. But I have taken summer jobs to pay for school: I worked at a museum one summer, in a lead refinery another summer, and most recently at Canadian Tire. In all cases, I don't think I got much productive work done in my first few weeks. I was too busy catching up with my coworkers and managers, who already seemed to know everything. At the lead refinery, I actually only saw the inside of the refinery once or twice in my first two weeks -- the rest of the time was spent learning basic safety procedures in an office. At Canadian Tire, I made a point of learning new things every day about the products on the shelves and about the tools I had to use (especially the computer that calculated the paint tints). Even on my last day of work before returning to school, I was still learning new things. And this was a retail store: imagine a programming project, with a large codebase, in which I am expected to make intelligent, surgical improvements.

Sometimes a confusion is best cleared up by asking the right question to the right person (even if the right question turns out to be "Help me?") Other times, there's just no way around acquiring the knowledge necessary to solve the problem. I think that, in the case of some of the problems I will be attempting to tackle in Freeseer, there is no way around gaining a deep understanding of the code. To ask other people for help too often would be a crutch to prevent me from learning. On the other hand, the right question might provide for an opportunity to quickly have the problem elucidated by another person, and help me to solve it. I often think about the differences between useful questions, and non-useful questions -- a bit too often, perhaps.

One way I hope to keep myself on track is to think in the long term: beyond this course, even beyond my university degree. The reason I signed up for this course was because I knew a little something about programming, but there seemed to be a huge gap between the knowledge I had, and the knowledge a person needed in order to contribute to an open-source project. I like open-source software, partly because I'm too cheap to buy software myself, but also partly because of the philosophy behind it -- the idea of putting programmers in control, making the code freely available, and the meritocratic idea that all you need to contribute to the world of software is a good idea and a bit of knowledge. I'm a creative person, but for the time being, knowledge is something I lack. This course seemed like the perfect excuse to dip my toes into the ocean of real-world software development.

As a result, I'm not in this course for the grade or the glory, and my main reason for going to university isn't for the promise of earning more money later on in my life (although that certainly doesn't hurt). I'm here because I want to know stuff. People always ask me what I plan to do with my degree. Hang it on my wall, I tell them. It's the knowledge and skills themselves that are important -- it never seems to occur to anybody that, when you have knowledge, you can, y'know, USE that knowledge. For example, part of the reason I spent so much time this week on SQL is because I know that SQL is used in a lot of programs besides Freeseer, and in the long run, even after this course is over, knowing about SQL will be a very useful skill for me to have, and will allow me to write programs that deal with databases -- I'm told that knowing about SQL is a very marketable skill as well, which is nice, but it's not my primary motivation.

I really want to be able to make programs that solve the kinds of problems I want to solve, and perhaps to solve problems that other people don't even consciously consider to be problems yet. Ultimately, it's kind of a selfish motive, but I don't think that's a bad thing at all. I have already learned a lot about contributing to an open-source project, and no matter what happens grade-wise, I know that I will have learned a lot by the end of the semester -- my time will not have been wasted.

Meta

I have a tendency to ramble a little in my blog posts. I have found that some people in my life enjoy my ramblings, and others don't. I would like to keep them in my posts, because I can provide a valuable first-person account of what it's like to be a student in this program.

In a traditional course, the professor grades the students based on a series of questions which is the same for everybody -- a lazy whiz-kid who knew everything before he signed up for the class might end up with the same grade as an average but hard-working student who paid attention and worked hard to understand the material.

But I get the sense that the UCOSP program is more complicated than that, with part of the grade being based on the goals the students set for themselves, on what the students learn, and on whether the students are able to make steady progress.

With that in mind, I would like to keep using my blog posts to make available as much data as possible on what was going through my mind each week. This is partly for my own benefit (I enjoy the act of writing to clarify my own thoughts) and partly for the benefit of whoever has to evaluate my performance in this course.

However, since not everybody needs to know what's going on inside my head, I think the best compromise would be to start my posts with a few short sections, followed by a Discussion. The short sections will be just the facts, ma'am: What I Did This Week, What I Plan to Do Next Week, and Problems. The Discussion will be the longer, stream of consciousness stuff. I might occasionally include a Meta section, like this one, for anything blog-related.