December 04, 2019 2:42 PM

Make Your Code Say What You Say When You Describe It

Brian Marick recently retweeted this old tweet from Ron Jeffries:

You: Explain this code to me, please.
They: blah blah blah.
You: Show me where the code says that.
They: <silence>
You: Let's make it say that.

I find this strategy quite helpful when writing my own code. If I can't explain any bit of code to myself clearly and succinctly, then I can take a step back and work on fixing my understanding before trying to fix the code. Once I understand, I'm a big fan of creating functions or methods whose names convey their meaning.

This is also a really handy strategy for me in my teaching. As a prof, I spend a fair amount of time explaining code I've written to students. The act of explaining a piece of code, whether written or spoken, often points me toward ways I can make the program better. If I find myself explaining the same piece of code to several students over time, I know the code can probably be better. So I try to fix it.

I also use a gentler variation of Jeffries' approach when working directly with students and their code. I try whenever I can to help my students learn how to write better programs. It can be tempting to start lecturing them on ways that their program could be better, but unsolicited advice of this sort rarely finds a happy place to land in their memory. Asking questions can be more effective, because questions can lead to a conversation in which students figure some things out on their own. Asking general questions usually isn't helpful, though, because students may not have enough experience to connect the general idea to the details of their program.

So: I find it helpful to ask a student to explain their code to me. Often they'll give me a beautiful answer, short and clear, that stands in obvious contrast to the code we are looking at out. This discrepancy leads to a natural follow-up question: How might we change the code so that it says that? The student can take the lead in improving their own programs, guided by me with bits of experience they haven't had yet.

Of course, sometimes the student's answer is complex or rambles off into silence. That's a cue to both of us that they don't really understand yet what they are trying to do. We can take a step back and help them fix their understanding -- of the problem or of the programming technique -- before trying to fix the code itself.

Posted by Eugene Wallingford | Permalink | Categories: Software Development, Teaching and Learning

December 02, 2019 11:41 AM

XP as a Long-Term Learning Strategy

I recently read Anne-Laure Le Cunff's Interleaving: Rethink The Way You Learn. Le Cunff explains why interleaving -- "the process of mixing the practice of several related skills together" -- is more effective for long-term learning than blocked practice, in which students practice a single skill until they learn it and then move on to the next skill. Interleaving forces the brain to retrieve different problem-solving strategies more frequently and under different circumstances, which reinforces neural connections and improves learning.

To illustrate the distinction between interleaving and blocked practice, Le Cunff uses this image:

interleaving versus blocked practice

When I saw that diagram, I thought immediately of Extreme Programming. In particular, I thought of a diagram I once saw that distinguished XP from more traditional ways of building software in terms of how quickly it moved through the steps of the development life cycle. That image looked something like this:

XP interleaves the stages of the software development life cycle

If design is good, why not do it all the time? If testing is good, why not do it all the time, too?

I don't think that the similarity between these two images is an accident. It reflects one of XP's most important, if sometimes underappreciated, benefits: By interleaving short spurts of analysis, design, implementation, and testing, programmers strengthen their understanding of both the problem and the evolving code base. They develop stronger long-term memory associations with all phases of the project. Improved learning enables them to perform even more effectively deeper in the project, when these associations are more firmly in place.

Le Cunff offers a caveat to interleaved learning that also applies to XP: "Because the way it works benefits mostly our long-term retention, interleaving doesn't have the best immediate results." The benefits of XP, including more effective learning, accrue to teams that persist. Teams new to XP are sometimes frustrated by the small steps and seemingly narrow focus of their decisions. With a bit more experience, they become comfortable with the rhythm of development and see that their code base is more supple. They also begin to benefit from the more effective learning that interleaved practice provides.


Image 1: This image comes from Le Cunff's article, linked above. It is by Anne-Laure Le Cunff, copyright Ness Labs 2019, and reproduced here with permission.

Image 2: I don't remember where I saw the image I hold in my memory, and a quick search through Extreme Programming Explained and Google's archives did not turn up anything like it. So I made my own. It is licensed CC BY-SA 4.0.

Posted by Eugene Wallingford | Permalink | Categories: Software Development, Teaching and Learning

November 27, 2019 3:42 PM

Maintaining an Online Presence

Earlier this year, many people were passing around this article about "re-learning how to be yourself online". Near the end the author reaches a set of questions that are motivating him:

Here I was retreating from the web because I thought my online presence was unimportant and inconsequential. Meanwhile, a foreign power was using its resources to pretend to be someone like me to try to influence someone like me. What kind of influence does that mean I really have? What kind of influence does that mean each of us has? And who fills that vacuum if we fail to fill it ourselves?

