Having successfully submitted my OPW application, and in the process submitting my first open-source contribution, I have lots of thoughts and feelings.

Part 1: Setting up the environment

Setting up your environment is awful. You think, “how long can it take to set up a virtual machine and install this software?” The answer? Longer than you could ever imagine. Especially if your project is on a platform you’re not familiar with, ask for advice early and often—because inevitably, something will go wrong and you’ll need to ask someone wiser for help anyway, and you might as well not a bunch of junk to undo by the time you do. (Like when I tried to install VirtualBox Guest Additions and it destroyed by VM’s video driver, and in fact all video drivers on any VMs I later installed. I had to wipe VirtualBox and start over. No fun.)

I spent a ton of my time at Hacker School learning how to ask questions (or, to put a finer point on it, learning how to not know things and admit to others that I don’t know things). The main reason that HS was so hard at first was that I wasn’t good at asking questions, at admitting when I didn’t know things, at letting myself (I feared) appear “stupid” in front of others. I was still better than some folks at pushing through this, but I wasn’t as good as I would have liked. (This is all tied into impostor syndrome, of course.)

I got vastly better at this skill as I spent more time at Hacker School. I grew more comfortable in the environment, I gained trust in the folks around me and in my own abilities, and I came to believe that my asking questions, even ones about really basic (quote-unquote-“basic”) things, was a display of intelligence rather than a display of ignorance.

What I didn’t realize about my shiny new skill of “Admitting When I Don’t Know Something and Asking Questions” was how context-dependent it is. At Hacker School, in person or on Zulip, I feel totally comfortable asking questions about “simple” things, and admitting that I’m totally in over my head with, say, troubleshooting my Virtual Machine installation and would someone please help me, and what is actually the difference between GET and POST because I never really learned it… that sort of thing. But as I prepare my application for the coming round of OPW and dive head-first into IRC chats about programs and programming styles I’ve never used before, that all seem to require strange dependencies or have to be run on X virtual machine with Y stuff built on it, I recognize a feeling from my early days of Hacker School.

Doing one thing at a time is very difficult.

Here I am, first Monday without returning to Hacker School, sitting down to say “Okay world, I spent the last three months writing code and it was awesome but I should know something about theory, algorithms, etc.; time to do some studying.” I intended to sit down with Interactive Python and blaze through a section or two before turning away to work on my other projects, job applications, etc.

INSTEAD, I was filled with a sudden anxiety—what if Interactive Python isn’t the right course for me? What if it’s an okay course but there are better ones out there? What if by doing Interactive Python I’m missing the perfect algos course for me and this perfect course and I will be like ships passing in the night, never knowing what we might have had together, and all because I chose to work on Interactive Python.

Today on “Bugs that everyone already knew about but Maia found out about for the first time so will write up anyway”, we’re going to talk about the perils and pitfalls of using mutable objects as default arguments for functions in Python. (This episode brought to you by Maia’s contradance database and the letter Y.)

No, nothing went wrong in my code that caused me to learn this lesson, but multiple code reviewers raised red flags about this line in my code: def resolve_query_dict(d, moves_list=Move.objects.all()). Move.objects.all(), by the way, is a fancy Django function that returns a list of all of the Move objects in your database, and since I would likely never be running this code over an extended period of time while things were added to the database, accidentally freezing the value of “all of the moves in my database” wouldn’t have really been an issue, but the dangers of writing code like the above are still whacky and interesting. Basically, odd things happen when you use mutable objects or called functions as default variables in your functions.

Funnily enough, when you’re teaching yourself how to do stuff pretty much from scratch, sans tutorials or guidance, you miss a few crucial points. Weird, right? Here (mostly for my own records, but you can read it if you want!) are the things I learned this afternoon from some code review of my Javascript/JQuery/Datatables code for my contra database:

JS != JQuery!!! They’re different things! They each have different sets of methods, and you need to keep track of whether any given thing you’re dealing with in web scripting is a JQuery or DOM (and therefore JS) object.

