Memorable feedback

I recently asked a couple of experienced software engineers (on different occasions) this question:

Tell me about a bit of useful feedback that’s stuck with you.

In each case, the answer was immediate and deeply personal. Each engineer described direct critical feedback they had received from a coworker years ago, about their communication style. When I say direct, I mean direct – maybe even harsh. They each took this feedback seriously, and have since worked hard to change their communication.

I know it’s a small sample, but I was surprised at the similarity in their answers, and the clarity with which they recalled the particular incident. There are probably several reasons for it. The most jarring feedback is most likely to stick in one’s memory. It’s also most likely to be a source of conflict, but maybe that’s what drives people to change.

My own answer to this question is not so direct.

I’m a little embarrassed to admit that the first thing that came to mind was not criticism I received from a colleague, but praise. I had a roommate in undergrad that once described the first time we met. We were in a freshman CS course together. The class, including the professor, had been puzzling over a problem on the whiteboard for a while. I, having said virtually nothing in class prior to that day, solved the problem at a stroke.

I’m sure he meant it as a compliment, but for me the story was a wake-up call. I was a smart kid, and a quiet kid. I quickly learned the synergy of those two traits, embodied in the phrase “Better to remain silent and be thought a fool than to speak and to remove all doubt.” (A sentiment with a long history.) By keeping quiet unless I knew the answers, I could look smarter than I was.

The problem with only speaking up when you know the answer is the missed opportunities to learn the answers you don’t know. I had enough model learners in my life to know this, but for some reason it didn’t sink in until I heard my roommate describe my behavior. Besides being obnoxious, I was wasting my time in school: Defending my ego when I could be learning more.

So I resolved to admit ignorance whenever possible. Asking questions when it seems like everyone else ‘gets it.’ Sharing my work before it’s finished. Saying “I don’t know.” By exposing the gaps in my knowledge I tried to become more teachable, not just by teachers but by peers as well. Since then I’ve learned that this habit maps to several desirable software engineer traits: Communication, curiosity, humility. The best engineers I’ve met do this too. I think it’s an important thing to learn.

CSSOM and CORS in Chrome 64

Every once in a while a programmer runs into a bug worth sharing.

Our team had one of those today. Students were unable to use Design Mode in App Lab, but the issue only happened on Chrome, and only if the user had installed a browser extension that injects an external stylesheet into the page.

The problem was caused by a bad interaction between an unadvertised security fix in Chrome 64 and some old feature-detection code in our site meant to work around an issue with Internet Explorer 9. We had at least six members of our team investigating at one point.

Live and learn. We released a fix today in v2018-03-07.2. I’ve posted a more technical writeup on StackOverflow where it may be helpful to others in the future.

Feedback and the growth mindset

I was listening to TED Radio Hour’s “Nudge” episode today. The second segment features Carol Dweck, Professor of Psychology at Stanford and author of Mindset (2006). One exchange jumped out at me.

Carol: We condition [kids] to show that they have talents and abilities all the time, and we think this is the road to their success, but in truth the road to their success is learning how to think through problems, learning how to bounce back from failures. These are the things that create contributions to society.

Guy: So, as a parent, would it have a material impact on my own kids for instance, you know, on the way they kind of approach challenges, if I were to, instead of saying, “Oh, you’re such a great reader” but to say “I’m really proud that you read that book.”

Carol: You know, I wouldn’t say “I’m really proud” because it makes it yours. Then the next book they’ll read to make you proud, rather than because they value it or enjoy it. I would say “Tell me about that book you read, that’s really exciting!”

Guy: Wow, you’re going to completely change the way I parent.

Carol: You know everything sends a message. Just a few different words, sometimes one different word, conveys a whole different world of meaning.

I’m fortunate that many people in my life (parents, teachers, mentors) have nudged me toward a growth mindset. The phrase, “Tell me about that book you read, that’s really exciting!” reminds me in particular of my two grandmothers. I can hear each of them say those words, clear as a bell, in their own way. It’s language that emerges from a lifetime of caring deeply about people. I’m not sure if they also recognized it as a sound cognitive development strategy.

Thinking through each type of feedback:

  • “Oh, you’re such a great reader. (Your talent makes you valuable)
  • “I’m really proud that you read that book. (Your action makes me valuable, or makes you valuable to me)
  • “Tell me about that book you read, that’s really exciting!” (I value your action and your opinion)

I actually think there’s a time and place for each of these, but it’s easy to forget that third step. Growing up, I always knew that Grandma took an interest in what I was reading or drawing or building. I thought it was a natural way to reconnect after we hadn’t seen each other for a while. I’ve since learned that not everybody does this. It takes intentionality to always take an interest in others. It’s also one of the most important ways to help others grow.

Good Enough Golfers

Four gentlemen golfers on the tee of a golf course

Twenty golfers wish to play in foursomes for 5 days. Is it possible for each golfer to play no more than once with any other golfer?

Find out for yourself.

This is known in mathematics as the Social Golfer Problem. Over Thanksgiving 2017, my dad posed a very similar problem: 28 students in discussion groups of size 4, rotated five times so that no two students are grouped together twice – with additional constraints restricting certain students from ever being grouped together. Puzzling over the problem together led us into the world of combinatorics.

It turns out the Social Golfer Problem (and the closely related Kirkman’s Schoolgirl Problem) are solved, but full generalizations of them are hard – even for computers. I went looking for an existing solution and couldn’t find one I was happy with. Dad assured me that it didn’t need to be perfect, just good enough for a teacher trying to organize a group. So I built my own:

Good-Enough Golfers is a near-solver for this class of scheduling problems. It attempts to schedule g x p players into g groups of size p for w weeks such that players meet a minimum number of times. Real solutions to this problem can be extremely slow, but GEG’s approximations are fast and often good enough for real-world purposes.

It’s also free and open-source.