Teaching Kids to Program

Every Tuesday night, a few of my friends at work and I head to a nearby youth centre to teach a class about programming to junior high school students. Our initial goal was to teach them javascript using codecademy‘s tutorials and our own guidance. We have failed to meet that goal.

On the plus side, we (and the kids) have learned things, and we’re sure it’s been a net positive experience so far, but we’ve got some changes in mind to make it even better. I’d like to share our situation, how our lessons have gone, what we’ve learned, and our plans for the remaining weeks of the program. Hopefully this can be of use to someone in the future, even if it’s just us when we try again.

Our Background

Our team is about half programmers and half people who work in other roles at the company. One fella in particular in our group has headed up the majority of the curriculum choices and plans for this program, and I’ve done my best to assist him along with a group of seven other volunteers. None of us have significant teaching experience – I think I might top the list with four or five courses as a teaching assistant. The class has about 15 kids at a maximum, and we tend to have 5 grownups in the room, teaching from 5:30 to 7:00 PM. We hoped that we would be a good natural fit for teaching programming as people who either know how to program or are learning it at present.

Our Plan

Initially, we believed that we’d be working with high school kids. Our plan was to use codecademy’s codeyear tutorial series to try to build a game of blackjack all the way from fundamental syntax. We worked through the first block of lessons in 20 minutes or so to review it, and felt like it would be reasonable to expect high schoolers to get through it in around 90 minutes. Then we found out it would be junior high students, and because we didn’t have anything else, we decided to give it a try as planned.

How the lessons went

(this is a lengthy narrative format; there’s a summary at the end)

Our first lesson plan was to introduce ourselves, get the kids to introduce themselves, show them how to get to the website, briefly walk through using it (type into the window, hit enter, follow the instructions, etc), and then loosely supervise the group, helping when necessary. The general plan worked well. The kids followed the instructions and typed things in, but only got through the first 3-4 lessons of the first block in an hour and a half. What was worse was that afterward we felt like we hadn’t taught much, and that the kids had gone through the motions, but hadn’t learned much either.

The next week we decided to keep the same approach because we had only a hunch that our lessons weren’t hitting their target. We knew that the kids would start to run into walls during the lesson if they weren’t getting it, so we did more codecademy with a bit of review of the concept of variables at the beginning of class. The kids did not seem enthused by the material, but they worked at it. One or two kids got to the end of the lesson block, and most of them got to lesson 6 or 7, about conditionals or loops. We took note of the failings of the codecademy tutorial and the sort of questions that we were being asked. Some of the kids clearly did get it, while most did not.

We discussed the situation before the third week. We felt like leaving codecademy would be abandoning our goal, leave the kids wondering what was up, and could leave our course without its core value. We wanted to try something else though, so we introduced the class to LightBot, a flash game where the object is to move a robot around an environment by giving it simple commands with a drag and drop interface.

