Sometimes, the outside is inside

Just a few pages off the bustling infinite corridor, there's another hallway, but unlike the infinite, it has four-story-high glass ceilings, my favorite piece favorite piece from the Percent-for-Art Program, and no traffic.

Building 6c's colorful, sunny hallways

The exterior of building 6C fascinates me. The corridor with the colorful floors of Sol LeWitt's Bars of Color Within Squares connects the outsides of 4, 6, 6C, and 8, and in most places, the hallway would actually just be outside. The ledges of the first floor windows provide convenient benches. The greenhouse-styled ceiling lets in more than enough light for reading, while the pathways above create shaded spots. And when it's too hot or too cold and there aren't clouds in the sky, it's bright, warm, sunny, and just right.

Recruitment is hard, part 2: goals and values

I spend a lot of time thinking about recruitment issues these days. This could be because I'm involved in a few student groups that have been spending a handful of time talking about it lately.

While a good portion of discussion about recruitment is (and should be) focused on "selling" your organization to newcomers, just as much of the discussion should center on clearly defining your organization and what it offers to potential members. A common line of questioning to many of my groups has been the following:

If we claim we are chosen based on values or work towards a set of goals, but we do not display these values or further these goals, then what were we chosen based on and what are we working for? Will others understand the purposes and goals of our organization? How will we "sell" our organization as something based on these values or working towards these goals?

People often don't like to think about this issue because it approaches the "recruitment problem" with "sticks" more than it approaches it with "carrots." I take issue with these concerns because I feel like they put organizations on pins and needles out of the fear that any misstep will ruin their image.

I suggest taking this line of questioning as a basis for discussion, instead of as something requiring the development of new policy.

Recruitment is hard.

Recruitment is one of those things that everyone does, but everyone seems to want to do better. It's also the kind of thing that is challenging: it's complicated, it's tiring, and it's personal.

Even if the {company, organization, student group} you're recruiting for has {well-defined, narrow} common goals or interests, the people you will want to recruit aren't likely to fit into any one "type." Primitive "typing" (computer pun not intended) can be based upon a two-axis plot of their interest and their compatibility.

The four basic types in recruitment based on compatibility and interest

To clarify, compatibility refers to their interest in what your organization does, while interest refers to how interested a person is in joining an organization surrounding those interests.

Last Thursday, I ran a discussion-based workshop on recruitment for SIPB, MIT's computing club. In the context of SIPB, "compatible'' refers to how interested in or knowledgeable about computing a given person is, and "interested'' refers to how interested they are in being a part of a computing organization. I introduced the types mentioned above as a foundation for what I hoped to be a very organic and free-flowing conversation about improving recruitment. Turned out my plot worked.

To start, we discussed some of the reasons that people walked into the SIPB office. They included:

  • wanting to learn about SIPB,
  • desiring use of a stapler, hole punch, or scanner,
  • attending a hackathon,
  • needing help to fix a computer problem,
  • hanging out with friends who spend time in the SIPB office,
  • tooling on a pset with SIPB members, and
  • proving to a reasonable portion of zephyr that you exist outside of the terminal.

We then talked briefly about how likely some of these people were to fall into the various types and emphasized how SIPB's recruitment efforts needed to be tailored not only to the different types of people but the different reasons they came into the office. It's a bit strange to spontaneously sell someone on the organization who's just using the stapler, but it's almost logical to inform them of some of the organization's other services.

We found that there was a central theme to what we wanted to accomplish with any interested or compatible person: we primarily wanted to get them to come back to the office. Ultimately, this accomplished more than just keeping someone informed through a set of mailing lists (which they could then filter to an ignorable mail folder): the returning prospective member gets more personalized attention and another opportunity to see the awesome things the office is up to.