Given the size of my following on Twitter and the size of my blog's readership, it's easy for me to think my online presence is unimportant or inconsequential. When time gets tight and work crushes me down or other interests call, feeling that my writing is inconsequential can be all that it takes not to take the time to write. I have to remind that that is never been why I tweet or blog.

With so much of modern life happening online, sometimes it can feel as if online writing has much higher stakes than it really does, especially for someone with my limited audience. It's worth reminding ourselves that tweeting and blogging can be simple reflections of who we are, nothing more and nothing less. The stakes don't have to be high, and our influence can be small. That's okay. Writing has its own benefits, and connecting with readers, however few there might be, is a bonus.

I am unlikely ever to write much about politics here, so my influence is unlikely to fill a space coveted by foreign powers. Whatever influence I may have will come from being myself. I need to overcome the inertia of busy days and make time to write.

Actually, that is not quite right. Much as I mention in my first blog entry ever, linked above, I have amassed a folder of ideas for blog entries. I also have a single org-mode file containing entries to write. Some, like the item that became this post, consist only of a quoted passage or some other trigger and a single idea waiting to be expanded. The most depressing items in the file are a seemingly endless collection of partially-written posts, some nearly finished, that never quite crossed the finish line.

So: I need to overcome inertia and make time to finish. That is easier said than done some days. Writing takes time, but finishing often takes a surprising amount of time. Finishing also means putting the words out in the world for others to read. That feels risky for many different reasons, and our minds can trick us into thinking we are better off saving the file somewhere and never finishing. But I like to think and write, and connecting with readers, however few there might be, is a bonus.

Oh, and as we in America enter a long weekend dedicated to gratitude, I thank all of you who are still reading my blog after all these years. I appreciate that you spend even a few of your scarce minutes reading what I write. Indeed, I marvel at it. I hope you find it time well spent.

Posted by Eugene Wallingford | Permalink | Categories: Personal

November 25, 2019 6:06 PM

Demonstrating That Two Infinities Are Equal

I remember first learning as a student that some infinities are bigger than others. For some sets of numbers, it was easy to see how. The set of integers is infinite, and the set of real numbers is infinite, and it seemed immediately clear that there are fewer integers than reals. Demonstrations and proofs of the fact were cool, but I already knew what they showed me.

Other relationships between infinities were not so easy to grok. Consider: There are an infinite numbers of points on a sheet of paper. There are an infinite numbers of points on a wall. These infinities are equal to one another. But how? Mathematician Yuri Manin demonstrates how:

I explained this to my grandson, that there are as many points in a sheet of paper as there are on the wall of the room. "Take the sheet of paper, and hold it so that it blocks your view of the wall completely. The paper hides the wall from your sight. Now if a beam of light comes out of every point on the wall and lands in your eye, it must pass through the sheet of paper. Each point on the wall corresponds to a point on the sheet of paper, so there must be the same number of each."

I remember reading that explanation in school and feeling both amazed and enlightened. What sorcery is this? So simple, so beautiful. Informal proofs of this sort made me want to learn more mathematics.

Manin told the story quoted above in an interview a decade or so ago with Mikhail Gelfand, We Do Not Choose Mathematics as Our Profession, It Chooses Us. It was a good read throughout and reminded me again how I came to enjoy math.

Posted by Eugene Wallingford | Permalink | Categories: General, Personal

November 10, 2019 11:06 AM

Three of the Hundred Falsehoods CS Students Believe

Jan Schauma recently posted a list of one hundred Falsehoods CS Students (Still) Believe Upon Graduating. There is much good fun here, especially for a prof who tries to help CS students get ready for the world, and a fair amount of truth, too. I will limit my brief comments to three items that have been on my mind recently even before reading this list.

18. 'Email' and 'Gmail' are synonymous.

CS grads are users, too, and their use of Gmail, and systems modeled after it, contributes to the truths of modern email: top posting all the time, with never a thought of trimming anything. Two-line messages sitting atop icebergs of text which will never be read again, only stored in the seemingly infinite space given us for free.

Of course, some of our grads end up in corporate and IT, managing email as merely one tool in a suite of lowest-common-denominator tools for corporate communication. The idea of email as a stream of text that can, for the most part, be read as such, is gone -- let alone the idea that a mail stream can be processed by programs such as procmail to great benefit.

I realize that most users don't ask for anything more than a simple Gmail filter to manage their mail experience, but I really wish it were easier for more users with programming skills to put those skills to good use. Alas, that does not fit into the corporate IT model, and not even the CS grads running many of these IT operations realize or care what is possible.

38. Employers care about which courses they took.

It's the time of year when students register for spring semester courses, so I've been meeting with a lot of students. (Twice as many as usual, covering for a colleague on sabbatical.) It's interesting to encounter students on both ends of the continuum between not caring at all what courses they take and caring a bit too much. The former are so incurious I wonder how they fell into the major at all. The latter are often more curious but sometimes are captive to the idea that they must, must, must take a specific course, even if it meets at a time they can't attend or is full by the time they register.

