Posts Tagged → teaching

Arena Notes | What to do about huddle puck?

When young children first start playing organized soccer, they play “huddle ball.” The energetic players all start following the ball around the field. Although, there are positions, such as forward, half back, and full back, nobody is playing them. This phenomenon can be attributed to lack of knowledge, lack of maturity, and simple enthusiasm. Kids start playing positions as they grow older and taught a better way. They become more skilled at passing the ball, so chasing is less effective. Also, a full-size soccer pitch is large, so it’s not feasible for player to follow the ball.

The same evolution happens in hockey. Kids start out playing huddle puck. They need knowledge, skill, and trust to play positions. There are a few factors working against us in house league.

  • There’s a lot of variation in skill level. Some kids can’t skate fast enough to keep up with the action. Some kids are highly skilled and are capable of carrying the play themselves.
  • The playing surface is smaller and skating is easier than running, so kids receive less negative reinforcement for chasing the puck constantly.
  • There’s a lack of trust in playing positions. They don’t trust the system. The kids don’t trust each other to be in the right place to take advantage of the positions.

Our team is playing huddle puck, and winning games. I’m worried about how long this will last. We are going to start losing to teams that play positions.

The professional coaches are emphasizing individual skills, so they’re not covering this area. I asked Coach Matthew about this and he said that it takes a long time for kids to learn this. He kindly found some videos for me and the kids to watch.

Whether or not we are successful, we need to start setting the expectation that kids play the position that they are assigned.

I don’t know how to teach this skill. I don’t have the experience playing or teaching. Since, I don’t have anything better to offer, I’m going to leave things be. It’s especially hard to mess with a winning record.

Running a DC motor from the Arduino Using the Creatron Economic Starter Kit

I’m teaching a Critical Making course and a question came up regarding how to run a DC motor from the Arduino. It was a bit tricky to get figure out how to do this using the parts in the Economic Starter Kit that students were told to purchase from Creatron, our local purveyor of maker stuff. There were a couple of puzzles, how to use the parts we were given and which online tutorial to follow.

I played around a bit and here is my result. I used the tutorial from bildr, which I found via the page for my MOSFET transistor on Sparkfun.

Continue reading →

Call for customers for Introduction to Software Engineering

It’s that time of year again, when I’m preparing to teach Introduction to Software Engineering at UofT. This will be my third time teaching the course and I have more students than ever, almost twice as many as last year. As part of this course, third-year students in computer science work in teams to implement a software application for a client. Consequently, a lot of the preparatory work is finding clients. Our clients have been non-profits, social enterprises, and schools that needed some software built. Here are some Q&A to help you decide if this is a good opportunity for your organization.

Continue reading →

Seeking customers for student projects

By diamondrefractionindex via flickr

I will be teaching CSC 301: Introduction to Software Engineering at University of Toronto this fall. The course is meant to teach software process for small teams, also known as agile. Students work in teams to complete a software project. I would like the projects to be for social enterprises to incorporate service learning into the course. As a result, I am now looking for non-profits or social enterprises who need some software built. Here are some Q&A to help you decide if this is a good opportunity for you.

 

Continue reading →

Seeking participants for an iOS/scrum boot camp

Idea: I want to put a small group of us (6-ish?) in a room for a week and develop an app. There may or may not be an iOS expert among us. We’d be using scrum/lean techniques and the goal is for each person to learn something new. The purpose of the end product is to demonstrate what we have learned.

Motivation: I need to become proficient at iOS programming. So, I am using this as an opportunity for me to conduct an experiment in alternative models for teaching software development/design, by holding a “boot camp” on the topic.

Who: Programmers, graphic designers, UX designers, and domain experts with some software-related learning objectives. You don’t have to be the best programmer or have any experience in iOS; you just have to be motivated and want to learn. For example, you might be a programmer, but always wanted to try your hand at project management. Or you might run a non-profit and want to learn how to give requirements for some software. Or you may be graphic designer who wants to get more involved in programming.

Who Not: This boot camp is not suitable for people who are expecting a lecture and well-crafted assignments. It is also not a for someone looking for free labour to develop the app that they have been planning for a long time.

Where: Toronto, either at a home in the Yonge/Lawrence area or at UofT

When: First week of August. I imagined this to be 4-5 days, 9-5-ish with lunch breaks. But if I get enough interest from people who have day jobs, we might do this over two weekends. I am also looking into the possibility of providing childcare for participants.

How: We will be working in pairs most, if not all, of the time. We’ll be doing short (1-day) sprints. We’ll work hard, but we’ll have a sustainable pace. We will all be working on an app together– I make no promises on the quality of the final product. The app itself with depend on the learning objectives of the participants, and we will decide together during the planning meetings.

Next Steps: Drop me an email (benevolentprof at gmail) to let me know you’re interested. Tell me a bit about yourself, your availability, and what you’d like to learn at the boot camp. We’ll have one or two meetings in advance to identify our collective goals for the boot camp and to do some scrum planning.

