An alternative to the content exposition mode of lecturing

- Gautham

At lunch we were having a discussion about the role of lectures in education. There is a lot of talk now about "reversing" (or is it "inverting"?) the classroom and about how lectures are not very valuable in their current form.

I think in some ways that is because we are doing the lectures incorrectly. Most lectures feel like an exposition of content. The "course content" in fact. We talk of the lecture "covering" some part of the course's content. These bits of content are the facts that a student is expected to know by the end of it. It also includes the skill to complete certain tasks.

The idea these days seems to be that a lecture is a poor way to communicate knowledge, and that the skill to complete certain tasks is best obtained by the student "doing."

I get fairly heated up when I perceive that "learning by doing" is being put on a higher pedestal than the alternative. Part of my angst is because I am exposed often to situations where a person, sometimes my past self, knows how to "do" something and has been doing it for years, but does it all wrong: Science that is gravely flawed because folks valued doing way over anything else, ugly computer programs, poor lindy hop/balboa on the dance floor, and dangerous and inefficient weightlifting technique in the gym. Everyone is nominally "completing task" but many do it very poorly. I also perceive very clearly how my skill in those four things have been dramatically improved by instruction of various forms.

The issue is that the counterpart to "learning by doing" is usually "learning by listening to content exposition," and that alone has not helped me all that much since I am good at absorbing content alone at a much faster rate from books.  Instead, I have gained tremendously from "observing a master at work and listening to their advice."

So if you are a lecturer, rather than teaching content, you can teach how to do your craft excellently. You can show how you work through a problem as a master of your craft. You can give advice on the wrong roads to take, as those options arise, which you know from your years of experience and constant self-improvement don't take you to a good place. You can show exactly how to hold the hammer so that the nail goes in straight.

If your craft is the development of ideas, you will devote your lecture to that, and there you have reason to go through lengthy derivations, but you will do so to teach your students how to derive new certainties efficiently and how to play with concepts.  I will gain from seeing your approach, and without thinking I will emulate the parts that speak to me, like I subconsciously try to emulate the posture of my dance floor and lifting platform heroes.

  In some ways this makes lecturing easier and in other ways harder. Teaching content is often somewhat boring for the lecturer too, but teaching the lessons one has learned while on the road to mastery comes naturally and with pride. On the other hand one has to be a master to teach like this.

Shortcomings of the GUIDE-inspired approach to programming Matlab GUIs

- Gautham

It is very difficult to make a Matlab GUI that can be reused and comprehended easily (i.e. clean) using the standard approach to building them. This approach is I believe inspired by the type of code produced by GUIDE, Matlab's automatic GUI code generation tool. GUIDE starts from a GUI layout made by the user and creates a code template for it. This approach necessarily puts the GUI front and center, to the detriment of the application design. In most important applications, the GUI should be a detail, not the organizing principle.

To illustrate, here is a code example for one of the simplest GUIs one could imagine: a click counter.

A GUI that counts the number of times the button has been clicked

Imagine that instead of counting clicks, the application is showing you a view of your carefully collected experimental data, and as you press buttons and click here and there, it makes modifications to your data and overwrites them in the disk. In other words, imagine that you care about what the application does.

Before going into the code for how to make such a GUI, first a few helper functions to lay out the GUI components.
Contents of gpndemos.makeFigure.m:

function figH = makeFigure()
    figH = figure('Position', [1 1 200 200]);
end

Content of gpndemos.makeClickMeButton.m

function uihandle = makeClickMeButton()
    uihandle = uicontrol('Style','pushbutton', ...
        'Position', [50 125 100 50], ...
        'String', 'Click me!');
end

Contents of gpndemos.makeTextBox.m

function uihandle = makeTextBox()
    uihandle = uicontrol('Style', 'text', ...
        'Position', [50 50 100 50], ...
        'FontSize', 40);
end

The code to launch the GUI is in gpndemos.makeClassicMatlabGUI.m (note that the second function, buttonCallback, is a local function contained within the file that defines makeClassicMatlabGUI):

function makeClassicMatlabGUI()
    figH = gpndemos.makeFigure();
    Hs.textbox = gpndemos.makeTextBox();
    button = gpndemos.makeClickMeButton();

    Hs.numberOfTimesClicked = 0;
    guidata(figH, Hs)

    set(button, 'Callback', @buttonCallback);
end

function buttonCallback(hObject, eventdata)
    Hs = guidata(hObject);
    Hs.numberOfTimesClicked = Hs.numberOfTimesClicked + 1;
    set(Hs.textbox, 'String', ...
        num2str(Hs.numberOfTimesClicked))
    guidata(hObject, Hs);
end

Then you run from the command line:

>> gpndemos.makeClassicMatlabGUI()

and the GUI will pop up and you can click the button and it will update the display.

It was a mystery to me initially how the single file above can produce a working GUI that persists after the function executes. The main function does three things. First it builds the GUI elements. Then it stores some data in the figure itself, and lastly it sets the action that should occur when the user presses the "Click me!" button. The second and third commands are the mysterious ones. A Matlab figure can be associated with a piece of data called the "guidata" - this thing is a regular Matlab structure (struct) and in our lab the convention is to give it the variable name "Hs". The lines:

Hs.textbox = gpndemos.makeTextBox();
Hs.numberOfTimesClicked = 0;
guidata(figH, Hs)