We let the conversation flow pretty organically, and some of the other suggestions to reach out to prospective members and to get them involved in the organization included:

  • maintaining a running list of "smaller" tickets which don't require a lot of background knowledge but relate to SIPB projects,
  • emailing prospective members about parts of projects or new project development that have low barriers to entry,
  • updating the website to contain information relevant to prospective members in a clearer, more direct manner,
  • making a point to introduce yourself to an unfamiliar face that sits down next to you,
  • pointing people towards other members whose interests are better aligned to theirs, and
  • following up with someone you talked to for a bit but haven't seen in the office for a week or so.

My observations of the SIPB office over the course of the weekend indicated that some of these are already well on their way to implementation.

The final topic of conversation revolved around how to get people who might be interested in an organization like SIPB but have never set foot in the office to learn more about SIPB. Of course, we mentioned inviting computing types to hackathons and other events. I suggested that subtler methods could be even more effective; I know that I've gone to the SIPB office many times simply because someone asked me where I was headed after class and mentioned they were headed that way.

We certainly didn't touch on everything which could be done to improve recruitment for SIPB; after all, recruitment is not just a hard problem, but one that changes over time as an organization, its members, and its prospective members change. But I also never expected to hold this workshop just this once.

***

I didn't write up too many of the notes about the various types here because they were fairly specific, but I did address it briefly in the comments section of my old blog:

Paul: I liked the two-axis model a lot, and I was hoping you would have talked about it a bit more. To ask a very open-ended question: What should a group do about/with type III people (low interest, low compatibility)?

Me: I intentionally didn't speak too much about it directly because how you handle people in types II and IV - the two groups one usually needs to spend the most time thinking about with respect to recruitment efforts - varies significantly from organization to organization. In terms of type III, the main goal is to be informative. People in this group can move to type II or IV fairly easily. In terms of SIPB, this is about informing people about services like scripts, linerva, and XVM, or if it comes up, mentioning that Debathena is a joint effort between SIPB and IS&T. Hearing about how SIPB's services makes their lives easier might make them think of SIPB in a more positive light. They also might tell all their friends about the awesome services we provide - maybe some of their friends will want to get involved!

'First' thoughts on git

I suppose it's more than a slight bit incorrect to state that these are my first thoughts on git; I've certainly already been exposed to git in a variety of ways. I'd always been told that my love of graph theory would convert me over to this different type of version control.

I more or less decided to look into git on a set of whims, yet I was really persuaded to go to the "dark side" because I was strongly encouraged (read: required) to understand the back-end model instead of just memorize a handful of commands (like with SVN). I'd attempt to do the merits of the consequences of git's back-end model justice, but instead, I'll point you to a far more experienced git user's blog post.

My first steps to really learning git was to look at a handful of resources:

After an hour or so of reading, my friend Evan and I talked through a bunch of the basic commands briefly and some of the more interesting commands in greater depth. I took notes on easel paper for the basic commands, and we worked through diagrams for cherry-pick, merge, and rebase:

Notes and diagrams from our conversations on git commands

I got fairly excited when I guessed that rebase essentially applies a series of cherry-pick calls to a branch.

I decided to start using git much more frequently for my academic projects. I really like the control that my understanding of the back-end model provides, and that control in and of itself is a sufficient reason to consider switching to git. I'll also argue that learning the back-end model is a fun enough exercise to want to switch.

A very MIT signals problem

I've always found signals and systems interesting, as it is one of the most power tools out there. Signals and systems can be used to describe many different problems because it is simply an abstraction which describes a physical, mathematical, or computational system by the way it transforms an input signal into an output signal. It's often studied by electrical engineers because it has many direct applications to signal processing and communication systems, but there are lots of applications in other fields.

The signals and systems intro class at MIT, 6.003, is one of the most dreaded and disliked Course 6 classes. The class used to be required for all Course 6-ers, both EE and CS majors, but now that the EE/CS department has switched to a new curriculum, it's only required for double E's. It's a bit unclear where I fall in the Course 6 spectrum, but most of my friends think I'm crazy for having enjoyed 003.

