Mindful learning; or, transferring student attention to eagerness for knowledge, rather than grades

In his book, “The Mindful Brain,” D. Siegel does talk about mindful learning near the end, a concept which was implanted by Ellen Langer. In a few words, mindful learning involves busting traditional myths about learning (such as top-down or bottom-up approaches) in favor of “sideways learning,” which entails implicit/explicit awareness (“mindfulness”) to context, open mind, awareness to distinction and condition, focus and orientation in the present, and other metacognitive processes. With respect to the top-down traditional learning approach, where test scores and grades are the focus of attention (thus sucking up cognitive power), I’ve always wondered whether modern instructional strategists can push the envelope and change the learning process altogether for the better. I attempted to do something similar in a past life.

In September 2010, I was assigned to teach an introductory computer science course at UNBC. We used to refer to the course as CPSC 126.

CPSC 126 is designed to introduce students of various backgrounds to the discipline of computer science. I intended to bust certain myths and misconceptions about the discipline and, in hindsight, I believe I achieved that major objective.

However, I thought it would be wiser to ask a more experienced teacher and computer scientist on how to best instruct the course. I was particularly interested in teaching students on how to gain knowledge for themselves, rather than having them wait for a single viewpoint coming from one individual, such as is the teacher. I decided to email Scott Aaronson of MIT.

Scott was kind enough to write a blog entry about my questions and his response. He posted our discussion here. I believe it may be of some help to young instructors taking on unconventional teaching that (purportedly) yields mindful learning. I quote here just a couple of points:

Arber:

In your opinion and based on your experience at various institutions, what would you recommend to me (a young, inexperienced scholar) regarding on how to best remove students’ attention from the mediocrity of grading to the eagerness for knowledge or, at least, high culture? […] I would also appreciate it if you could provide me with one or two guidelines in approaching students to appreciate what they are being taught and to teach them on how to seek knowledge for themselves.

Scott:

Dear Arber, Thanks for your thoughtful email! I’m always delighted to hear from people who share my views about the inherent problems in combining teaching with evaluation.

Alas, your question of how to get students to focus on intellectual exploration rather than on their midterm grade is an incredibly difficult one, since it depends not only on you but also on your academic context (for example, you’ll probably be required to give grades by department policy). I’ve been struggling with that question myself for the past three years, and still haven’t answered it to my satisfaction, but here are a few small tips I can offer.

(1) Some students didn’t come to college to learn, but for any number of other reasons: to party, get a high-paying job, satisfy their parents, etc. Or they’re only taking your course because it’s required for the major, while their real interests lie elsewhere. Treat these students fairly and with respect, but don’t kill yourself trying to awaken an intellectual curiosity that isn’t present. Instead, identify the students who are in your class to learn, memorize their names and faces, and make special efforts to reach out to them—for example, by sticking around after class to chat with them about the lecture and answer their questions. (In my experience, many intellectually curious students prefer sticking around after class to coming to office hours. In many cases, students who come to office hours are there because they want you to do their homework for them!)

(2) Grade generously. I usually give at least a B- to anyone who makes a serious effort in the course. (In practice, that policy turns out to be compatible with giving a fair number of Cs, Ds, and even Fs.)

(3) Most importantly, if you don’t want the students to focus only on low-level boring stuff, don’t lecture only about low-level boring stuff! Tell stories about Alan Turing and his codebreaking work. Talk about the philosophy behind the Church-Turing Thesis, or the arguments for and against identifying “feasible” with “polynomial time,” or the implications for AI if it turned out that P=NP. If a student asks a really good question, don’t be afraid to take a 10-minute digression to answer the question. You’ll constantly feel pressure in the opposite direction—there’s so much “real material” that needs to be “covered”! But think about what your students will remember from your course twenty years from now, long after the details of implementing red/black trees have been forgotten, and the right course of action will become clear to you.

One most interesting point Scott indicated was the inherent paradox in teaching. It can be best realized by my remiss question: how do you teach students to teach themselves? :)…

Who is doing what to whom, and why?

The opacity this question offers as a stand-alone isocolon fades away once one states what it is intended to attack. Get this: Twitter’s main menu located on top of the page contains a tab with the label: “Who To Follow”, as illustrated in the following figure:

The English used here seems fine to most, but the grammatical error it poses is oblivious and mostly missed or unaccounted for. As a grammar Nazi (as a friend would probably refer to my attentive persona), I’m ranting here to attack precisely this carelessness with English language Twitter has attired its website with.

