I needed to write up a statement of my teaching philosophy for a job application I’m submitting shortly, and it just seemed like the sort of thing worth sharing. So here you go. Constructive comments welcome.


My teaching philosophy centers on my core values. I highly value practicing compassion and empathy for students; I value digging deep into the joy of learning something new and mind-expanding; and I believe in making learning as fun as possible.

Compassion and empathy can easily be mistaken as running counter to “rigor” or serious learning. However I see them as being central to creating a learning environment where everyone can feel safe enough to dive heavily into seriously challenging skills and ideas. This is pretty easy to do with students who you feel a connection with because of common interests, backgrounds, etc, but to make a classroom safe for all students can often mean deliberate, soul-searching work. I believe this really deeply matters to the lives of students, and to the future of our STEM professions which we want to see diversify.

I really enjoy the challenge of learning, and I love seeing students experience that same sense of mastery when they understand something that used to be incomprehensible. I’m also awfully stubborn about assessing students in ways that demonstrate deep understanding rather than shallow recall. I’ll check for small details here and there, but I would much rather see that students can be handed the sorts of information they could’ve looked up online anyway and see them work out something challenging with it.

I also believe that all of the above can create a fun atmosphere to learn in. Difficult challenges in a safe environment are a foundation for engaging gameplay, and I believe a classroom can be this best kind of game. It’s not easy, but I’ve seen glimpses of it and I want to see more of it in my teaching career. This has to be deeply challenging stuff, and it has to be safe enough that failure isn’t a game-breaker. (For more on this, you can read this blog post of mine from a few years ago.)

Here are some examples of how I’ve worked towards this in practice.

My usual classroom assessment practice has quickly settled on using “standards-based grading”, something that’s been slowly growing in usage in math education circles via blogging and Twitter networking. SBG is based on the idea of tracking ideas/skills assessed, rather than tracking individual assessments. It takes a bit more planning up-front but allows for much easier reassessment along the way and helps move assessment more towards being a measurement of learning rather than a collection of abstract points.

I spent one year developing and running a digital media program for Abbotsford Middle School which I focused mostly on Scratch-based narrative, art and game development. This was an incredibly valuable time for me as I got to see first-hand the value of wide-open, inclusive access to computing education – and it was FUN! Students from diverse backgrounds, ability levels and of both genders regularly surprised me with their accomplishments and enthusiasm. (For more detail on how I approached the program, here’s another blog post.)

Another goal I have strived for in my teaching is to emphasize active learning in the classroom instead of passive listening. I have worked with low-tech “clickers” for in-class polling, random-group standing whiteboard work for exploring new mathematics, and whole-class assessments that drive students to collaboration and discussion. While I am very capable at explaining ideas on a whiteboard, I believe that students who are actively processing new ideas in the classroom are more engaged with the learning itself, are more likely to form a healthy learning community, and will walk away with more self-efficacy than if they simply hear me explain things in a clever way.

For more examples of my thoughts on teaching, as well as a cross-section of some of my other interests, I encourage you to browse around my past and current blogs:




thank you,

– josh giesbrecht

I need to recap earlier chapters, but I’m currently reading the chapter on Advanced Actions and this bit just grabbed me in that “just blog this immediately” sort of way.

12.10. Action variables

And we will want the photographing action to have the player use the best-quality camera which comes to hand. We will give the action a variable called the ‘camera photographed with’, thus:

The photographing action has an object called the camera photographed with.

Every action’s variables must be named differently from those of all other actions, because there are some “before” rules (for instance) which take effect for many different actions, and which might need access to any of their variables. So action variables should be named in a way marking out to which action they belong. The best way to do this is to include the past participle of the action name – just as “camera photographed with” contains the past participle “photographed” of the action “photographing”.

A stuffy OOP programmer could look down his nose at this – why, you’re asking me to simply name global variables with an identifier???!?! What about encapsulation?!!!

And yet, the solution results in totally reasonable, fully comprehensible English. After all, language isn’t encapsulated. Oh, sure, there are some things we understand best within a particular context, or meanings that change depending on context. But nothing’s stopping me from referring to calipers while in a kitchen. The English language has no mechanism for programming’s encapsulation, and yet somehow we get by.

Inform’s definitions make me pause. I want to write a short post summarizing some main ideas: Things, which are sort of like objects; Kinds, which are sort of like classes; Actions, which are sort of like, well, functions with side effects; Values, which I guess are also like objects? Or instances? Or just values?

If I were learning nearly any other programming language, this uncertainty would be non-existent. Even when things are non-standard I could say things like, “Oh, well Lua can do objects but it implements them unusually via tables.” I think the reason I feel so uncertain here is that Inform is under no pretense of writing a manual aimed at programmers.

Here’s a fantastic example, from the start of the chapter of Writing with Inform on “Kinds”:

4.1. New kinds

Values are to Inform what nouns are to English sentences. They represent numbers, times of day, pieces of text, places, people, doors, and so on. Because they have such an enormous variety, and because we often want to talk about what some of them have in common, we need a way to sort all of these different ideas out. That’s the main aim of Inform’s concept of “kind”.