I took 003 in Fall 2009 with Professor Denny Freeman. His approach deviated from the usual approach to the class by

  1. reordering the topics so that Laplace transforms were taught before Fourier transforms and
  2. introducing the concept of "Engineering Design Problems."

The "Engineering Design Problems," or EDPs for short, aimed to show 003 students some tangible applications of the material, and they were open-ended questions which typically required some amount of programming. For most people, these problems made them a bit more excited about signals and systems, but for me, this was all about getting excited about writing little pieces of code.

The most "MIT" EDP was assigned near the end of term:

The following images have been blurred. Figure out a way to sharpen each image to identify the following buildings:

Blurred Buildings assigned

You might be able to guess what some of those buildings are without even seeing the larger images the course staff included in the assignment. (b1 certainly is the most distinctive.)

Of course, there are many ways to blur an image, but looking at this from the simplest 6.003 perspective, it's most likely that either the rows or columns were blurred by a system with a single pole. After all, Denny Freeman is a big fan of Occam's Razor. Running with this assumption, such a system would have a system function with the following form:

H_{blur}(z)=\frac{1-p}{1-pz^{-1}},

where p is the system's only pole. This system would be stable if |p|<1. More importantly, if this system were a low-pass filter, i.e. if 0<p<1, it would blur the image.

You can deblur a system blurred by a single pole by applying a system with a single zero:

H_{deblur}(z)=\frac{1-pz^{-1}}{1-p},

where p is this system's only zero and has the same value as the pole in H_{blur}(z).

Since we will want to write code to deblur the image, we will want to get the difference equation corresponding to H_{deblur}(z) to apply to the rows or columns of the blurred images. The corresponding difference equation is:

y_{deblur}[n]=\frac{1}{1-p}(x[n]-px[n-1]).

Now that we may have figured out what's going on generally, let's look closely at image a1:

Blurred Building a1

The blurring in image a1 looks to be primarly horizontal, which means rows of the image's pixels would have been passed through the low-pass filter. To deblur this image, we should try to pass rows of pixels through the deblurring different equation, y_{deblur}[n]. The rows were processed either casually or anti-causally, i.e. left to right or right to left, respectively.

At this point, we really just have to dive into writing some code. The first deblurring code I wrote was a Python script to deblur a blurred_image from left to right with a pole p and save it to deblurred_image:

import Image
import os

def deblur_left2right(blurred_image, deblurred_image, p):
    original = Image.open(blurred_image)
    new_image = Image.new('L',[original.size[0],original.size[1]],0)
    original_pixels = original.load()
    new_pixels = new_image.load()

    for j in range(original.size[1]):
        new_pixels[0,j] = original_pixels[0,j]
        for i in range(original.size[0])[1:]:
            new_pixels[i,j] = (original_pixels[i,j]-p*original_pixels[i-1,j])/(1-p)

    new_image.save(deblurred_image)

After playing with different values for p, it was apparent that images a1 and a2 were blurred from left to right with a pole at 0.985, so deblurring them with a system with a zero at 0.985 returned the original images. Here is the unblurred version of a1:

Unblurred Building a1

As you can see, a1 is building 68.

The buildings in the second row, b1 and b2, had their columns blurred from bottom to top with a pole at 0.985, and the third row, c1 and c2, had their columns blurred from top to bottom with a pole at 0.985. You can change the for loops in the Python script to deblur in other directions. I encourage you to also see what happens when you change the value of p.

Even with "cute" EDPs like this one, 003 last fall was still all about grungy math - signals and systems often are. However, students who hadn't decided that the class would be too terrible before even stepping into 34-101 for the first lecture seemed to enjoy playing with some of the more tangible applications of signals and systems and got a lot out of the class. Hopefully, more people can come to appreciate this class in its own right, and maybe fewer people will shy away from being an EE because they fear 003.