... or at least differently. From Inside Google's Efforts to Engineer Its Food for Healthiness:
So, instead of merely changing the food, Bakker changed the foodscape, ensuring that nearly every option at Google is healthy -- or at least healthyish -- and that the options that weren't stayed out of sight and out of mind.
This is how I've been thinking lately about teaching functional programming to my students, who have experience in procedural Python and object-oriented Java. As with deciding what we eat, how we think about problems and programs is mostly unconscious, a mixture of habit and culture. It is also something intimate and individual, perhaps especially for relative beginners who have only recently begun to know a language well enough to solve problems with some facility. But even for us old hands, the languages and mental tools we use to write programs can become personal. That makes change, and growth, hard.
In my last few offerings of our programming languages course, in which students learn Racket and functional style, I've been trying to change the programming landscape my students see in small ways whenever I can. Here are a few things I've done:
By keeping functional tools closer at hand, I'm trying to make it easier for these tools to become the new habit. I've also noticed how the way I speak about problems and problem solving can subtly shape how students approach problems, so I'm trying to change a few of my own habits, too.
It's hard for me to do all these things, but it's harder still when I'm not thinking about them. This feels like progress.
So far students seem to be responding well, but it will be a while before I feel confident that these changes in the course are really helping students. I don't want to displace procedural or object-oriented thinking from their minds, but rather to give them a new tool set they can bring out when they need or want to.
At one point in this conversation between Elvis Costello and Tom Waits, the two songwriters discuss some of the difficulties they face in the creative process. Costello remarks that he sometimes writes notes that he can't sing, only to be disappoint himself when he gets into the studio. Waits commiserates:
Anything that has to travel all the way down from your cerebellum to your fingertips, there's a lot of things that can happen on the journey. Sometimes I'll listen to records, my own stuff, and I think god, the original idea for this was so much better than the mutation that we arrived at. What I'm trying to do now is get what comes and keep it alive. It's like carrying water in your hands. I want to keep it all, and sometimes by the time you get to the studio you have nothing.
This is something I notice all the time when I'm teaching. I'll have an idea for class somewhere: walking home, riding the exercise bike, reading something. My brain dives into the process of making the idea real: telling a story, writing code, explaining an idea in relation to things we've done in class before. Then comes deployment. We get into the classroom and... it feels flat. On rare occasions the new ideas bombs, but most often it just seems not quite right. It doesn't feel like what I had in my mind when I first had the idea, and I'm not sure how we ended up feeling the way we feel in class. The idea was so perfect.
Teaching ideas are abstraction. Teaching is concrete. It involves other humans. Their learning is what's important, and sometimes the idea doesn't make the connection intended by the teacher. The classroom is where reality sets in.
There is good news. Sometimes a disappointing or failed idea can be salvaged by analyzing the experience and redesigning the session. But most of the time it never feels as perfect as it did in my head at the moment of conception. Part of the art of becoming a teaching is making friends with this fact and moving forward.
I saw Robin Sloan's An App Can Be a Home-Cooked Meal floating around Twitter a few days back. It really is quite good; give it a read if you haven't already. This passage captures a lot of the essay's spirit in only a few words:
The exhortation "learn to code!" has its foundations in market value. "Learn to code" is suggested as a way up, a way out. "Learn to code" offers economic leverage, a squirt of power. "Learn to code" goes on your resume.
But let's substitute a different phrase: "learn to cook." People don't only learn to cook so they can become chefs. Some do! But far more people learn to cook so they can eat better, or more affordably, or in a specific way. Or because they want to carry on a tradition. Sometimes they learn just because they're bored! Or even because -- get this -- they love spending time with the person who's teaching them.
Sloan expresses better than I ever have an idea that I blog about every so often. Why should people learn to program? Certainly it offers a path to economic gain, and that's why a lot of students study computer science in college, whether as a major, a minor, or a high-leverage class or two. There is nothing wrong with that. It is for many a way up, a way out.
But for some of us, there is more than money in programming. It gives you a certain power over the data and tools you use. I write here occasionally about how a small script or a relatively small program makes my life so much easier, and I feel bad for colleagues who are stuck doing drudge work that I jump past. Occasionally I'll try to share my code, to lighten someone else's burden, but most of the time there is such a mismatch between the worlds we live in that they are happier to keep plugging along. I can't say that I blame them. Still, if only they could program and used tools that enabled them to improve their work environments...
But... There is more still. From the early days of this blog, I've been open with you all:
Here's the thing. I like to write code.
One of the things that students like about my classes is that I love what I do, and they are welcome to join me on the journey. Just today a student in my Programming Languages drifted back to my office with me after class , where we ended up talking for half an hour and sketching code on a whiteboard as we deconstructed a vocabulary choice he made on our latest homework assignment. I could sense this student's own love of programming, and it raised my spirits. It makes me more excited for the rest of the semester.
I've had people come up to me at conferences to say that the reason they read my blog is because they like to see someone enjoying programming as much as they do. many of them share links with their students as if to say, "See, we are not alone." I look forward to days when I will be able to write in this vein more often.
Sloan reminds us that programming can be -- is -- more than a line on a resume. It is something that everyone can do, and want to do, for a lot of different reasons. It would be great if programming "were marbled deeply into domesticity and comfort, nerdiness and curiosity, health and love" in the way that cooking is. That is what makes Computing for All really worth doing.
Campaign Security is a Wood Chipper for Your Hopes and Dreams
Practical campaign security is a wood chipper for your hopes and dreams. It sits at the intersection of 19 kinds of status quo, each more odious than the last. You have to accept the fact that computers are broken, software is terrible, campaign finance is evil, the political parties are inept, the DCCC exists, politics is full of parasites, tech companies are run by arrogant man-children, and so on.
This piece from last year has some good advice, plenty of sarcastic humor from Maciej, and one remark that was especially timely for the past week:
You will fare especially badly if you have written an app to fix politics. Put the app away and never speak of it again.
Know the Difference Between Neurosis and Process
In a conversation between Tom Waits and Elvis Costello from the late 1980s, Waits talks about tinkering too long with a song:
TOM: "You have to know the difference between neurosis and actual process, 'cause if you're left with it in your hands for too long, you may unravel everything. You may end up with absolutely nothing."
In software, when we keep code in our hands for too long, we usually end up with an over-engineered, over-abstracted boat anchor. Let the tests tell you when you are done, then stop.
People say, "if you love what you do you'll never work a day in your life." I think good work can be painful--I think sometimes it feels exactly like work.
Some weeks more than others. Trust me. That's okay. You can still love what you do.