I’m all well and good with what nouns are, but the programmer part of me wants to scan for words like “variable”, “object”, “constant”, or even “type”. Inform avoids these programmerly terms with such consistency that it simply can’t be an accident. It’s like the authors are saying, “Look, we talk about kinds of things because that’s the kind of thing that people understand. If we go on about classes somebody’s going to think they’re going to be assigned homework and start having flashbacks of that final exam they failed in tenth grade, and we can’t have that.”

The other reason for caution is that Inform isn’t doing things the way I’m used to. It’s not primarily a procedural language, but a rule based one. Rather than defining a main loop and writing interface code and programming logic in sequence, you simply define what exists and what rules govern the way things relate to each other.

visual index of an Inform project
The index that Inform generates for your project gives a good high-level idea of how it defines and classifies your code.

So I’m tempted to compare Inform’s ‘kinds’ to classes. But there are important caveats. Kinds aren’t meant to visually encapsulate or organize code in the way that object-oriented programming usually does. You can define verbs and relationships that act on particular kinds of objects, but those definitions exist wherever you decide to put them in your story file. Verbs in this case are sort of like a class method, but verbs themselves aren’t ‘attached’ to a class. It reminds me a bit of how Common Lisp handles methods, where the objects in question still have to be passed as parameters because of the list structure of CL code. In a sense CL methods are simply functions defined for a particular class of parameter. Similarly, Inform code can have verbs defined to operate on a particular kind of noun.

I’ve been a tagalong in parts of the Interactive Fiction community for quite a few years, and so learning to use Inform 7 has been on my backburner since it first arrived.  I’ve dabbled with it enough to contribute a few Very Small things, and attempted a proper game for the first ShuffleComp a few years back.  But each time I’ve began, I’ve hunted the manual for information and generally find myself so flabbergasted by Inform’s capabilities that I get derailed from simply implementing the small thing I was looking for.

This year I’ve had an Idea that I actually want to write out, and a motivation to do so.  So I’m going to pull together enough spare-time learning energy to work my way through “Writing with Inform”, the manual written by Inform’s creators.  (You can find the manual built into the Inform application, or downloadable / readable on the website.)

Inform is specifically designed for interactive fiction, the sort where you type commands and move about various rooms and pick up objects to solve puzzles and all of it is text.  Inform is also astounding in that its source code is fully readable English text.  Here’s an example from the manual:

4.2. Scripted Scenes

The player carries a lockpick, a smoke bomb, a grappling hook, and a pair of gloves. The description of the lockpick is “Effective on most kinds of key locks, it is a gift from your mentor in the discipline, old Wheezy.” The description of the smoke bomb is “Your last of these, so you should rely on it only when other modes of escape have vanished. It takes effect when dropped, producing a cloud of purple haze sufficient to fill a medium-sized room.” The description of the grappling hook is “Good for shooting at balconies and other sorts of overhang.” The gloves are wearable. The description of the gloves is “Black and shiny, with gripping material on the palms. Batman would be jealous.”

Reviewing Possessions is a scene. Reviewing Possessions begins when play begins.

Escalating Danger is a scene. Reviewing Possessions ends when Escalating Danger begins. Escalating Danger begins when preparations near completion.

To decide whether preparations near completion:
if at least two of the things which are carried by the player are seen, yes;

This isn’t the text of the gameplay – this is part of the source code that generates the game.

As you can imagine, this makes it pretty easy to read existing source code.  It also makes for a much friendlier introduction for those intimidated by this.kind(of, punct.uati(on)); .

But it’s still a programming language, not a natural language parser.  What this means is that while valid Inform code is readable English, not all readable English is valid Inform code.  Inform can be picky about punctuation choices, variable names, and structure just like any other language.  Writing it is still programming, with error messages and misunderstandings and a need for specific knowledge of the system.

It’s also somewhat overwhelming for me when I’ve merely dabbled, because it’s so incredible.  Inform’s rule-based system doesn’t map cleanly to the kind of programming I’m familiar with, and the system is capable of a great deal.

So, reading the manual!

I’m at a point where I need to summarize what I’ve read in order to make any more progress forward.  I’m blogging my summary because I like the idea of supporting the IF community with a bit more exposure, and because it forces me to process my thoughts more completely.  I’ll be writing from the perspective of a programmer who’s already familiar with C-style code and a handful of other paradigms, and will end up comparing and contrasting Inform’s terminology with usual programming concepts out of necessity.

If that’s the kind of thing you might find useful, great!  If not, drop back in a few months and I’ll be blogging about something totally different again.

If we’re going to focus on special triangles, might as well really focus on special triangles, right?

Rather than having kids label the “special” angles (multiples of 30 and 45 degrees) on a unit circle, I made up cardstock special triangles that matched the protractor-grid trig reference sheets.  Students labelled the side lengths with a hypotenuse of 1, and can then physically move them around on the unit circle as a reference.

Here’s the printable PDF. It should be the correct scale to match the printable sheet in the previous post (ie. the hypotenuse will match the radius of the printed circle).

special triangle cutouts

My class is a mix of students of different ages, many of which have taken this course before and some of which have taken the previous Principles 11 or 12, which had less of a deliberate focus on the special triangles.  So I haven’t pushed hard for everyone to use these, but a lot of the students have picked up on it and pull out the triangles to check solutions on quizzes or homework.