So, there are random non-programming reasons why I didn't feel like I made much progress yesterday -- I tried working in a beanbag chair (no good for Sumana), I drank coffee too early in the day (caffeine crash in the afternoon) and I listened to the wrong music (Guster and Neutral Milk Hotel? might as well be The Mountain Goats for all the good that does me) -- but here are the big ones.

• When I got frustrated, I didn't get help as much and as often as I should have. This is DESPITE the fact that I DID get help from Zach, Allison, Stew, and, crucially, Mary. I had short conversations with the first three, and then Mary paired with me for 45 minutes and helped me understand some things about my goal of refactoring a big codebase. Such as "it is a big job" and "you should have a guiding thing you're trying to do as you go, like adding a new feature, or adding tests". Also she helped me see how to write a test with little mocks so that I'm not doing the foolish thing of testing "does the exact same technique (as the function I'm testing) work on the exact same input (as the function I'm testing is using) and get me the same output (ibid.)?"
• When I was trying to play with Beautiful Soup for the first time, I used a test page different from the test page in the documentation/tutorial. Then, when I ran into seemingly inexplicable errors, I didn't think to look at the differences between my input data and the input data in the documentation examples. I felt especially helpless because my spouse wrote Beautiful Soup and thus it seemed like I ought to wait till I got home and ask him for help. But that broke my momentum; I should have swallowed my embarrassment and pride, and asked someone at HS for help.
• To feel less like a broken and incompetent programmer, I did some simple Codecademy exercises, but the interface feels slow and -- since I already know the concepts in the exercises I was doing -- I knew I wasn't really learning anything. I should have skipped them, or just skipped to something hard.
• I paired with Julia to understand some gzip stuff to hopefully help her debug a problem, which means I learned some things about Huffman coding and the mind-breaking way that LZ77 encoding and decoding works. But it took what felt like a super long time because I never learned some basic CS things and I am not facile with binary arithmetic, and I felt like a drag, and felt blergh. Maybe I was just in a down mood; maybe I should have just bid Julia goodbye and gone for a walk or something. (Sorry for my raincloud, Julia!)
• We heard a talk (in our Monday night talk series) that somewhat went over my head, and which, as I realized about 25 minutes through, was simply going to be hard for someone with my learning style. I an an active enough learner that hearing about concepts like event loops and threads (and the problems concomitant with those approaches to concurrency) isn't enough; I need to play with them and experience them. I am a visual enough learner that, if I haven't tried writing concurrent programs before, I need diagrams or animations or similar visual elements to help me understand what works and doesn't work, rather than just sentences spoken orally. I am a sequential enough learner that if I don't get the first concepts in a presentation, it's going to be hard for me to grok any of the middle. And I am a sensing enough learner that I really need to understand the examples, and I had a hard time reading the syntax of an unfamiliar language (OCaml) to get at what was happening in the examples. (This is interesting data because I thought I was way more on the intuitive side of the sensing-intuitive spectrum, and the verbal side of the visual-verbal spectrum, and the reflective side of the active-reflective spectrum. Failures show us nuance!) So, for those first 25 minutes, I mostly felt unintelligent, and tried to follow, and felt my morale sag. After I realized "oh, this is almost exactly the opposite of my learning style", I felt less bad. So in the future I shall try to have that realization earlier. (Monday night talks are lids-down, so it's bad manners to try to understand the speaker by writing code. Even though I consider myself a crap artist, maybe I should try getting out pen and notebook to draw my own diagrams in cases like this.)
• After I came home, Leonard worked with me on Beautiful Soup play and helped me understand another perspective: writing tests is writing code, and writing tests is hard -- in fact, generally harder than writing the code that the tests test. You have to think on another plane. Oh. I've been blithely walking into intensely difficult non-solved-problem areas of software engineering, viz., refactoring and testing, with a codebase entirely new to me, as a not-very-experienced programmer. No wonder I've been running into difficulty.

Today is a new day! As soon as I hit Publish I will pair with Leonard a little. Yay morning freshness.