A simple sentence, also known as a clause, comprises a subject and a predicate. The purpose of the subject is to be in agreement with the main verb, which denotes the tense and the respective action. The subject may be spotted by asking questions such as “Who?” or “What?”. Neither the subject nor the predicate need be atomic, as in “It is raining.”, wherein “It” denotes the subject (who?/what?) and “is raining” the predicate of the clause.

Now, consider the sentence “I follow you.” The subject here is “I” (“Who?”), the verb “follow” is in present tense and denotes the action of the subject. The pronoun “you”, on the other hand, is the object of the clause. In English, the object may be spotted using questions such as “Whom?” or “To whom?”. Hence, to spot the object in the sentence “I follow you”, you may ask yourself: “Whom do I follow?”. The answer would be “you.” In other words, “I am doing this to you”, so as to answer the question posed by the title of this post. It would thus be more respectful to English if Twitter were to edit the erroneous label “Who To Follow” to the correct counterpart: “Whom To Follow”.

The reason English natives make such mistakes is at least two-fold, in my view. First, the construct of the English language is such that it makes it hard for an English speaker to differentiate between subject and object. A language such as German or Albanian or even Turkish make a clear grammatical distinction and have the right questions to spot such constructs. Second, English natives are not taught the language as harshly and strictly as it is taught to their counterparts in, say, European schools. I shouldn’t forget to mention what I sometimes notice — few English natives pay strict attention to their language while they read. Pitiable.

(I added the “Why?” to the “Who is doing what to whom?” person-marking isocolon hoping some expert out there might provide their insightful explanations here…)

Our hits at ICSE ’12

In the past two semesters, I’ve been collaborating closely with other researchers to both learn from them and from what they’ve pointed at, as well as to contribute modestly to the body of knowledge, as is customary. Among our compositions, three hits were intended for three different workshops in this year’s ICSE in Zurich, Switzerland, and the three of them were accepted.

The first hit, “ProxiScientia: Toward Real-Time Visualization of Task and Developer Dependencies in Collaborating Software Development Teams,” which I coauthored with Kelly Blincoe, Adrian, Peppo Valetto, and Dana, is thus far the one whose lyrics I know the best, as you may have noticed here. We’ll be presenting this at CHASE, an arguably reputable workshop. Here’s a PDF of the paper. A funny constraint at CHASE, as in most other venues: limit the provision of your knowledge to 7 pages. One needs to inform ICSE about the existence of the concept of entropy in relation to data compression and the inherent computational difficulties to compress stuff. Note: Here in Canada we have a vast unused space and we don’t care of compressing; thus we do feel you, Switzerland :)…

The last two hits are mainly pedagogical reports on teaching software engineering in the face of modern constraints. The first such paper, and the second hit, is a concise synopsis I wrote with Dana, my supervisor, having TA-ed for her before as well. It’s titled “Teamwork, Coordination and Customer Relationship Management Skills: As Important as Technical Skills in Preparing Our SE Graduates” and will appear at EduRex. A preprint (PDF) can be found here. In my view, the learning outcomes we summarized as well as the challenges faced throughout the instructional process are the major contribution. To provide some context, we included a section alluding to the types of projects we had students develop, as an anonymous reviewer pointed at.

The third and final hit is a paper I coauthored with Dana, Casper Lassenius, Maria Paasivaara, and Adrian, titled “Teaching a Globally Distributed Project Course Using Scrum Practices” (PDF here). The intent here was to report on observations regarding the applicability of agile methods (e.g. SCRUM) in GSD settings. The ecology used for observation was the GSD environment set up for the GSD course taught at the University of Victoria, Canada in collaboration with Aalto University, Finland. (I’ve dedicated a post to that course since it was my second PhD course and an interesting experience at the same time.) This is an important report on the challenges students faced in employing scrum practices in GSD teams. In particular, student teams (three, in total) comprised Canadian and Finnish teammates separated culturally, temporally, and geographically, noting that the linguistic distance wasn’t really a factor. It will be great to argue on the challenges faced (and lessons learnt, now that the course is over) with other workshop participants who had to resort to similar instructional strategies/designs and who experienced all sorts of challenges for all sorts of reasons.

More updates to come in future posts as we prepare for ICSE ’12.

Disparate results, joint challenges

