Author: Robin

Posted on

Job satisfaction findings from last century

Bill Buxton, in a presentation at CHI 2011, recommended the work of Melvin Kransberg, a pioneering historian of technology. Kransberg apparently published the definitive textbook on the subject, but that is many pages and several volumes long; instead, I read By the Sweat of Thy Brow (1975) by Kransberg and Joseph Gies.

It is worthwhile to read a decades-old book now and then to remind yourself that many of the important problems of today were also problems of the past. What’s most astonishing is how many solutions exist that were proven decades ago, yet are still not widely known, let alone widely implemented.

I found the most interesting examples of this in By the Sweat of Thy Brow to be the solutions for job satisfaction. I leave you with a series of quotes.

…the classic (1932) British motivational study of girl workers threading embroidery needles…. The girls were told first that they had to thread a hundred dozen needles a day instead of the seventy-five dozen they had been threading. The announcement produced consternation that turned into delight when it was added that on finishing the hundred dozen they could go home. They got through the new quota in time to leave at 2:30 in the afternoon.

•

At [a Bell Telephone Company plant], phone directories were formerly compiled by women employees each of whom performed only one of the 17 operations necessary in compiling a directory…. Management found itself endlessly hiring and training new workers. Under the job enrichment ideology, each worker was given an entire directory to compile, performing all 17 steps, from scheduling to proofreading. Turnover dropped substantially.

  •

Frederick Herzberg, a prominent industrial psychologist, has identified [in 1966] five factors as strong determinants of job satisfaction—achievement, recognition, work itself, responsibility, and advancement…

 •

‘Perhaps the most consistent complaint reported to our task force,’ said the Work in America study, ‘has been the failure of bosses to listen to workers who wish to propose better ways of doing their jobs.’

Posted on

What motivates a child?

That seems like a simple enough question.  If you asked a selection of teachers, parents, and psychologists to answer it, I wonder how their answers would differ from each other.  Is it a solved problem? Or a complex mystery on the frontier of science? Or somewhere in between?

Posted on

The myth of ability

“Historically, societies have always been divided by myths of difference: between peasants and nobility, slaves and slave owners, or minorities and majorities. Today, the most pervasive and enduring of those myths — the myth of ability — is being challenged.”

-John Mighton (The Myth of Ability)

Posted on

There are no excuses for letting children fail

John Mighton writes in The Myth of Ability:

As far as I am aware, no program in mathematics was ever developed with the expectation that every child in the program would excel. To most educators, the idea of an entire class doing well in any subject seems absurd.

That was published in 2003, but today it is still widely assumed that the “curve” in test scores is a “natural” result of innate differences in human intelligence.

Through a tutoring program that he later extended to classroom teaching, Mighton showed that in fact every child could excel. And he found that such a result requires only two essential ingredients (which match my definition of profound: obvious only in retrospect). They are:

1. The teacher must actually believe that every student can excel.

2. The curriculum and teaching methods must be designed, tested, and refined in a way that treats any student’s failure to learn as being a failure of the curriculum and teaching methods.

This is entirely analogous to creating usable software. Instead of blaming problems on “user error,” you blame the software — and, critically, use that knowledge as an opportunity to improve the design. Creating great software is not easy, but it’s also not rocket science.

Mighton has experimented with various best practices in teaching, many of which have been well documented elsewhere in the psychology literature (and popular literature by authors such as the Heath brothers, Malcom Gladwell, Carol Dweck, Martin Seligman, etc.). For example, he neatly sums up the research on the importance of flow:

Nothing focuses the attention of children more sharply than the feeling that they are meeting a series of challenges and succeeding brilliantly.

But the crucial thing that John Mighton has shown is not in the particulars of his curriculum or philosophy. Rather, it is the simple, incontrovertible fact that he made every single student succeed in math — without requiring extra money or super-human energy or even teachers who previously knew anything about math.

It is an existence proof.

And it means that all of the excuses are bogus. “They can’t focus.” “They don’t care.” “There’s not enough time or money to get through to them.” Every student brought to him as “unteachable” was in fact taught to excel. And it was not even particularly difficult. It was certainly not rocket science.

But if we know how to teach in such a way that every child succeeds, why are we not doing it? Mighton says,

I believe the answer lies in the profound inertia of human thought: when an entire society believes something is impossible, it suppresses, by its very way of life, the evidence that would contradict that belief.