How a disciplinary paradigm teaches us to see and not see

I read two articles today back-to-back, though they came from different sources. They represented completely different world views and the conceptual distance between their respective disciplinary paradigms was breathtaking.

The first article came to me via a regular email from the IEEE Computer Society. It was by Phillip Laplante on cultural factors in software development. The article discusses Geert Hofstede’s work on five dimensions of social norms that could be used to characterize any culture. These dimensions are power distance index (PDI), individualism (IDV), masculinity (MAS), uncertainty avoidance (UAI), and long-term orientation (LTO). Each of these dimensions exemplified by choices in software process, for instance:

Are software engineers in low-LTO countries more likely to favor a code-and-fix approach to formal methods? Are software engineers in high-LTO countries more likely to favor spending more time on requirements engineering and less on testing?

Laplante is part of a task force charged with developing a professional licensure examination for software engineering. Consequently, he is wrestling with the question of whether it is reasonable to have the same exam in every region. His interest in Hofstede’s work is driven by the desire to be culturally sensitive. He gave data for five countries and asks questions such as:

Would software engineers in Malaysia (PDI = 104) use fewer techniques (such as reviews) that require higher management participation than in Ireland (PDI = 28)? How widely are group reviews (and the concomitant criticism) used in the US, where individualism is high (IDV = 91) versus in India (IDV = 48)?

I wasn’t especially interested in the work on the licensure exam, but I was intrigued by the Hofstede dimensions. I thought it was pretty interesting that culture could be distilled down to five dimensions and wondered how I could use this in my research.

The second article was forwarded to me by a colleague. It was a news article from the Program in Human Rights at Stanford University on a talk by a faculty member, Kentaro Toyama on ten myths about technology and development.

There is a lot of interest right now in humanitarian technology, and information and computational technologies for development (ICT4D). At the last CHI conference, there was a notable number of papers on this topic. Also, I co-authored a paper with Don Patterson on this topic.

Each one of Toyama’s myths resonated with me, so it’s hard to choose favorites, but here are a few.

Myth 3: ‘Needs’ are more pressing than desires: A high proportion of the income of the very poor goes on what Western observers might view as ‘luxury’ items: (music, photos, festivals & weddings) rather than ‘basics’ such as healthcare.

Myth 6: ICT undoes the problem of the rich getting richer: In contexts where literacy and social capital are unevenly distributed, technology tends to amplify inequalities rather than reduce them. An email account cannot make you more connected unless you have some existing social network to build on.

Myth 8: Automated is always cheaper and better: Where labor is cheap and populations are illiterate, automated systems are not necessarily preferable. Greater accuracy may be another reason to favor voice and human mediated systems.

Toyama caused me to seriously re-assess my reaction to the first article. There’s no way that Hofstede’s dimensions would help anyone trying to make their way in or design for the developing world that Toyama described. Laplante’s article belied an engineering mind set, where people are instruments, i.e. operators of machines and machine processes, who are in turn instruments of the machine. Toyama’s myths belied a humanist mind set, where people are fully-fledged autonomous individuals who live in a context.

As a positivist, Hofstede is trying to look for rules and generalizations about people. He’s trying to turn them into abstractions in a model, which can then be used to reason with. Furthermore, he’s turning the context into an input.

In contrast, Toyama is exquisitely sensitive to people as individuals in a context. Context is all. He’s trying to get you to really see what’s there, rather than your preconceived notions (or your model) tell you should be there.

It occurred to me if you take either point of view, you would never see the other, because of the blinders inherent in each. An engineering viewpoint is what gives rise to the misconceptions that are Toyama’s myths. By the same token, someone with a humanist viewpoint working in context-specific ICT4D would never arrive at a set of five dimensions for characterizing national cultures.

So, is one viewpoint (engineering vs. humanist) better than another? Part of me is very uncomfortable with looking at people and machines merely as instruments. I am much happier looking at people as loving-feeling-dreaming-jumping persons. But at the same time, I’m not sure that poets would design the best technology.

The solution is to be multi- or inter-disciplinary. Becoming steeped or indoctrinated into more than one discipline allows one to see the limitations and assumptions built in each disciplinary paradigm. I often say that asking someone to describe their own culture is like asking a fish to describe water. If you’ve never been out of your culture or water, you’d never see it.

This sentiment is echoed in a blog post that I also read today by Jim Coplien where he writes about the relationship between (software) engineering and the arts. “Cope” takes the middle ground and argues for the importance of both. I’ll let him have the last word.

You can’t study everything, but conquering complexity requires first a human outlook, then a social perspective, and finally a grounding in the arts. A good liberal arts education can raise your awareness about the human side of the world and about what matters to people. A grounding in user experience why the design of a computer interface (or any machine interface) is important and why it is hard. Psychology has everything to do with good computer system design. Literature and history can offer you cultural perspectives that make it easier to work into a shrinking world market. Architecture can help you articulate the complexity of design.