Alas, it seems that my dreams of writing a chorale harmonizer in the style of J.S. Bach have to be put to bed until another day. Susan and I have been taking various stabs at this, trying out a few ineffective Python midi programs (one of these, incidentally, had ZERO documentation and was THE MOST FRUSTRATING THING EVER) before settling on mingus, a midi/music theory Python library. Unfortunately, it seems like no one’s addressed any bug reports since 2011, so when we realized that midi read-in was totally borked, we were a little stymied. Specifically, if we gave it this file as input:

It returned this mess here:

(Apparently some people at Hacker School think I’m an Iron Blogger, despite me being nothing of the sort. There’s no money riding on whether or not I make consistent blog posts—but I figure I should do what I can to sustain this favorable impression of me!)

Since my HS halfway check-in, I’ve resolved to ask more questions and not let myself get stuck banging my head against problems that could be solved in a hot second by any of the three people sitting next to me. I think that I’ve done a pretty good job with this resolution; I ask for help way more frequently, and as a result, I think I get more done. However, I feel the need to remind myself that there is such a thing as asking for too much help.

Take this example: I was sitting down with Tristan, a fellow HSer, attempting to set up virtualenv and get all of my permissions and installs un-borked. I was totally in over my head, having never used virtualenv before, and he was helping me sort it out. There was some funky stuff that needed fixing having to do with my $PATH being invalid because one of the folder names contained a space. We dealt with that issue, and now most of the stuff worked, but I still couldn’t manage to run bpython from inside my virtualenv. I showed Tristan the error message my computer was spewing, and asked him, “What’s going on?”

His response: “What do you think is going on?”

Me: “Well, it won’t run bpython!”

Him: “Come on, you can do better than that.”

Here are some gleanings from Amy’s code review of my phonebook applet, and some self-study. Mostly for my own records and so I actually absorb all of this by writing out, but if anyone has comments, additions, disagreements with anything I’ve written here, fire away!

• misc. layout stuff, like putting import statements in alphabetical order
• avoid global vars when possible. I already knew this, but it’s good to remember. For example, if you’ve assuming your program will be run on the command line, you can put global vars in the main() function.
• functions that only incidentally return stuff are bad news. I had a function called phonebook_exists that checked to see if the phonebook you were trying to look up existed; if it didn’t exist, the func. would throw an error, and if it did, it would return the data of the phonebook. Which in retrospect was super weird because nothing the function name indicated that it was what you should use to get the contents of a saved phonebook. A much more sensible way to do this is to have a function called read_phonebook which attempts to return the contents of the saved phonebook, but if it fails (which you figure out with a try/except), then it throws an error. (Incidentally, I had a similar confusion with when things should and shouldn’t be returned in another project I’m working on, my bootleg homemade git. I had a function called save_at_hash that would hash a file, save it at its hash, and then return the hash. Why did this function return the hash? I assumed it would be useful. Couldn’t really tell you why. I ended up refactoring it into two functions, make_hash—which took a file and returned a hash—and save_at_hash—which took a file and a hash and saved a copy of the file at that hash.)

I was messing around with my website yesterday, and trying to make two sub-websites for my ‘Music’ and ‘Programming’ hats in a single Octopress install, and I really was going to be on time to my dinner plans except once my website experiment was borked and I tried to restore my previous site… well, long story short, it was the borked-est, and I spent an hour then and an hour today hunting around with Allison trying to fix the problem. Turns out that in trying to roll back my changes, I’d introduced some discrepancy between my master and gh-pages branches, and I could get around all of this on github with force pushes (-f), but not so easily with actually deploying my site (rake deploy). In the end, I had to go into my Rakefile and add a plus sign somewhere that tells Octopress not to worry whether it’s doing fast-forward commits¹ and just commit anyway.

Here are the fruits of a mini-seminar on git from the inimitable Mary—a sketchy portrait of the inner workings of git.

Git: The Bestest Version Control System with the Worstest UI

All of your Git-age lives in the .git folder

When you run git init, all it does is create a .git folder. That’s it! Your machine knows what folders are and aren’t git repos by the presence or absence of a .git directory. .git is a hidden folder, so to see it, type ls -a. Whenever you add or commit things to your git repo, they’ll get stored in here.