I am giving an iSkills Workshop for the Faculty of Information. Over two three-hour sessions, I take absolute beginners to writing a small programs to encrypt, decrypt, and break a Caesar cipher.
Posts Tagged → teaching
Showing Google Maps in JES
I’ve been teaching CCT 374: Technologies for Knowledge Media course this term. It seemed a natural fit to use a Media Computation approach to teach Python programming. Continue reading
A simple capacitive touch sensor
The final project for the Critical Making course is wearable technology. So this is a tutorial on a simple capacitive touch sensor.
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.
Using git and github from PyCharm
In last week’s class, I demoed using Sourcetree to manage your repositories. I didn’t show how to use the features in PyCharm for the same purpose.
Here are a some screenshots that should help.
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.
Seeking customers for student projects
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.
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.
What separates an “A” student from the rest
I have been teaching the same course at UCI for six, almost seven years now. The first time that I taught Inf111 was Winter Quarter, 2004. (Technically, it was ICS121 at the time. It wasn’t re-numbered until a couple years later.) I have learned a lot about teaching in those years, but that is a topic for another time. I have learned a lot about learning, but not enough. I have a couple of observations about students who do well, who get “A’s” in school.
An “A” student organizes their life in a way that allows them to succeed. This is the single most significant characteristic that separates an “A” student from a “D” student. An “A” student ensures that they has enough time to study and keeps distractions at bay. A “D” student has a fight with their significant other the night before the final exam, which keeps them up all night AND prevents them from studying.
An “A” student submits assignments on time. A “D” student submits assignments late or not at all. It’s a small thing, but it makes a difference.
An “A” student shows up. Lecture is not necessarily the best way to absorb new material, but it does provide two key benefits. One, it provides time with the material, which leads to familiarity and comfort with the material. It almost doesn’t matter what is covered during the lecture. Two, lectures are an opportunity for a student to assimilate into a culture. In other words, the student can learn the logic behind a discipline and how to structure an argument within the genre. This affinity is important for answering open-ended questions on tests and for solving open-ended problems in an acceptable manner.
An “A” student does well on the first evaluation. There is almost a perfect positive correlation between a student’s score on the first evaluation (no matter how large or small) with the student’s final overall grade in the course. This relationship sometimes makes me despair my role as a teacher, but it’s a central truth. Graduates from Ivy League schools do well, because they were doing well before they enrolled in the school.
An “A” student doesn’t necessarily start ahead of time. Some “A” students have a finely honed sense of the “last minute,” i.e. the last possible moment to start an assignment or studying for a test and still succeed.
An “A” student isn’t necessarily the smartest or most engaged person in the class. Intelligence helps, but the ability to organize one’s life trumps raw processing power.
So what does this say about education more broadly?
Students who don’t have support and orderly lives do less well. This describes a lot of working class and inner city kids. It’s almost like they are doomed before they start. And this is why we celebrate when a kid with a complicated home life succeeds– they have beaten the odds.
Good teaching matters more to students in the middle of the pack. Students at the head of the class tend to be capable book learners and can drive their own learning experience. Not everyone learns in this way. Classroom exercises, presenting material in other modalities, and accommodation of learning styles are ways that good teachers can make sure average students learn the material. “B” and “C” students need more help engaging with written material, and consequently innovative teaching has more impact on them. This tendency also has implications for working class and inner city kids, which is why programs like “Teach for America” are important.
Teaching “A” students is rewarding, because it provides a form of cheap and easy validation for me: I taught it, they got it. Teaching “B” and “C” students is rewarding, because it allows me to make a difference in outcomes. We’re comrades in the same war: while I struggle to teach well, they struggle to learn well.