How to teach Programming

Subversion Under Control

Our team had a dinner meeting tonight. Hunter told us that we would be receiving our source code later in the evening. Everyone was excited to head back to the lab to talk about the source code. I now have on my hard drive a working copy of Obsidian. We talked briefly about the different main parts of Obsidian, but the main idea is for each of us to go in and explore the code ourselves. We came up with a list of functionality that is needed for completion of the project as well as some possible areas of extension that we could work on. To learn the source code we decided that going through the source and creating class diagrams of the packages and how everything interacts would be best. This way we are forcing ourselves to look at every file and method in the project and understand their connections. We might even get a good class diagram that we can use to teach other people about the code at a faster pace then them just looking around.

Programming Education

I have advocated that the educational paradigm that we have currently (not just for programming) is broken and needs to be drastically changed. Sir Ken Robinson is one of my favorite public figures who shares very similar viewpoints on how education should be changed. The main problem with school is the fact that it hasn't evolved since its growth during the revolution. The level of importance on each subject is very skewed to catering to "creating professors" as Sir Robinson puts it. By this he means that we put Math and Sciences first, followed by everything else, with any type of art usually being at the bottom. Now, this might be all well and good for anyone who wants to go to what we know of right now as higher education (Math and Sciences being the main competitors while liberal arts colleges being the only schools who entertain the thought of an art major) but it isn't the best if we want to be able to start seeing problems from different angles. I'll talk more about general education in a later blog post, but for now lets talk about programming.

The main idea behind learning different paradigms like Object Oriented and Functional languages is for the expanding of our cognitive self, to be able to see the problem from different ways. This is also the same reason that we learn about different ways of solving the problem (recursive solutions vs iterative solutions). So with this reason well established I must ask, why do I feel like most of the people who try to go through a programming degree switch? Why do some students really struggle with the problems? I remember specifically when learning about linked lists and our teacher taught at a high level (concepts) and wanted you to figure out how to program it by yourself. The problem was that most of the students around me seemed to not understand how to code it. When I would sit the student down and try to get them to explain to me what a linked list is they could draw the diagram, and how to move though it, but they never made the connection that "currentNode = currentNode.next()" is the way that you can move to the next node. Why did so many students not seem to grasp the concept? I honestly don't have a concrete answer, but I can say that the students that didn't get it the first time seemed to grasp the concept a lot better when I used real world code examples and a visualization of what happened step by step. I feel like if we want to teach programming more we need to change the way we tackle the situation. And this doesn't mean just teaching the syntax either! I remember being in another class where we learned syntax for most of the class and then for the final I was asked questions about higher level concepts that (again) some students didn't seem to grasp. It seems that no matter how you teach there are just going to be students who don't understand parts of concepts. I know a full range of programmers, ones who know many different ways of solving the problem, but they couldn't program the simplest of solutions to a problem. Others who if given the method signatures could program everything, but couldn't come up with their own solution to the problem. How do we bridge the gab so we don't have this large whole in our talent.  

Bret Victor (former interface designer at Apple) says that the "new" ways of teaching programming by using tools like Codecademy and Khan Academy are doing everything wrong. In his interactive paper he explains that both the environment and the language should be able to allow the student to learn the way of thinking that is required of us to get our creative ideas into code. He emphasizes that Code and Khan Academy are just teaching the "rote skill" of programming, which as he puts it, "Learning about 'for' loops is not learning to program, any more than learning about pencils is learning to draw". The goals of a programming system should be, "to support and encourage powerful ways of thinking, as well as to enable programmers to see and understand the execution of their programs". His paper has started influencing developers to help create his vision of a new programming system that would allow students to easily pick up the theory of programming without getting lost in the syntax that teachers seem to want to push under the rug until a later time (I had to go look up what the main method in Java actually meant because of the lack of explanation in class to keep the smoke and mirrors afloat until after people learned syntax). For me and the other students who have both a strong skill-set in programming as well as problem solving seems to stem from the fact that we continue to learn outside the classroom. These are the students I would want working with me on any project. The ones who stay here late at night solving a programming problem because they want to and not because it is just the day before the homework is due. I want the ones who work on projects outside of class, who work on projects that are not their own, who help teach other students. Those are people who I think go to class to get the grade, but they are also the ones who if given the opportunity to make their own curriculum of what they want to learn would choose bigger and harder challenges. THAT is what we need to change our current students into. And the only way to do that, is to change the way we think about teaching. 

