I am Ben Buckley. I'm not a hundred percent sure what I'm expected to write in my weekly blog post, but I will take it as an opportunity to reflect on what I've done each week and reorient myself towards my goals -- whatever those goals turn out to be. Since I assume someone, somewhere will end up reading these blog posts, I will do my best to stay entertaining.
I applied for the UCOSP program because I wanted to know what it was like to contribute to an open-source project. No matter what happens this semester, I am confident that I will know a lot more leaving than I did coming in.
Going in, I honestly didn't know very much. The thing is, in typical computer science courses, you learn how to program by doing isolated problems with preset solutions. There's a huge gap between solving problems designed to teach a specific concept, and actually being able to contribute to a project that people use.
It seems like learning to program is like learning a natural language. Just because you know how to diagram a sentence, doesn't mean you'll be able to fully appreciate James Joyce. There's more to it than just the syntax of the language. You also need a vast store of real-world knowledge. There is no shortcut to gaining this knowledge; it takes a long time.
The unfortunate thing is that often, when an expert knows a lot about a subject, they overestimate how easy it is for other people to master the same subject. So far, my mentors have been courteous about answering my questions. However, in the past I've had professors who hated answering questions -- even if they paid lip service to the value of asking questions, you could tell they didn't enjoy answering them. I'm always a bit nervous about asking questions, because I don't like to bother people. But on an intellectual level, I know that in the long run it is less trouble for everybody if I ask as many questions as I can as soon as I can, so that I can overcome any confusion I have and get started with productive work right away. So, it is important that I work on overcoming my fear of asking questions.
One of the reasons that asking questions can be so scary is that, when you ask a question, you are revealing your own ignorance. In an educational environment, it would be nice if this were encouraged, but in practice, admitting one's ignorance often results in being criticized by the person whose job it is to teach you, e.g. "I shouldn't have to explain something so obvious. You should know this stuff already." However, there are also times when I've asked a question about something, only to find that other students were confused about it as well. For that reason, I will try not to bluff my way through my blog posts. I will do my best to list everything that I am ignorant about. If my posts end up being very, very long as a result of this policy, then so be it.
I took one step in overcoming this fear in the past week. I had downloaded Freeseer, and I was trying to run it from the source. I could open the program, but I couldn't record anything. So, I posted in the Google group about it, and within a day, we set up a Google hangout to figure out what was going wrong. Michael Tom-Wing and Thanh Ha were very helpful, and ultimately we were able to solve the problem. Apparently it had something to do with how I installed one of the libraries? At any rate, I am able to record video and audio on my laptop.
One upside of my fear of asking questions is that I have gotten fairly good at learning things on my own. I have spent most of the last few weeks reading about things I need to understand in order to make meaningful contributions to Freeseer. This included, of course, the documentation for Freeseer, but it also included learning about Git and about Bash scripts. It also required me to learn about aspects of Python that I didn't know about, or about which my knowledge is a bit shaky. For example, I didn't know anything about logging in Python, and I haven't had much practice writing programs where catching exceptions plays a big part. I have also never used the Qt or GStreamer libraries before.
Learning about Git is a project on its own. Intellectually, I have some idea of what it's for -- it gives you a way to experiment on a project by making a branch, and making changes to that branch in the form of commits. In the past few weeks, I've learned a lot about how Git works, but I still have a very long way to go, I think. Sometimes I can Google the answer to a question, but a lot of the time, I need to read more about Git just so I can articulate a meaningful question, let alone understand the answer. Git is the first version control system I have ever used -- maybe if I had used other systems beforehand and dealt with the problems that Git is designed to solve, I would understand it a bit better. But alas, I have to work with the knowledge that I have.
I have spent some time in the past week considering what I want to work on this semester. Given my passion for making things understandable and easy, two things come to mind: the Freeseer GUI, and the documentation. What the GUI and documentation have in common is that they are both intended, in some sense, to communicate the purpose and features of the project to its users and developers. A common issue I have noticed among people who work in technical professions is that they are not always good at communicating their knowledge to other people. This is where I believe I might be of some use. I don't have a much technical knowledge as everybody else on the project, but when I do have knowledge, I am obsessive about being able to communicate it in a way that makes sense. I don't claim that I always succeed, but I am passionate enough about communication that I would be willing to stick with it for the entire semester.
I would like to spend some time working on both the GUI and on the documentation -- if I get tired of working on one of those two things, I can take a break and work on the other for a while. Working on the GUI will allow me to get my hands dirty with the code in a way that interests me, and doing research for the documentation will give me enough experience reading the code and using the program that I can contribute to other aspects of the project as well, especially if I decide to stay on the project after the course is over.
What do I hope to accomplish by the end of the semester? Ordinarily, when it comes to improving communication between developers and users, I would settle for nothing less than a total revolution in human consciousness. But since this is only a 3-credit course, I will have to settle for smaller goals. When I look at the list of open issues, I can see plenty that are relevant to my interests. For example, there's issue #532: after a talk is modified in the table view, it becomes unselected. This seems like a tiny problem, but it doesn't seem to have been addressed (I am able to reproduce it). Fixing it would make a small but noticeable difference in the user's experience.
Another issue is #442, "Reorganize Get Started Guide". I made some mistakes when I was setting up Freeseer, so I have firsthand experience in the importance of having a good starting guide.
With that in mind, I believe that I am ready to start drafting up my project proposal for the semester. I think I'll start doing that now.
EDIT: I've done my project proposal, and it can be seen here: https://docs.google.com/document/d/1D98OpJsXvnOMHOWmZkRnb5Xp26Upv2jfMaMP3VYP3WQ/edit?usp=sharing
No comments:
Post a Comment