This seemed to interest some of the kids more than the javascript, though it seemed to be a bit more confusing too (it required some understanding of functions to get through later levels, and our attempts to explain the concept in an odd context like the video game didn’t always get through. We noted that the kids were definitely doing more problem solving and were clearly more engaged on the whole.

Before week 4, the team researched MIT’s Scratch, CMU’s Alice, the Logo language, and simple Javascript canvas playgrounds, but nothing felt cool or easy enough to be a great choice. Then a member of our team found a program called Kodu, which blew us away, but the computing resources at the youth centre couldn’t handle it. We went back to the drawing board, and ended up using the second LightBot game in week 4’s class. The kids were much more savvy this time around, and several came to grasp the concept of simple loops and functions in the game’s context.

The following day, we had a phone call with an instructor who has run a number of short programs intended to teach kids about programming, and we barraged her with questions about her experiences and about what our goals should be. We found out that she had made use of Scratch, and that the kids in her program (who were a little younger than ours) loved it. She also had a fantastic takeaway for us — don’t worry about teaching concepts. It’s not important that kids leave our class with strong computer science fundamentals. They’ll do that naturally if they are excited about code when it comes up later in their lives. It’s our job first and foremost to bring a sense of joy to messing around with computers, and they’ll figure the rest out on their own.

To summarize, we began trying to teach javascript with a self-driven tutorial and hoped to convey concepts. We found that this approach was not working well, and that engagement rose when we played a game based around the concepts instead of working through examples. From there, we’ve been advised to aim for excitement and to worry even less about concepts. Motivation will make concepts take care of themselves down the road, so it should be our focus.

Next steps

Our current plan is to introduce Scratch using some teaching materials we’ve found*, along with our aim to excite and advice from a coworker who taught high school students in the past. After a week or two of introduction, we hope the kids can spend the last few weeks building their own scratch games/videos while we help them to get past any roadblocks they encounter.

We’ll be taking a more hands-on approach to teaching the Scratch program, having the kids see small sections of the steps played out and repeating them. We hope that we can bring more excitement to the class, give the kids an opportunity to create something, and let them take home a more positive view of making things with computers.

Conclusion

I don’t want to paint the image that the kids have been unhappy; the man who supervises the outreach program put our minds at ease by reminding us that if the class were totally awful, far fewer of the kids would keep coming back. We have just felt a consistent belief that we could do more for them, and we think that we’ve arrived on a better path now than when we started.

Also, as a final (nitpicky) note: codecademy is not a very good platform for teaching kids. The biggest nits for me to pick in the initial block of lessons is a lack of consistency and very difficult language / abstract examples. The first few variables you declare are myName, fullName, and myLastName — the kids got confused about why and whether the ‘my’ needed to be at the front of what they were writing.

Beyond that, names are often things like “array” for an array, or examples occur like a variable “word” which holds the word “this” or the word “that”. It’s entirely too complex and abstract. Attempting to explain an if statement evaluating the variable “word” which may have “this” or “that” inside it quickly turns into a “Who is on first” situation. These could be rewritten to use more concrete language. For example, a variable can be descirbed as being like a jar with a label on it that you put pickles or berries into. That level of concreteness would have made our task worlds easier.

We considered writing our own codecademy lessons to continue down the javascript path, but in light of the extra research we did, Scratch is by far the best route for kids in the age group we’re teaching. Codecademy has its place and is a great resource, but those initial lessons could be vastly improved.

Unrelated Addendum

As a final and very marginally related note, I tried writing this out on piratepad so that I could replay my writing process in an attempt to improve it. I ran into two major problems.

The horizontal resize bar decided to operate on hover or somehow to interpret hovers as mousedowns. Every time I moved the mouse, the text writing field started resizing itself. I resorted to being extremely conscious about keeping my mouse to the left of the margin bar, and using the keyboard for any window/tab switches or text selection I might make; it was a big darn pain.

Next, the pirate pad server apparently went down while I wrote. A “re-establishing connection” notice came up, and presented an option to “Reconnect” as the big clear nice-looking button. Doing so refreshed the page, which would have been great if the piratepad server had not just gone down. I checked its status using downforeveryoneorjust.me, and waited 5 minutes. It fortunately came back up! And to the service’s credit, my writing was preserved across the gap. The experience was very scary, and comes down to the simple UI issue of not suggesting a user reconnect without warning them to copy their text away first.

* If I find the URL to these lesson plans, I’ll insert it. If you’re looking for them after reading this and I haven’t done that yet, please email me.

Skills, the lottery, and my congratulations to Mixpanel

Mixpanel raised $10.25 Million in a Series A round led by Andreessen Horowitz (see Peter Levine’s post), and that is fantastic — my congratulations to Suhail and the gang for building a kickass product and team. I know they’ll continue to find success!

I have a personal story to share about Mixpanel, about being the wrong person at the right place at the right time.

The background

Last August I was an intern at Google working at their San Francisco office — just a fifteen minute walk from Mixpanel’s abode. I had a single semester of school remaining back in Canada and I was thinking about future employment. I responded to one of Mixpanel’s frequent hackernews job postings, and received a response from Anlu not long after.

We set up a time to come by their office, and I ended up a block away by mistake, so I showed up fifteen minutes late. They didn’t seem to notice — nothing but a warm welcome. I was quickly greeted by the team and went into the meeting room (it had a table in the middle; hence it is a meeting room) and we started the interview process. Everyone on the team took a turn, which is a great idea! They all need to be confident of a person’s skills before committing to work side by side with someone for years.

Over the next few hours, I grew to understand that these were smart, funny, friendly people who loved what they did. Suhail spoke often about how important it is to have passion for what you’re doing. I did my best to yield valid responses to their questions, and while I think I came off as a nice guy, I didn’t deliver world-class chops. I was largely unfamiliar with javascript, missed a simple solution to keep a dynamic ordering of a set of objects, and took my sweet time to write a full answer to a problem Suhail gave me.

Their ad had asked, “want to learn how to scale?”, and suggested they needed a back-end person. I like to play with *nix, but had no idea about the tools or processes involved in building scalable web applications or doing high volume data processing, so it appealed greatly. At the end of the day, Suhail asked how I felt about working on front end stuff, or whether my passion was for working on infrastructure related things. I told him (as I said just now) that I don’t really know javascript. That I don’t have design experience and can’t make pretty websites — but I’d love to learn how.

He told me that I simply made too many mistakes to work on infrastructure in their fast-deploying environment. Their philosophy (at the time, I have no clue now) was to ship as soon as what you have is better than what’s out there. He asked again if back-end work was my passion, and how I felt about the front-end. I defended my ability to write solid code, and echoed my willingness to learn, and I might have even said that cliche “I don’t know what my passion is yet”, because really, I don’t. Then we shook hands; a few days later I got confirmation that they’d moved on in their search, and a thanks for coming in.

That was an ego hit, but I am very thankful that Suhail gave me the advice. I made a lot of mistakes in that interview, and I saw that he was right in the larger sense: I probably would have made some mistakes and shipped code soon after at some point. Infrastructure code is too mission critical for to be incorrect. Until I improve, I have to work slowly and surely.

The Lottery

There is a stance that I could take regarding Mixpanel’s recent seed round (which is the sort of successful growth I expected from them when I interviewed). That stance is that I missed a winning lottery ticket.

I’ve been thinking about my long term plans lately. Down the road, I might want to end up in the startup game, stay secure in the working world, or return to academics. An acquaintance of mine recently got into YCombinator, raised money, and appears to be doing great — I admit to feeling envy — so I’m going to indulge in a story: Imagine that I sold Suhail on my passion for the front end.

Back to that conversation we had: he’s asking if I’m more passionate about infrastructure, and I told him that I don’t know the front end, but I’d be willing to learn. Instead of that, let’s pretend that I mustered very fine words and drove home to him that come hell or high water, I’d write the best damn front-end code anyone had ever seen. Clean, efficient, beautiful, and fast. I would make it my life, because I had a (just-ignited) passion for it. The next element of the real story is the handshake and the “too bad” notice — instead now it’s a high five, and a confirmation that they think I can kick ass along with them.

Fast forward to now, imaginary timeline: I’ve learned a ton, helped them with their front end, taken some charge — maybe made a few mistakes, but didn’t cause severe data loss — and I’m living the California startup life with a small bit of equity in a fantastic, growing company. As they hire people, my front-end veteranship naturally brings me to lead the front end team, and 5-10 years down the road they have a public offering and I end up a millionaire. My dreams of financial independence and starting my own startup then come true! All because I displayed sufficient passion that day.

This has all the earmarks of classic stories. Shirking the big company to work for a little guy. Doing something impossible “because no one told me I couldn’t”. Riding on passion alone and “doing what I love every day of my life”. The great tech-magnate tropes.

Except it’s hogwash.

Skills

While the tropes I just mentioned have value (especially “don’t tell yourself what you can’t do; the world will stop you if you actually can’t”), to think that saying something different in that one conversation is similar to ‘missing out on the lottery’ is not just naive, but downright stupid. Here’s why:

I am a junior developer.

There are some people out there who finish college as fantastic programmers. They know design and code and code-design and they whip out complex, correct code like lightning. That’s who Mixpanel needed, and I am just a mediocre programmer who is learning his craft.

I could not have fired on all cylinders and magically made up for missing skill with passion. Suhail was looking for passion because it’s probably a good signal for skill and work-ethic. If I had acted differently in that situation and delivered on passion, it would not have changed my lack of skill. I would have ended up failing their team by coming into the situation learning instead of knowing.

The bottom line is that learning and developing your skills is not something to be ashamed of, and it’s also not something that can be skipped. Instead of pretending to be awesome already, I now work with talented people who know way more than I do and I’m learning from them while contributing. That’s where I should be. (though, it is perhaps the sort of experience I should have had during my internships; I’ll write about that some time.)

This is not a Lottery

The second major takeaway from my imaginary story is that it wrongly trivializes what the team at a company like Mixpanel does. It is built on the false assumption that a great company is a thing to ride, instead of something to carry.

People who work at small companies have to work much harder than people at large companies. It is not an easy life, it doesn’t often lead to riches, and it’s certainly not a magic ticket to success. Let’s imagine that I not only had the passion, but also the skill to be worthy of a first-10 hire when I applied: Any success I might have had would be the product of great coworkers, extremely hard work, long hours, luck, and intelligence over a great period of time.

Once again, my best to the team at Mixpanel. Keep it up.

Day 3: Writer’s block

It could just have been the effect of having Stargate on in the background, but for twenty minutes I sat here and couldn’t think of a topic. It’s day 3 of 21 in my attempt to establish blogging as a habit, and I hope that I’m not already out of ideas. I actually tend to have a lot of ideas about halfway through making a blog post (on days 1 and 2 I certainly did, at least), and I also come up with things throughout the day — perhaps I should note them down. If we can’t have one real topic, then let’s touch on a few smaller ones!

Decimal Time

Simple concept: 10 hour days with 10 ‘minutes’ each hour, and 10 ‘seconds’ within that, and so on. I think that using the same names for different units gets especially confusing though, so let’s ditch them and go with SI prefixes:

units for decimal time; zero point eight six four seconds equals one nan, of which there are one hundred thousand in a day.

What I find to be striking about this is that the units seem usable in real life. A nan is functionally equivalent to a second, and it’s faster and easier to say. A mic (I’d say “mike”, but you can argue about pronunciation if you like — it’s from “micro”) is the least useful, but it’d be more functional to say “just a mic” than “just a sec” or “just a moment”, because we often need 10-20 seconds when we say that. A mil is extremely similar to a minute, and a cent at about 15 minutes is a very common unit of time we work in already.

Okay, so what’s the big deal? Why bother, right? I’d love to have some solid defense against that, but I’ve got nothing. Especially when it turns out that a great number of people have attempted to accomplish this sort of reform before and it has rarely found success. Near the turn of the century, a company called Swatch marketed and sold watches which had 1000 “.beats” throughout the day, which you would use to denote time, @264 for example.

Before that, the France made a number of attempts (or perhaps, one very long attempt) at introducing decimal time, but it regularly fell out of use. Their system was much as I’ve described here. Just look at this fun clock picture I pulled off of the wikipedia page about it:

The Chinese were at it even before that, and seem to have operated with decimal time in full swing for a very, very long time, alongside a similar system to the one which we use. So this idea is hardly original, and it’s also unlikely to suddenly take the world by storm.

Why think about it at all, then? Just out of curiosity. First, I’m interested in what it would be like to have a different standard of time: the second being slightly faster, but the minute and the hour longer. How would that affect my mind’s perception of the world Beyond that though, I’d like to try out living in a different time than everyone else. It may be the closest a boy can get to being a time traveller. I’ve also put some thought into living on unix time, just have that monotonic timestamp on a watch and try to use it to live by. It could make for a really interesting experience.

A brief related tangent

Something I have done in the past is deliberately, regularly choose to do foolish or unusual things. It’s borne out of a desire to have new and fresh ideas. My rationale is that if most people think similarly about things, then two people who have similar experiences might have similar ideas. To have a “new” idea, you have to be “first” to it, which means that you need to spend more time thinking about a problem than anyone else who has had a similar set of experiences to you.

Really good ideas then should tend to come from people who have thought about problems a great deal, or who have had unique experiences. Since you can’t magically think about hard problems for a long time, a hack would be to raise the uniqueness of one’s experiences. A simple plan to achieve that is to add rules into your daily life which cause you to go about things a little bit differently, and then maybe you’ll see what others cannot.

That’s one reason it would be cool to live on monotonic time counting forward in seconds from epoch. Or to have one hundred thousand nans each day, instead of 24 hours.

Writing better code

As I have more code to write, I find I’m getting smarter about a lot of things and seeing a lot of clever ways to use (particularly python) language features that I might not have thought of in the past. Today I learned about python dict-expressions when trying to filter a given set of columns out of an array of dictionaries. They’re new to 2.7, but have been being discussed since before 2.3 — they’re just like list expressions, except you use {} instead of []. I’m writing in a 2.6 environment, so they were unavailable, but a workaround is to pass a list expression to the dict() constructor, like so:

dict([(i, 2*i) for i in range(10)])

I was curious about what was ultimately best performance-wise, because that hack job with the dict() constructor is tough to read. A coworker suggested using the profile module, callable with

python -m profile my_file.py

and it is excellent! I had to write my own repetition into the test to get useful results(unlike with the timeit module), but it dumps total, per_call and cumulative time spent in each function, as well as a count of function calls, without any additional instrumentation. It was greatly useful — and interestingly, vanilla code without any list or dict expressions was faster, but not by a huge amount. In 1,000,000 tests, a double-nested for loop to iterate over the array and save individual columns took 8.250 s of total time, while the dict-expression (on python 2.7) took ~10 seconds, and the list-expression in the dict-constructor took ~11 seconds. I couldn’t find any way to simplify or speed up the expressions, so I wonder if that points to some cases where expressions are just slower than vanilla code.

Rain on the trees

I’ll finish up with a cool phenomenon I saw today as rain started to fall on the trees outside my window at work. There was no appreciable wind when the droplets started to fall, and the trees outside are very young, so that you could see each leaf bounce as it got hit by the rain. Letting my eyes unfocus a little to watch the pattern of leaf bounces was particularly rewarding as the rain became heavier; it made a magnificent optical effect. Keep an eye out!

That which perceives itself

I’ve been putting some spare cycles into thinking about humanity as a superorganism lately. At times, it’s hard to not think about. I am hardly well read on this subject, let alone authoritative, so please take the “thinking aloud” that follows with the proverbial grain of salt.

What the hell is a superorganism

In simple analogy form: you are to your cells as humanity(a superorganism) is to you, or as a huge colony of ants is to each individual ant.

Ground-back

Long ago, somewhere in the universe, multicellular life arose. It has some inherent advantages over single celled life, namely the ability of cells to specialize and perform unique tasks. If you’ve been to an introductory economics class, you will have heard about how specialization is doubleplusgood productivity-wise, so these little multicellular buggers often found themselves among the fittest. Hence, they survived.

Many of the parts of you that make up “you” are specialized cells, which perform very specific tasks. So much so that when you cut these pieces out they don’t really make sense. You don’t have specific control over individual cells in your body — you can’t tell cell 23 from the left of your thumbnail, 8 rows deep, to “heal up now” or to “go fetch a drink”, but clearly an individual, comprised of trillions of cells, manages to perform on a macro scale.

Human Groups

Now consider groups of people. Imagine taking a biologist’s fine-tooth comb and organizing and categorizing them: religious groups, national governments, municipal governments, big businesses, little businesses, clubs, volunteer organizations, guilds, militaries, educational institutions, health institutions, transit commissions, unions — I could probably sit here and keep naming organization types indefinitely.

Then you could classify them by size, age, purpose, shape (leaders, branches, etc). And then you could likely figure out a timeline of them – for example, tribal organizations (now endangered) evolved in some places into local municipal governments, which were precursors to national governments. There’s a complex web of interconnection and some organizations exist strictly to feed off of others, some organizations compete for the same resources, and some organizations even seem to eat other organizations.

The obvious point is that an organization is directly comparable to a regular biological organism. They typically have centralised command groups, communications/action channels, and often what appears to be a collective will. It’s pretty damned cool.

Think about it

This is where it gets interesting. When considering this, two natural directions arise: first that humanity as a whole likely counts as an organism unto its self, and by thinking about it as such, you may be helping it to take the first steps toward becoming a truly self-aware being. The second is that you, a self-aware being, have just provided enough evidence (for non-biologists) to sit back and freak out over the notion that your actions are not yours, but are merely the collective will of your trillions of constituent cells.

The problem of “you”ness aside (we’ll leave that for buddhists to ponder at the moment), I’d like to turn to some questions that arise out of this topic.

Identification

What would a self-aware human organism look like? I think that the entire planet as a being only became a possibility very recently (in the past few decades), when communication speeds and quality became so great. Each individual bit of humanity has a significantly higher capacity for awareness of the state of the whole with access to the internet.

What else would there be, though? Could we, as the constituents of this organism, even recognize it fully? Perhaps there are ingredients needed beyond communication and specialized internal organs; what are they? That’s one I’ve been thinking about a lot: what remains to be made, done, or thought that will help the whole of humanity to realize itself?

Esotera

The last thing that I want to bring up is what our communication is in this model. When I write this and store it somewhere, is that “part of the memories” of this larger being? Are the memes which rise above the background noise this creature’s ideas? Imagine telepathy between two superorganisms — or imagine if that’s what’s going on in our own heads! Billions of voices crying for attention and building off of each other, and the rare virally successful notion in the populace of your mind becomes a joke you tell, or your plans for lunch.

I’m especially curious going forward, as we store our thoughts electronically instead of simply speaking them, we’re making them long term accessible to vast amounts of the group — maybe that sort of internal access is part of achieving awareness.

Conclusion

This was pretty rambly, and frightfully shallow, but it got the collection of questions I’ve been juggling straightened a bit. It helps to dump these things so that later, I can come back and build upon it. A reasonable bit of this thought (this time around) was inspired by a great little story about a man who meets god on a train. It’s quite entertaining — I’m not sure how people with strong religious convictions would regard it, but it asks (and poses sensible answer possibilities to) a lot of great questions.

To conclude, I suggest taking a moment to attempt to regard the whole of humanity. The vast billions of people across the world, eating and waking and dying and laughing and sharing at every given moment. The collection of all of us, together, as a thing that wants and survives — how long will it live? If we don’t know why we exist as individuals, imagine the difficulty in answering why it exists! And that all-time-favourite, is it alone in the universe? It’s great food for daydreamy thought.

Three Weeks: An Experiment

The Gist

I am going to write a blog post every day for three weeks, and they can’t completely suck.

Some background: I am the target market for self help books. I constantly wish I were doing more to improve my self and my life, and I frequently dream up big schemes, then (maybe) execute on them for a day or two. Something pulls me out of the pattern and it’s over. The dream is forgotten, and I move on.

I’ve tried a number of approaches:

  • Just do everything
  • Do whatever single thing interests me that day
  • Commit to big specific projects I think I want to do
  • Start with small things and slowly ratchet them up
  • Try to get people to care if I fail
  • Change my sleep schedule for some reason

Regular pitfalls include:

  • Missing a single thing leads to a feeling of failure, and I give up
  • Failing to have a specific interest on a given day
  • Overcommitting my time, or getting mired in setup
  • Deciding which things to start with is hard
  • Other people are rarely motivated to see my plans through
  • There’s always a reason to stay up late or to sleep in

The Next Grandiose Scheme

I would bet that you’ve heard about 21 days being the time required to form a habit, right? Go to google and type in “21 days”, it’s probably in the first two predictive results. My plan is simple enough that I’ve ignored it for years. It goes like this:

  1. Focus on a single thing for three full weeks.
  2. Repeat.

My plans on the order of “do a billion things” have never been a truly successful, so it makes sense to give things a try one-at-a-time.

Logic

Since these are relatively small packets of time, I’m able to choose topics I might otherwise fear are wasteful. I should also be able to set realistic, objective goals for where I’d like to arrive at after three weeks of focused effort. I can also freely fail at focusing and just try again — one of the intended results of performing this experiment multiple times is that my ability to drill down and focus on something new should improve. Right now I tend to get watery-eyed and feel like a nap after an hour of focus.

Documentation of the three-week effort brings some other things to the table. There’s a well-known method (I’ll call it the Seinfeld method) where a success-to-be plots a big red X on a calendar every day they’ve performed the task they want to improve at. I don’t have a big calendar in my house (though I may get one), but I do have a blog. It’s like putting my big red X marks on the lawn, and telling all of my neighbours why. But I’d hate to get half-way into a three-week sprint and fail to blog about it. Thus, my first sprint should force me to be blogging every day. In a way, I’m combining some of the earlier strategies:

  • This is a small start.
  • I’m telling others.
  • I’m working on something that interests me.

As time goes on, my writing should improve, and you will have the chance of learning something, since I’ll often report on my activities by explaining them.

Off on a tangent: a hack I’ve learned is to trick myself into starting a large project by convincing myself to do one very easy but related task, then riding its momentum. An example is doing the dishes: rather than set out to “do all of the dishes”, I just decide to rinse a single dish that is nearly clean. Once the water is running and I’m rinsing the dish, I may as well wipe it. Now I have a wet cloth and running water, and I’ll reflexively grab another easy looking dish. As the pile grows, momentum builds.

Once more for effect

So this is my first easy dish: just write a blog post today. That’s all I have to be aware of each day, and on Monday, May 28th, I’ll find another easy dish to start.