Motivation

Joining the Project

The groups have finally settled, the projects are slowly being picked, and Team Obsidian is officially a team. The more we talk about what we are going to be doing for the project the more excited I become. We have almost finished writing out our milestones for the project, including where we want to be at the end of the semester (hopefully we can show it off at POSSCON to some people I know who are going to be there). We hope to have a few people from outside our group interested in the software as well as a contributor or two. We are actually going to host a party if we get someone from outside the college interested in the project during our development semester. So far my section of the project is setting up/help set up our communication channels. This includes the a Google group for the developers as well as an open group for people to ask questions. The other thing that I helped with was the initial setup of our IRC channel. Eventually Micah and I will have a bot in there to do some basic functionality stuff (kicking people and controlling our op powers so we don't scare people away).

Daniel Pink/Clay Shirky on Motivation

Lately I have been reading a lot of Daniel Pink. The two books specifically I have been reading are "A Whole New Mind" and "Drive". Originally I read A Whole New Mind because the department chair recommended it to me after my interest in teaching was discussed one day and while it is a good book it isn't one I want to talk about today. I feel like I can relate Drive and another book Cognitive Surplus (by Clay Shirky) easier to software projects and open source, so that is what I'll do. Now, I love watching videos online about anything that might might be informative or entertaining, and normally these come in the form of TED talks. These videos normally help me figure out how I would want to run my company one day. Dan Pink's talk about "the surprising truth about what motivates us" was turned into a RSA-Animate video, and I feel like anyone who runs a software development company (or any company for that manner) should watch the video and understand what motivates us isn't as straight forward as you think. The three key elements that he deems important for better performance and personal satisfaction are: Autonomy, Mastery, and Purpose. With these key items I can see why the open source community continues to grow. We have the ability to choose what we want to work on (autonomy), we can continue to get better at our craft (mastery) and every software product we create has a higher reason for existing (like Wikipedia and Ushahidi) which gives us our third element, purpose.

Now while Daniel Pink does hint at open source, most of his video and book deal with how to motivate people within a company. This is a good thing as companies can work on open source software and make a profit, if only to get the idea of money off the table, so employees can stay focused on work. Just make sure you learn about the different ways open source can possibly make a profit (of which I'll talk about in a later post, but for now read the Magic Cauldron from my favorite book that I seem to talk about way too much for my own good), but seeing as how Obsidian is not for profit, and the people who are working on it are not getting paid (except by a grade, but I can safely say we are not even thinking about that, the project is much too interesting) I am more interested in the idea of Cognitive Surplus (video) to help us get people interested on working on the project. The idea of Cognitive Surplus is that people now have the means to use their free time in a more collaborative environment, as well as pointing out the generosity that people have to create for their fellow man. The cool part about our project is the fact that we are working on a tool that will help other people who create software. Imagine during an interview and you ask them how they test their software, "Oh we use Obsidian to unit test our code". I would just sit back and chuckle silently while I tell them I was on the team that helped make that open source. 

Knowing the factors of how and why people choose to collaborate on open source software is going to be very useful later on when the project is officially released online for people to play with. I believe gaining momentum by showing people the output of Obsidian and getting input from people early and often will only help the software grow.

FOSS Experiences and Reflections

The project that I want to work on for this semester is Obsidian. And seeing as how we would be creating the open source community behind Obsidian, I thought it would be good to go out into other open source projects and see how other people build their communities. During this effort I looked at big open source software packages (Ubuntu, Firefox, Chrome) as well as smaller ones (HTTPAgentParser, Team Talk) and a few in between (JUnit, Super Tux Kart). It is really interesting to see the differences in the amount of people change the whole dynamic of a group. For the small projects there is usually only one or two developers who have total control over everything that happens in the it. You can copy the project and make modifications but normally it is really hard to get in touch with the developers because the lack of formality with the community. Most of these projects are normally someone's quick fix to a problem that they just happened to release into the wild of open source. For the bigger efforts you can see a lot of formality with the project. If you want to submit code to fix bugs it has to go through verification processes (normally someone else signing off on the patch) and if you do not belong to the group who works on that section of the code (or you are new to the project) you have to jump through even more hoops just to make sure that your solution will not break any existing code. No matter which way you look at these scenarios they all hold a common element, they are built using a Bazaar style of organizing themselves.

The Bazaar style of development is (as Eric S Raymond puts it) the open market style of development, where you take in opinions and reviews from people who are normally outside the project. This contrasts what was perceived to be the better way of doing things the Cathedral way. The Cathedral style of development is one with very specific set of goals and a main "architect" who controls the whole project, an example of this would be GNU's Emacs and GCC. Both are restricted with a specific group of people who can contribute. Now when first looking at any level of open source software you might think that everything is actually developed in a Cathedral way (with a main person or group of people controlling everything), but that is not true. As Eric Raymond said in Homesteading the Noosphere's section called Ownership and Open Source, "According to the standard open-source licenses, all parties are equals in the evolutionary game." This means that anyone could direct the path that the project will take, however as he goes on about Open Source ownership he makes the point that in practice this can not really work. Every open source project will be dictated by everyone. So in real world practice of the Open Source licenses an Owner is usually found. This owner can be a single person (JUnit's Kent Beck) or a group (Ubuntu's Canonical), but you can easily find out who the owner of the project is by looking for something really specific for the project: "The owner is the person who has the exclusive right, recognized by the community at large, to distribute modified versions". So right now Obsidian has (to my knowledge) one owner, Hunter. Later on in the semester the ownership will shift slightly as everyone in our group starts getting more and more input about the direction of Obsidian, until eventually it will be more like Ubuntu instead of JUnit in terms of ownership.

Tomorrow I learn if I actually get into the team with the people that I want to work with, and if that happens then Obsidian is the obvious community we will be working on, seeing as how we have already had meetings about what needs to be done and who would work on setting up or initial websites and emailing listings as well as setting up an IRC channel for when we start getting other users on our project. The group seems really interested in the project and open source in general. Lets just hope that I can put my experiences and knowledge that I have to good use for the sake of making the community better and the software more accessible to everyone who wants to use it.

Picking a Project (A.K.A. My FOSS Preferences)

As I sit in the school computer lab I ponder to myself, "what type of free software/open source user/advocate am I?" Am I the Richard Stallman, or the Bill Gates? I think like most people I would consider myself in the middle ground. Not filled with disgust of closed source, but prefer open source when a good/reliable project can fulfill my need. An example of this would be LibreOffice or GIMP. Even though I would only consider myself in the middle of the spectrum I do love learning about the Open Source Movement and believe in everything they stand for. I actually tried to work on a few projects over winter break, but I'm still working on the patches before I submit them back into the project. So taking this all in consideration I believe I have picked my top three projects that I would like to work on for my CSCI 462 class at CofC: Obsidian, Melange, and Processing.

Obsidian (links will be provided when our job is done) is a project created by Hunter with Dr. Bowring's guidance. Without getting into too much detail about the project before it is released, it will help create a framework for test engineers to create unit tests. What I do feel comfortable talking about is what our team would be doing for the project. As hunter said in his post a team is forming, and one that I think meshes really well. Joanna and Micah are people I have wanted to work on a project with for a while now and last semester I had the pleasure of working with Laryea (who was on a team with hunter and myself) for our 362 project. Our work for 462 would be a little different than the rest of the class. Instead of contributing to an existing project we will (hopefully) be creating an open source community around the project (if Dr. Bowring puts us on a team together). Now what does that entail? We would have to create an open community that people would want to join. Seeing as how I have studied and advocated (and with some luck contributed to) open source in the past I feel like I have a decent grip on what a community should have as well as what it should try to avoid. Things we would be working on include: making the existing code base available and accessible to newcomers, working on a wiki page to keep a knowledge base that users and contributes can use to learn about the project, creating modes of communication with the developers (us for now) with mailing groups/IRC rooms/FAQ's, creating a way of tracking bugs and feature requests, and of course making the project better by adding features and fixing bugs. This is my number one pick seeing as how I have been begging to see/work on it since last semester when I first saw output of it for our 362 project and with my knowledge on open source I think I would be a great asset to the project.

Melange is a framework that creates "a framework for representing Open Source contribution workflows". If you have ever contributed to Google Summer of Code you have been on a Melange powered site. Melange is powered by Google App Engine (for now) and I believe that creating a framework that other open source projects can use to create a workflow for contributions is a noble cause. I know of one or two students who currently work on the project or have done so in the past and they all say that the work is challenging but rewarding, and seeing as how programmers are constantly looking for a challenge and get joy from challenging problems as well as being optimists during the whole ordeal, I want the challenge and sense of accomplishment that my fellow peers have felt.

My third project that I would want to work on is Processing. Processing is the project that I helped create a test framework for last semester. It is an "open source programming language and environment for people who want to create images, animations, and interactions." It is written in Java and works on a multitude of platforms including Android and in web browsers with Javascript enabled. The idea of working on a tool that can help students learn programming as well as artists create works of art is the original reason I picked this project last semester, and that passion for helping other people is still there for me.

Both Melange and Processing are projects that have a medium (10-40) number of developers actively working on them, while Obsidian will only have the students in the group working on it (at first). I would be happy to work on any of these projects and if I work on Obsidian I might (in my spare time) work on the other two projects as well to get more ideas on how to run an open source project. 

Bring on the Challenge!

Warning: The following blog post has a lot of links. I would recommend at least looking at the links after reading the post to get a better understanding of where I am coming from.

A new semester begins, and with that phrase students get back into the swing of things. The streets don't feel as empty as they once were during the Winter break and people are hanging out in the computer lab. Everything is slowly changing, but hopefully for the better.

The reason I deleted my old blogs and started this one is now upon us, CSCI 462 (otherwise known as Software Engineering Practicum). After taking CSCI 362 (the prerequisite for 462) I have been looking into testing more. Specifically I have been reading (or re-reading in some instances) papers and books that address the issues of software engineering in relation to: time management, open source ideals, project complexity, licensing, history of Linux, user interface, as well as going into open source projects to see where I can help out. This semester is going to be about putting everything we have learned into real world practice by submitting patches to existing Open Source projects (examples from last years class include Firefox, GIMP, and XBMC). Talking to a bunch of the students who hang out in the computer lab (hereby referred to as 218), every one of them seems anxious to start. I can feel a passion come out when I talk to them about what project they would like to work on.

It might just be my imagination running wild but after seeing a bunch of my peers start attending events that I have helped put on (and others I have attended) aimed at the tech industry it seems like students are more willing to put themselves out there instead of just attending class for a grade. Seeing students talk about the practice programming competitions and the fire in their eyes when talking about how much better they will do next time is great for me. I have talked about my own personal sense of accomplishment when I help a student get over a programming wall, but this seems to go deeper than that. I have setup another programming competition that will be on Friday 1/25/2013 and everyone seems to be paring off already into groups.

I'm really excited to be in 462 this semester for another reason (besides working on open source projects). Every student is given the opportunity to attend POSSCON (Palmetto Open Source Software Conference). My first interaction with the Computer Science department at CofC was actually the semester before I started. Dr. Starr (The department chair) invited me to attend by riding with a teacher who was driving students (for the same 462 class that I am taking right now) to the conference. Wanting to get involved early at the school I accepted. I got to talk to Jon 'maddog' Hall as well as hear talks from people involved with hosting services like github and linode. The best part is that this year one of my friends Adrian who helps with +BarCampCHS might be presenting this year! It will be interesting to see someone I look up to give a presentation in front of a room full of hundreds of people.

After looking on the Class Wiki (which holds all the blogs for this semester) and reading most of my peers initial posts I have to say, everyone seems to be really interested in POSSCON as well as working on an open source project. I do have to give +Tyler Sawyer a shout out for talking about my favorite topic, FOSS. Specifically about the difficulty starting to work on a big project when we are more secure in our old ways of working on a small project for a homework assignment. Everyone can learn from his lessons about how difficult it can be, but to not give up, for the benefits outweigh the pain and struggles that you may face.

Talking about FOSS I'll just throw up a video clip from the movie RevolutionOS (Which we should watch in class *cough cough*), where Bruce Perens talks about free and open source software. Specifically he talks about the (at the time) 9 rights (now 10 rights). The 10 rights of open source spell out the ideals of the open source movement including the idea of "copyleft", the opposite of copyright. I'll talk more about my thoughts on copyleft as well as open source in general thought the semester, specifically when I talk about Eric S. Raymond.