make sure that someone who has access to the figure will be able to figure out how many times it has been clicked on and the address of the textbox. That interested party is the function that executes when you press the button. Speaking of which, here is the line that tells Matlab what to do when the button is pressed:

set(button, 'Callback', @buttonCallback);

What is intriguing about this is that the function "buttonCallback" is a local function within the "makeClassicMatlabGUI" file, and you can never call it yourself from the command line or any other program you write, unlike the main makeClassicMatlabGUI() function. However, Matlab can call it when you click on the button. Matlab's rule is approximately that a GUI Callback can be set to any function that is "in scope" (accessible) at the moment you do the set(…) operation itself. In our program, we set the button's 'Callback' while running the "makeClassicMatlabGUI" file, and the buttonCallback local function is certainly available at that time. By this mechanism, the button can execute a local function within makeClassicMatlabGUI long after makeClassicMatlabGUI() has finished executing.

Looking above at the code for buttonCallback, it does the following: First, it "beams down" the struct of data held by the figure. Then it increments the click count by one, and then it tells the textbox to display the new click count. Lastly, it "beams up" the updated struct to the figure.
There are many ways to explain the shortcomings of this scheme when building larger applications, but they are all consequences of the fact that the application is trapped within the GUI:

The GUIDE-inspired GUI design traps the application within the GUI

The "business logic" of the program is inaccessible from anywhere outside the GUI. In our example the business logic is just storing and incrementing a counter. There is nothing "GUI" about the concept of storing and incrementing a counter, but the standard design traps that idea within the GUI. To add features to this application you must directly modify the code, since there is no easy way to use or manipulate this application from another program. And since there is no easy way to manipulate the application from another program, there is no easy way to write tests for the business logic.
The first step to a better design is making the application directly accessible to the user, or at least to the programmer:

A freed application is accessible to the user directly.

GUIs are not the only interactive programs one can build in Matlab. In fact, Matlab has an ample and easy to use set of tools to create clean, reusable interactive program through its support for object oriented programming. We'll see how to do that for our "Click me!" example in a next blog post.

Where to find the truth

Gautham gave a awesome group meeting today all about software design. In the course of his presentation, we finally found where the truth is.

(Quote taken from Robert Martin's "Clean Code", p. 54.)

How do you know you're an adult?

I was just shoveling the snow the other day, which always seems to lead to some sort of internal reflection. I was thinking about being an adult. I think I qualify now, mostly, and I was wondering what some of the criteria are. Here’s a few thoughts I had:

You’re an adult if...

1. You’re no longer automatically better at everything just because you’re two years older.

2. You no longer want to be like everyone else, but rather wish you weren’t just like everyone else.

3. You no longer miss your mom when you’re sick.

4. Growing out of your clothes is no longer a good sign. (Sydney)

5. You would love to debate existentialism in early 20th century film, but these dishes sure as hell aren't washing themselves.

Any other thoughts?

What not to worry about when you submit your paper

When I was a graduate student, I used to really worry about the little details of manuscripts when submitting a new paper, like whether it fits in the length requirements or specific figure lettering requirements or how the figures might fit on a page or whatever. I think I know why: it felt like something I could control in an otherwise very opaque and essentially random process. I now think it really just doesn't matter. Yes, try and keep to the basic spirit of the journal (a 50 page treatise on the mathematical details of burst modeling probably doesn't belong at Science), and get some very basic things right like citation formatting, but beyond that, don't sweat the length limits and so forth. Your job at this stage is to convince the editors that it's interesting and to convince the reviewers that its interesting and sound. Reviewers rarely read the supplement, so I when in doubt, put it in the main figure. If you're lucky enough to get your paper accepted or close to it, then great! Now you can worry about all those details, hopefully with some help from the editors.

So write clearly and compellingly, make attractive and easy to parse figures, and don't worry about the small stuff. Hopefully, you'll have plenty of time for that later!

Was it luck?

I think I’ve written about this topic before, but I just saw this TED talk that got me thinking about it again. In this talk, the speaker describes an experiment in which he sets up a rigged Monopoly game between two randomly selected contestants, rigged in the sense that one of the contestants gets way more money and so forth than the other. The interesting thing is that even though both contestants plainly know that the game is rigged and that’s why the rigged contestant wins, when questioned about why she or he won, the winner will say that it was due to their good strategy or good moves or whatever. Apparently, this sort of rationalization is a common psychological reaction.

I wonder if the same thing is at play in scientists. I think that if you ask most successful scientists, they would say that they succeeded due to hard work and a bit of talent, perhaps even pointing out a couple of particular insights that they made along the way. Some might say luck, but probably many of them don’t really mean it. But when look at my own career so far, I have to admit that whatever modicum of success I’ve had is perhaps more stumbled into than earned. I mean, how many choices did I really make, at least that were really consequential? How many were instead the product of the sheer luck of someone knowing someone in the right place at the right time? They say fortune favors the prepared mind, but I think it’s even more true that fortune favors the fortunate.

Apple, Google, and privacy

There seems to be a notion out there that Apple is better than Google when it comes to privacy. Maybe, can't say that I follow that stuff too carefully. But I'm wondering how much of that is because of Apple's utter inability to deliver competent online services than anything else...