I do my best to help them get into these courses, either this spring or in a late semester, but I also try to do a little teaching along the way. Students will learn useful and important things in just about every course they take, if they want to, and taking any particular course does not have to be either the beginning or the end of their learning of that topic. And if the reason they think they must take a particular course is because future employers will care, they are going to be surprised. Most of the employers who interview our students are looking for well-rounded CS grads who have a solid foundation in the discipline and who can learn new things as needed.

90. Two people with a CS degree will have a very similar background and shared experience/knowledge.

This falsehood operates in a similar space to #38, but at the global level I reached at the end of my previous paragraph. Even students who take most of the same courses together will usually end their four years in the program with very different knowledge and experiences. Students connect with different things in each course, and these idiosyncratic memories build on one another in subsequent courses. They participate in different extracurricular activities and work different part-time jobs, both of shape and augment what they learn in class.

In the course of advising students over two, three, or four years, I try to help them see that their studies and other experiences are helping them to become interesting people who know more than they realize and who are individuals, different in some respects from all their classmates. They will be able to present themselves to future employers in ways that distinguish them from everyone else. That's often the key to getting the job they desire now, or perhaps one they didn't even realize they were preparing for while exploring new ideas and building their skillsets.

Posted by Eugene Wallingford | Permalink | Categories: Computing, Teaching and Learning

October 30, 2019 3:30 PM

A Few Ideas from Economist Peter Bernstein

I found all kinds of wisdom in this interview with economist Peter Bernstein. It was originally published in 2004 and the updated online a couple of years ago. A lot of the wisdom sounds familiar, as most general wisdom does, but occasionally Bernstein offers a twist. For instance, I like this passage:

I make no excuses or apologies for changing my mind. The world around me changes, for one thing, but also I am continuously learning. I have never finished my education and probably never will.... I'm always telling myself, "I must sit down and explain why I said this, and why I was wrong."

People often speak the virtue of changing our minds, but Bernstein goes further: he feels a need to explain both the reason he thought what he did and the reason he was wrong. That sort of post-mortem can be immensely helpful to the rest of us as we try to learn, and the humility of explaining the error keeps us all better grounded.

I found quotable passages on almost every page. One quoted Leibniz, which I paraphrased as:

von Leibniz told Bernoulli that nature works in patterns, but "only for the most part". The other part -- the unpredictable part -- tends to be where the action is.

Poking around the fringes of a model that is pretty good or a pattern of thought that only occasionally fails us often brings surprising opportunities for advancement.

Many of Bernstein's ideas were framed specifically as about investing, of course, such as:

The riskiest moment is when you're right. That's when you're in the most trouble, because you tend to overstay the good decisions.


Diversification is not only a survival strategy but also an aggressive strategy, because the next windfall might come from a surprising place.

These ideas are powerful outside the financial world, too, though. Investing too much importance in a productive research area can be risky because it becomes easy to stay there too long after the world starts to move away. Diversifying our programming language skills and toolsets might look like a conservative strategy that limits rapid advance in a research niche right now, but it also equips us to adapt more quickly when the next big idea happens somewhere we don't expect.

Anyway, the interview is a good long-but-quick read. There's plenty more to consider, in particular his application of Pascal's wager to general decision making. Give it a read if it sounds interesting.

Posted by Eugene Wallingford | Permalink | Categories: General

October 27, 2019 10:23 AM

Making Something That Is Part Of Who You Are

The narrator in Rachel Cusk's "Transit" relates a story told to her by Pavel, the Polish builder who is helping to renovate her flat. Pavel left Poland for London to make money after falling out with his father, a builder for whom he worked. The event that prompted his departure was a reaction to a reaction. Pavel had designed and built a home for his family. After finishing, he showed it to his father. His father didn't like it, and said so. Pavel chose to leave at that moment.

'All my life,' he said, 'he criticise. He criticise my work, my idea, he say he don't like the way I talk -- even he criticise my wife and my children. But when he criticise my house' -- Pavel pursed his lips in a smile -- 'then I think, okay, is enough.'

I generally try to separate myself from the code and prose I write. Such distance is good for the soul, which does not need to be buffeted by criticism, whether external or internal, of the things I've created. It is also good for the work itself, which is free to be changed without being anchored to my identity.

Fortunately, I came out of home and school with a decent sense that I could be proud of the things I create without conflating the work with who I am. Participating in writers' workshops at PLoP conferences early in my career taught me some new tools for hearing feedback objectively and focusing on the work. Those same tools help me to give feedback better. I use them in an effort to help my students develop as people, writers and programmers independent of the code and prose they write.