Gary and Judith Olson start their famous paper “Distance Matters” with a quote from Arthur Mee: “If, as it is said to be not unlikely in the near future, the principle of sight is applied to the telephone as well as that of sound, earth will be in truth a paradise, and distance will lose its enchantment by being abolished altogether.” Alas, distance still persists, particularly in software development where global adoptions of the process have posited harder challenges than the apparent advantages distance-mitigating technology (such as video-conferencing) brought in.

In his paper (PDF) “Global Software Engineering: The Future of Socio-Technical Coordination,” Jim Herbsleb (one of the organizers of the FoCSD workshop, read here) wittingly points out that the distance factor is what makes global software development (GSD) different from the traditional, collocated processes. Given Crowston and Malone’s definition of coordination as managing interdependent components, Herbsleb hints at three main areas of GSD in need of coordination: software architecture, requirements, and tools. Software architecture is molded by coordination on top of the technical skills and imagination required from architects and developers. The major dependency here is between tasks. Managing task dependencies effectively implies effective coordination at the software architecture phase. Thus, this being hinted at as the main challenge, the question is how it can be fit with an organizational structure. That is, are there sufficient resources to manage such dependencies over the distance factor? Next, requirements require abundant communication. In turn, communication and coordination are connected via a feedback loop where one guides/improves the other, as Jorge Aranda points out in his PhD thesis. Finally, tools are the manifestations of coordination mechanisms (as far as it concerns the subset of tools pertaining coordination in GSD).

But I want to emphasize one crucial point: coordination tools are to be built and actuated if, and only if, they are designed on top of demonstrated coordination mechanisms. Otherwise, developers and other actors shall be reluctant to employ these tools if there is not clearly tackled use case. A satisficing number of tools should be provided to cope with the GSD process — an overwhelming number could lead to communication breakdowns and, thus, could negatively affect coordination.

The latter point clues at the best coordination practices in GSD. A multiplicity of interactions and communication channels could make the GSD process perplexing; however, judging from appearances may yield incorrect conclusions or premises to anticipate a wrong conclusion. A challenge Herbselb poses is exactly this: identifying best practices (“effective” he calls them) and making the GSD process compatible thus attenuating the effect of distance.

I am, nevertheless, not fully impressed when modern researchers, on top of talking about the future, forgo important aspects of human systems — we are complex entities with complex interactions; thus, every human system (including GSD systems) should be studied from the viewpoint of Complex Systems. There’s more to a complex system than communication and tools — there’s collective intelligence and self-organization. Understanding the power of the latter processes could provide useful insights to understand what “effective” (as in “effective coordination”) means…

Prophesying on the edge: The future of collaborative software development

The CSCW ’12 conference, held in Seattle, WA, 74 miles apart from Victoria, BC, was a blast. Or, so I heard. I didn’t attend. I couldn’t attend. I belong to a different cultural species, at a level where preponderant cultures impose visa restrictions. Nevertheless, I had a paper accepted at the Future of Collaborative Software Development (FoCSD) workshop, whereby experts were invited to talk about the future. My paper, titled “Embracing Distributed Work: Why Distance Shall Matter (Even) Less,” (PDF here) coauthored with Adrian Schröter and Daniela Damian, talked about the importance of distributed software development in terms of its inherent benefits vs. the benefits of collocated development. In brief, FoCSD poster for the benefits and my prophecy for the future: The benefits of distributed work comprise a whole larger than the sum of its parts; thus, it should be embraced without any local hesitation. Here’s Adrian’s post on this and another FoCSD paper where I appear as a coauthor.

But the speculation per se is not the real issue when it comes to academic venues. What really concerns me here is the actuation of such workshops, whereby experts talk about the future using scientific principles, such as dialectics, statistical inference, etc. The entire process of predicting the future is not only erroneous in its intent, but also reduces to intellectual poverty.

The field of CSCW entails social and cultural research because, after all, studied actors include human beings and their ecologies. One major argument for talking about future trends in social sciences is exactly the presupposed abundance of historical data. That is, social scientists intending to predict the future assume a historicistic approach with respect to a social and cultural process, such as distributed software development. Yet, as Karl Popper has argued in his book “The Poverty of Historicism,” such attempts are doomed to philosophical, intellectual, and actual failure, most certainly. This is what I meant by intellectual poverty above.

