Mad Libs was driving me mad.
In order to learn JavaScript earlier this quarter, I set out to build a web application that would mimic a game of Mad Libs and immediately got stuck. The idea was that the game would prompt you to enter a set of random words according to specific parts of speech, and then return to you a story whose blanks had been filled in with those words. Cue a hilarious mix match of sentences.
In theory, building it would be simple: have an input form in which the user entered various words. With a button click, my code would hide the form, and show the story template with its blanks populated with the input values.
But none of it was working. I needed my code to rewrite the HTML with the resulting story, but It. Just. Wouldn’t. Do it.
Unfortunately, you can’t Google “my Mad Libs project isn’t working,” or even, “rewrite HTML with resulting story like in Mad Libs.”
Often, especially for an inexperienced coder like me, the trouble with tackling projects with an infinite number of methods (as with JavaScript) is that you don’t necessarily know what the language can or can’t do. So you just have to cross your fingers and hope that Google will fetch the answer to the annoyingly contextual problem you have before you can even articulate what specific action you want the code to carry out.
For my MadLibs project, no permutation or combination of the words “input values into text,” “populate template,” “rewrite HTML” was giving me the answer I wanted, so I took to Twitter:
I’m seriously lacking in the department of how to Google code problems using the right verbiage
— Suyeon (Summer) Son (@suyeon_son) January 26, 2014Half an hour later, Timothy Kempf, a developer in California, took kindly to my tweet of desperation and asked what kind of problems I was having. After going back and forth on Twitter, he offered to look over a Gist (Warning: Code may make your eyes bleed) of my code, and left comments for how I could fix it. I had my Eureka moment then. I was telling the JavaScript to run as soon as the document loaded, not necessarily within the workflow of my submit button, which rendered it unusable. My immediate problem was solved, but I knew I couldn’t always rely on a real, experienced developer to look over my shoddy code every time it didn't work. So instead, I took a step back and asked myself: How do the pros do it? I asked Jeremy Bowers, a news applications developer at NPR, who said he follows a specific pattern when Googling to achieve specific outcomes:
e.g. “JavaScript remove key from object”
What a deceivingly simple pattern. Like code, which I’ve learned is better simple than complex, Google searches should be simple, but broad enough to bring you the anticipated results. Sadly, my problem was that I didn’t even know how to get to the level of correct specificity.
I next turned to Nick Bennett, a Chicago-based developer, who suggested that I “search to find better search terms.” I myself had been doing this, but failed to recognize the pattern in my habits:
@suyeon_son I go from the general to the specific, and find words in imperfect results I can use to refine/pivot my search. verbose helps.
— Nick Bennett (@yoyoohrho) March 5, 2014Mine the diamonds in the rough, Bennett said. “There’s nothing wrong with going to page 10+ of search results.”
Alternatively (and perhaps additionally), Kempf suggested you check the console. (For new coders, that’s the box that pops up when you right click + “Inspect Element” in Google Chrome.)
“Odds are, if what you’re doing isn’t working, it’s thrown an error somewhere,” he said. “If you’re having trouble finding out where something is mysteriously dying, you might want to start logging things until you can track down the issue.”
Lucky for us, Google has a tutorial on how to use the console for debugging JavaScript, which, I’m sure, you can apply to other languages.
The great thing about the console is that it shoots you an error message that you can also Google.
When all else fails, learn the vocabulary, Kempf said. That might mean an extra 20 minutes on a sidetrack perusing the documentation and perhaps shaving a yak. But ideally, it’ll help you recall other things you’ve heard or read and eventually help refine your searches earlier.
“If you see an error, don’t just fix it,” he said. “While you might be able to solve a problem by copying and pasting from Stack Overflow, the best way to use it is to understand why the problem happened, and how the solution works.”
Of course, if that Gist was any hint, my code had a couple dozen more problems to address. For longer than I’d like to admit, I ran line by line, figuring out each Google query and error message as I went. I rephrased my questions as I picked up new lingo, following Bennett’s advice of using my search results to come up with better search terms. When an error message popped up, I did my best to understand why my code hated me, and how I could fix our tumultuous relationship.
I eventually did finish my Mad Libs project, which helps you come up with a ridiculous excuse for not going into work. It may come in handy, especially the next time I spend too long trying to figure out how to Google when I don’t know what to Google.
About the author