Sometimes, though, we make things that are expressions of ourselves. They carry part of us in their words, in what they say to the world and how they say it. Pavel's house is such a creation. He made everything: the floors, the doors, and the roof; even the beds his children slept in. His father had criticized his work, his ideas, his family before. But criticizing the house he had dreamed and built -- that was enough. Cusk doesn't give the reader a sense that this criticism was a last straw; it was, in a very real way, the only straw that mattered.

I think there are people in this world who would like just once in their lives to make something that is so much a part of who they are that they feel about it as Pavel does his house. They wish to do so despite, or perhaps because of, the sharp line it would draw through the center of life.

Posted by Eugene Wallingford | Permalink | Categories: General, Personal, Teaching and Learning

October 25, 2019 3:55 PM

Enjoyment Bias in Programming

Earlier this week, I read this snippet about the benefits of "enjoyment bias" in Morgan Housel's latest blog post:

2. Enjoyment bias: An inefficient investing strategy that you enjoy will outperform an efficient one that feels like work because anything that feels like work will eventually be abandoned.
Getting anything to work requires giving it an appropriate amount of time. Giving it time requires not getting bored or burning out. Not getting bored or burning out requires that you love what you're doing, because that's when the hard parts become acceptable.

The programmer in me immediately thought, "I have this pattern." My guess is that this bias applies to a lot of things outside of investing. In software development, the choices of development methodology and programming language often benefit from enjoyment bias.

In programming as in investing, we can take this too far and hurt ourselves, our teams, and our users. Anything can be overdone. But, in general, we are more likely to stick with the hard work of building software when we enjoy the way we are building it and the tools we are using. Don't let others shame you away from what works for you.

This bias actually reminded me of a short bit from one of Paul Graham's essays on, of all things, procrastination:

I think the way to "solve" the problem of procrastination is to let delight pull you instead of making a to-do list push you. Work on an ambitious project you really enjoy, and sail as close to the wind as you can, and you'll leave the right things undone.

Delight can keep you happily working when the going gets rough, and it can pull you toward work when a lack of delight would leave you killing time on stuff that doesn't matter.

(By the way, I think that several other biases described by Housel are also useful in programming. Consider the value of reasonable ignorance, number three on his list....)

Posted by Eugene Wallingford | Permalink | Categories: Patterns, Software Development

September 14, 2019 2:56 PM

Listen Now

In a YC Female Founder Story, Danielle Morrill gives a wise answer to an old question:

Q: What do you wish someone had told you when you were 15?
I think people were telling me a lot of helpful things when I was 15 but it was very hard to listen.

This may seem more like a wry observation than a useful bit of wisdom. The fifteen-year-olds of today are no more likely to listen to us than we were to listen to adults when we were fifteen. But that presumes young people have more to learn than the rest of us. I'm a lot older than 15, and I still have plenty to learn.

Morrill's answer is a reminder to me to listen more carefully to what people are telling me now. Even now that can be hard, with all the noise out there and with my own ego getting in my way. Setting up my attention systems to identify valuable signals more reliably can help me learn faster and make me a lot more productive. It can also help future-me not want to look back wistfully so often, wishing someone had told me now what I know then.

Posted by Eugene Wallingford | Permalink | Categories: General, Personal

September 13, 2019 3:12 PM

How a government boondoggle paved the way for the expansion of computing

In an old interview at Alphachatterbox, economist Brad DeLong adds another programming tale to the annals of unintended consequences:

So the Sage Air Defense system, which never produced a single usable line of software running on any piece of hardware -- we spent more on the Sage Air Defense System than we did on the entire Manhattan Project. And it was in one sense the ultimate government Defense Department boondoggle. But on the other hand it trained a whole generation of computer programmers at a time when very little else was useful that computer programmers could exercise their skills on.
And by the time the 1960s rolled around we not only ... the fact that Sage had almost worked provided say American Airlines with the idea that maybe they should do a computer-driven reservations system for their air travel, which I think was the next big Manhattan Project-scale computer programming project.
And as that moved on the computer programmers began finding more and more things to do, especially after IBM developed its System 360.
And we were off and running.

As DeLong says earlier in the conversation, this development upended IBM president Thomas Watson's alleged claim that there was "a use for maybe five computers in the world". This famous quote is almost certainly an urban legend, but Watson would not have been as off-base as people claim even if he had said it. In the 1950s, there was not yet a widespread need for what computers did, precisely because most people did not yet understand how computing could change the landscape of every activity. Training a slew of programmers for a project that ultimately failed had the unexpected consequence of creating the intellectual and creative capital necessary to begin exploring the ubiquitous applications of computing. Money unexpectedly well spent.

Posted by Eugene Wallingford | Permalink | Categories: Computing, Software Development