Furthermore, in less philosophical, but more realistic, terms, Michael Shermer has nicely articulated in a Huffington Post article, why we, the expert prophets, are merely wrong. According to Shermer, no matter how many existing studies one quotes to talk about the future, one has confirmation bias, “which our brains employ to reinforce what we already believe while ignoring disconfirming data.” If the rebuttal here is that such academic venues as CSCW are highly specialized and focused on such research, then this indeed “increases confidence, but it also blurs dissenting views until they are no longer visible, thereby transforming data collection into bias confirmation and morphing self-deception into self-assurance.”

While I refrain from considering my CSCW FoCSD paper as a prediction to future trends in distributed software development, I believe the Popperian criticism of historicism and Shermer’s nice recollection about the futility of predictions do apply in my case. It is this wit which may have probably affected some FoCSD organizer, who decided to not make the FoCSD proceedings available to the public.

Wise move to save oneself :).

An apologetic rationale for David Allen’s “Getting Things Done”

When I commenced my PhD studies in September 2011, I decided to replace my existing system of personal organization with a new, much-talked about system referred to as Getting Things Done (GTD). This is, in fact, the main title of a book written by David Allen and published in 2001. Therein, Allen describes a personal organization system which purportedly increases productivity in a stress-free manner. (I’ll succinctly summarize the main points of that system below.) I write “purportedly” because it is in my nature to almost always assume a skeptical position (in the sense of rationalism) when reading and examining a particular matter. In other words, I focus only on the facts of the matter.

Yet, Allen’s writing is based on an experientialist approach wherein the phrase “trust me because I’ve seen it” seems to be clued at incessantly throughout the flow of the book. (In fact, at some point, Allen does write: “…but in the meantime, trust me.”) Thus, I wondered, could there be any scientific (neuro-psychological) rationale behind the foundational claims of superiority of such an organization system? Well, I didn’t find a plausible answer to my question until I came across Mihaly Csikszentmihalyi‘s seminal book “Flow.” It is my intention to elucidate on that answer in this post. At first, I shall illustrate Allen’s GTD system along its structural points. Next, I shall attempt to use some psychological results from Csikszentmihalyi’s work to rationalize (at least to some degree) some, if not all, of Allen’s points.

To motivate the reader into his system, Allen introduces the concept of “incompletes” or “open loops” (pp. 12–15), which entail essentially stuff (thoughts, ideas, intentions, created or discovered information) that one has in mind that is occupying one’s mind. This stuff (or, commitments) need to be thoroughly identified (for one may not be fully aware of all of them) and manifested into some sort of tangible system (electronic or physical) so that one may then take the necessary action(s). Thus, the basic principle behind the GTD framework is to collect and corral all the stuff that bugs your mind and decide whether and how to act on it. The trick to effectual organization is to keep reminders about such actions and consult (review) them frequently so one doesn’t miss doing any “incompletes.” Furthermore, on pages 15–17, Allen discusses on why “incompletes” are on one’s mind. In particular, he states: “Until those thoughts [incompletes] have been clarified and those decisions [to act on them] made, and the resulting data has been stored in a system that you absolutely know you will think about as often as you need to, your brain can’t give up the job” (p. 16). It is exactly the latter conclusive statement that I intend to apologetically rationalize here.

Allen’s Getting Things Done (GTD) system comprises five phases:

1. Collect. One must always collect everything that is deemed as an incomplete in one’s mind. Every thought, desire, intention, extravagant idea or opinion that has a “…’should,’ ‘need to,’ or ‘ought to’ attached to it” (p. 26) needs to be expelled from the mind and written down somewhere outside the mind. On page 29, Allen allegorically states that one’s mind is like a computer’s RAM — it can only hold and process that much. Thus, one needs to “get it all out of one’s head.” Naturally, getting them out is not sufficient and efficient unless one processes them, which brings about the next phase.
2. Process. Now that one has their stuff out of their mind, one needs to process what each manifested item means. Allen provides a nice, intuitive flowchart of this “algorithm” of his on page 32. In simple terms it works as follows: Take an item from your system and ask yourself what you can do about it. That is, what’s the next physical, unitary action you can take to do that item? If there is no action, trash it or incubate it for prospective use. If there is an action, determine what it is and if it takes less than 2-3 minutes, do it; otherwise, put a reminder somewhere in your system to do it in due time. How does one organize reminders, though? That’s the next phase.
3. Organize. Here you want to separate actionable from non-actionable items. The latter can either be trashed if they have no value or incubated/referenced otherwise. The referencing should be general (e.g. file-folder-based). Actionable items posit a gimmick: if an incomplete you’ve taken out of your mind takes more than one action step to complete, then Allen refers to it as a project. Thus, you can’t “do”  a project, but you can only “do” the actions associated with that project. For instance, if item “Save the world before I die” was on your mind and you took it out, it most certainly needs more than an action step and is, therefore, a project. Allen advises one to keep projects in a separate list and the actions associated with them in another list for frequent reviewing, which yields to the fourth phase.
4. Review. Now that you’ve organized your stuff, you must review them so that you actually do them. Reviewing starts from the most exigent element — the calendar — and proceeds with the next actions that you intend to do. Also, a weekly review of all you’ve got (including your list of projects) is essential to keep your system up and running.
5. Do. The final phase of Allen’s GTD system is to actually do things, mainly based on your intuition, but also on the contextualization of your settings. For instance, if you’re on a plane using your laptop, you’ll most probably do things that can be done only on your laptop (e.g. email, write a poem, etc.).