I think it’s harder than that, and a good analogy is racism or sexism. When injustice is ingrained — when “that’s the way it has always been” — elaborate excuses and rationales must be crafted to avoid the conclusion that well-meaning people are perpetuating discrimination (in this case, discrimination against the very students they purport to help). It’s a terrible conclusion to come to. To accept it means admitting that for decades we have been undermining the potential of millions of eager young students.

After seeing how children flourish with even a modest amount of attention, I have come to believe that when a child fails a test it should be regarded as a failure of our system of education. And when millions of children, year after year, fail tests they could easily pass, it should be regarded as the failure of an entire society to care for its young.

Supporting change implies acceptance of this terrible conclusion: that for generations we have been letting students fail, letting poverty persist, and letting the economy correspondingly sink — and that there is no excuse for it. How can we live with that guilt? Especially as a student or teacher in the system that is perpetuating the injustice — someone who has the power to make change?

I think that Dweck’s “growth mindset” is a good place to start. It helps us accept the truth as a learning opportunity to do better.

Because the fact is, we already know how to do better. And putting it off is only making the situation worse. As Matt Wilka and I concluded, “just do it!”

Posted on

Know the history

I found out today that IBM Research was working on scenarios for computers in education as early as the 1960’s (when programming meant feeding stacks of punched cards into a machine the size of a building).

Posted on

Automation vs. ownership

“Where once workers enjoyed their work but were unable to produce enough to give themselves leisure and material satisfactions, now they are gaining the leisure and material satisfactions while losing the enjoyment of work.”

-Melvin Kransberg & Joseph Gies, By the Sweat of Thy Brow (1975)

Posted on

Being too clever

“Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it?”

-Brian Kernighan

Posted on

Don’t reinvent the world

“Our job is not to reinvent the world; it’s to take stuff that we know exists already — but hardly anyone’s got it — and get it out to them.”

-Steve Jobs, 1997 [link]

Posted on

It’s all about managing complexity

When I was working on a natural language processing system at Johns Hopkins during the summer of 2005, I remember having a minor epiphany: I realized that the strategy our research team was using was essentially just a way of converting an intractably complex problem into a series of computable smaller problems. It didn’t take me long to make the jump to realizing that this is an essential part of all science and engineering.

I was reminded of this when watching a Steve Jobs video recording from 1997 (via daringfireball). Steve is talking about why he thinks better developer tools and APIs are so important to progress (around 25 minutes into the video):

It’s all about managing complexity. It’s like scaffolding, right? You erect some scaffolding and if you keep going up and up and up, eventually the scaffolding collapses of its own weight. That’s what building software is. It’s how much scaffolding you can erect before the whole thing collapses of its own weight. It doesn’t matter how many people you have working on it — doesn’t matter if you’re Microsoft, with 500 people on a team — it will collapse under its own weight.… These [new developer tools] allow you to not have to worry about 90% of the stuff you worry about, so that you can erect your 5 stories of scaffolding, but starting at story number 23 instead of starting at story number 6. You can get a lot higher.

This is related to the fundamental notion of abstraction, and to “the mythical man-month” (which Steve also references). It’s a good reminder.

In a related section, Steve responds to a question asking about how visual programming tools might fit into this. His answer (around 42 minutes in):

Here’s the deal. The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. The way you get programmer productivity is by eliminating lines of code you have to write. The line of code that’s fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write! So the goal here is to eliminate 80% of the code that you have to write for your app. That’s the goal. So along the way, if we can provide vizi-this and vizi-that and visual this and visual that, well that’s fine, but the high-order bit is to eliminate 80% of the code. When you ‘draw the line’ in interface builder, you’re eliminating code of one form. But that only goes so far. Maybe we can go further. I’ve seen a lot of demos of things that try to take it all the way back into the algorithmic part of the codebase, and none of them have ever been any good. If there are any good ones out there, show them to me — I’d love to see them.

In other words, abstraction is far more important to productivity than whether a language is visual or textual. Making languages visual is only a win if it can help solve the “higher order” issues: bugs, maintenance, and complexity. Steve’s 1997 claim is that he has not seen compelling demos of this in the visual programming space.

I think this is crucially important to keep in mind when thinking about visual programming languages that could be generally adopted. They have to provide an advantage in terms of abstraction. It seems that so far the opposite has been true: abstraction has been the main weakness of visual programming systems.