The rest of the book goes at length to describe the actual implementation of this system and to get projects going through several tricks and tips based on the author’s expertise as well as on other practical knowledge.

Now, if you look back at the most vital point of this five-phase system, the first point, you  might naturally ask: Why is it that one needs to get things done by first getting them out of their minds? That is, why won’t the brain give up the job? Why would one want to free up one’s psyche of stuff that bugs one? What’s the rationale behind this? Should I just trust the author and invest my time in implementing a system of personal organization with utter skepticism and risk to end up not leveraging it? These questions were sitting at the back of mind as I was reading and implementing Allen’s GTD system. These questions were the only “open loops” that thwarted me from assembling the system back when I finished reading the book months ago. But I answered them comfortably as I was reading Csikszentmihalyi’s “Flow” and I can reassure you that after implementing GTD with less skepticism it does work smoothly, overall. Here’s why.

The essence of Csikszentmihalyi’s “Flow” is about positive human experiences that enable one’s life to flow, i.e. to be exhilarating, vivacious, enjoying life, and so forth. Csikszentmihalyi (whose name sesquipedalophobics might want to eschew pronouncing) provides rigorous psychological arguments (based on decades-long research) on what flow is and how to attain and preserve it using a phenomenological, rather than anatomical/biochemical, approach to the functioning of the nervous system and the mind.

After revisiting happiness in the first chapter, Csikszentmihalyi elucidates on the anatomy and limitations of consciousness interestingly in light of the information-theoretic concept of entropy (p. 25). On page 24 he writes: “A person can make himself happy, or miserable, regardless of what is actually happening ‘outside,’ just by changing the contents of consciousness. [...] To develop this trait, one must find ways to order consciousness so as to be in control of feelings and thoughts.” According to the author, information theory is relevant to apprehend what goes on in one’s mind through such a model of consciousness. This could be a valid undertaking because after all: “The function of consciousness is to represent information about what is happening outside and inside the organism in such a way that it can be evaluated and acted upon by the body” (p. 24). As such, consciousness may be construed as the central “clearinghouse” which handles sensations, thoughts, intentions, desires, etc. Note that intentions are what provides and keeps order in the consciousness (p. 27). And these intentions are organized in a hierarchy of goals/outcomes (p. 28). Hence, we can freely control which outcome to pursue based on our subjective prioritization of objectives. In David Allen’s sense, these outcomes could be viewed as project outcomes, but also as the next actions to take to do whatever incomplete has been collected.

But consciousness has indeed a major limitation: it can process only that much information. The empirically observed terminus of the amount of information consciousness can process at a time is at most 7 bits. The mind can discriminate these 7-bit chunks at every 1/18th of a second, which implies that an average human can process roughly 120 bits of information per second! If we assume that a human is awake (“conscious”) for 16 hours a day and lives on average 70 years, the lifelong amount of information the mind can maximally process is roughly 185 billion bits (p. 29). Pretty fascinating, yet quite minute compared to infinity!

To understand what this limit on the mind’s processing power implies think of the following scenario: If it takes a person 60 bits of information to comprehend what another person is saying, then theoretically one could be listening to two persons at the same time and understand both of them readily, since the total processing power of the mind is 120 bits (per second). But we all have experienced such a situation and we all are aware of the practical impossibility of such a (stochastic) event. The reason this is not practically possible lies in the fact that one’s consciousness is already occupied with existing thoughts, feelings, “incompletes” or “open loops”! Consequentially, if one liberates one’s mind by controlling one’s consciousness, then one could achieve flow. It exactly this conclusion that supports the ostensibly efficient system of personal organization put forth by Allen. In other words, if one frees up the mind by means of controlling consciousness (the processing unit of information), then one gives it the chance to process even more information (discovered or created), which one wouldn’t otherwise process.

In Csikszentmihalyi’s words, what Allen refers to as “incompletes” are, as a matter of fact, ” things that occupy the mind and reduce its capacity of processing information” (p. 30). This brings about the discussion on attention, whose intentional ordering of consciousness averts increased (psychic) entropy, thus reducing the chances of yielding disorder in the mind. On page 31 we read: “It is attention that selects the relevant bits of information from the potential millions of bits available. It takes attention to retrieve the appropriate references from memory, to evaluate the event, and then to choose the right thing to do.” Hence, learning where to direct attention to implies controlling one’s consciousness. This means that one’s personal productivity could be flowing incessantly if one induces order in one’s consciousness. This is exactly what David Allen alludes to throughout his GTD book. (“The Art of Stress-Free Productivity” is, in fact, the book’s subtitle.)

In all, “The mark of a person who is in control of consciousness is the ability to focus attention at will, to be oblivious to distractions, to concentrate for as long as it takes to achieve a goal, and not longer. And the person who can do this usually enjoys the normal course of everyday life” (Flow, p. 31). Thus, if we can at least control what we want to get out of our brains and efficiently manage it through a working, actionable organization system, we should attain not only flow, but also professional productivity. Based on my preliminary evaluation of the GTD system, this has been indeed the case in my professional and academic life.

The main point to remember here is this: The reason why Allen claims you want to get things out of your brain is  what Csikszentmihalyi concludes: to free up (or at least attempt) your mind so that the information-processing power of your consciousness increases. If you (learn to) control your consciousness by steering attention attentively, then you bring about order in your mind (increased psychic energy). And, thereafter, flow comes into play and psychic entropy dissipates. Flow, in turn, provides for a stress-free life, which consequentially yields efficient personal productivity through an effectively implemented organization system, such as Getting Things Done. But the prime step to take is to collect and corral incompletes in one bucket, whence processing, organization, reviewing, and doing follow. I highly recommend the reader studies both books, especially Flow.

As a side note (to myself) I must confess that while reading and studying both books I observed patterns that were always present in my life, but which I could not eloquently articulate at least to myself.

Computer-Supported Collaborative Work; or, my first PhD course

Throughout my academic experience, there is only a fistful of courses I valorized. The Computer-Supported Collaborative Work (CSCW) course I attended at UVic and taught by M.-A. Storey in the September 2011 semester is one of them.

The course was divided into three parts. The first part, spanning roughly four weeks, consisted of lecturing and blog posting. I found the latter to be quite beneficial in terms of gaining background knowledge in the field. We were assigned weekly readings (quite challenging and instructive); we were asked to blog on them and we would discuss them the in following class meetings. (In fact, what instigated this blog is the posts I wrote for the CSCW course blog!)

In the second part of the course, the “dive-in” section, we were supposed to organize student-led workshops pertinent to the theme of the course. We formed four groups comprising graduate and undergraduate students with a group having no less than four and no more than six students. We chose a topic amongst a pool of previously brainstormed topics and we had at least a month to organize and prepare for the workshop. My workshop was on e-Government and ran on November 1.

The third and last part of the course was about hands-on demonstration of the scientific concepts we gained in the first part and the manifestation of CSCW-compliant systems. We were also asked to keep a lab book of our activities. This part culminated in a final report and presentation on December 6. My project involved conceptualizing and implementing an awareness-providing visualization tool for collaborative software development. More on the tool can be found in my other post here.

Contemplating retrospectively, these three parts posited unique challenges and problems that required fast and efficacious solutions. I love to read and I thus fell in love with the first part of the course. I love to write and I thus enjoyed contributing to the course blog. I love to collaborate with others and I thus relished organizing and contributing to our workshop. I love to do research and to humanize results and thus I enjoyed the third part of the course.

I’m looking forward to attending similar courses in the future. I’m pretty stoked for the January 2012 Global Software Development course I’m taking with my supervisor, Daniela Damian! More on this later on…