Code Year, Lesson 2 Part 1

I have a distinct memory of the first day of French 1 in college. I walked in confident that I would succeed. After all, I had been a successful Spanish student in high school; French was a romance language, ergo it wouldn’t be that different. Right?

Well, I quickly realized that in college language classes, you actually learn the language. My instructor, Alison, opened the first day of class speaking to us – a group that presumably had no prior French knowledge –  primarily in French. It was a clear dive into the deep end. My, how this was different than high school Spanish class!

(Side note: I had pretty strong Spanish education in high school, but we spent quite a bit of class time gathered in a circle singing songs by Juanes and Rebelde. So, you know. Not super rigorous.)

Anyway, this is perhaps a circuitous way of getting into my main point about programming, which is that I feel like with Code Year, I’ve similarly dived into the deep end. Unlike with French, however, I’m fighting not only the battle to learn quickly, but also the battle to overcome my anxieties about technology. I’ll admit that I’m a computer user more inclined to call tech support when something goes wrong than to take the time to trouble shoot myself. I figure that “an expert” must know more than me, right?

The glory of the digital age (And yes, I realize this is hyperbolic. Humor me) is that we CAN have control over our digital lives. I may not be “math-brained,” but I CAN learn to program. I have faith in this. It is just a doggone, difficult task.

Before I get into the nitty-gritty, I have to say that part of what inspired this “can-do” attitude was a short video I watched earlier today from educator Stephen Chew aimed towards helping undergraduate students develop better study habits (i.e. DON’T MULTITASK; NO ONE DOES IT WELL). The video itself is admittedly a little cheesy, but he stated something in his video that struck a chord with me: many students don’t succeed in his classes because they assert they’re “just not good” at something.

This is something I’ve told myself so many times over: “I’m just not good at math.” “I just can’t visualize [insert any image/shape here].”

“I just can’t do it.”

There is some truth to the concern that some students can’t learn as quickly as others can in different subjects. But I’m coming to believe (increasingly) that we really ARE capable of doing anything if we just take the time. It’s doing things that feel uncomfortable to us that is the real push. I don’t think it’s much of a generalization to say that we’re all predisposed to avoiding uncomfortable feelings; that feeling of failure and incompetence is perhaps one of the most uncomfortable for me (this is, unfortunately, a common syndrome of living a life primarily validated by academic achievement).

Phew, with ALL OF THAT SAID:

I’m pretty frustrated by the programming. I can’t give up now because I know how important it is for me to learn. But dang it. It’s really hard for me.

For those who care about the technical stuff:

I completed the lesson Functions in Javascript this week. From what I understand, functions are basically blocks of “reusable code.” It’s a code that you store that gives your program a certain command to repeat over and over again (so that you don’t have to write in the same commands repeatedly).

See, so far, so good. I’m all into this efficiency thing. I like to color coordinate files and write to-do lists, so the idea of something like a function very much speaks to my organizing soul.

As these Code Year lessons tend to go, it started quite well. I must say that I felt incredibly proud of myself when I created my very first function!

"You never forget your first function"

Simple, yes, but still mine all mine! I made the console spit out my name! Winning!

Of course, the lesson grew increasingly complicated. As with learning any foreign language, learning a programming language requires you to integrate what you learned from lessons prior (crazy, right?)

So, within functions you must also store variables. Defining and storing variables allows you to work with the numbers/words/items that will be important for your function (and therefore your program) to – well – function!

So, I didn’t capture an image that spit out the console log text, but basically this activity required me to run the code to see what the function “greet” spit into the console log. As you can see, because the variable “greeting” is was typed into the console log, the variable’s text (“Ahoy”) appeared in the console log.

So far, so good? Yep, so was I.

Here’s where things get tricky:

Inside a function, certain values can get “returned.” To clarify, in all of the examples I’ve shown, the functions are just outputting information without receiving any input. The return tool is necessary to use if a particular value is inputted into a function.

Here’s an example:

The value “x” has been inputted into the function and two different functions are created: one that simple returns the value inputted and another returns the value inputted, squared.

Again, I think we’re still following, right?

Remember those tricky if/while loops I discussed in Lesson 1? They’re baaaaack:

So, here, we’re basically just complicating the function further: this program will determine whether to spit out “The statement is true” or “isn’t true” based on the conditions established within the function.

What was tricky to me about this was figuring out how to define the conditions within the function. How do I use the correct syntax to break down the conditions? What’s the clearest/easiest way to do that?

Obviously, I’m still learning and I’m still working through a lesson on establishing parameters within functions, too. But… here’s where I left off!

I find myself reading and re-reading directions to make sure I understood, but now that I’m synthesizing what I’ve learned, it feels simpler than when I was learning it. I guess this shows I understand what I’m doing? Maybe?

Code Year: Lesson 1

I’ve made it through (most of) Lesson1 of my “Getting Started with Programming” Course on Codeacademy and I’m already running into trouble! Nooo!

Mind you, the first few exercises within the lesson felt like a breeze. Really, I figured I’d be making apps and creating programs in no time! I suppose when you have exercises like “type your name”…

…And “Copy these instructions so that you can create one of those awesome pop-up boxes!”

… you’re bound to feel like a programming champ.

Yet this were just the “feel good” exercises before tackling the real deal.

Before I get into the details, here are some new terms I learned:

string:  a unit of alphabetic characters that need to be identified as one. As a programmer, you need to identify “strings” in your programs in order for words to show up. If you don’t identify “strings,” the program won’t recognize those particular word units as important. You have to treat your program a little bit like your great aunt Ethel; assume that it will remember nothing. However, it’s easy enough to store strings so that the program will remember what you mean when you type in certain words.

variable:  a number that you store for the program to use as information later.

array: an index (typically of numbers) created so that the program can store multiple numbers at once in the same order/pattern each time.

I’m still not sure I completely understand the distinction between a “string” and a “variable” (aren’t they all simply units of different types to be stored?), but the above definitions are a simplification of how I’ve parsed this out in my mind.

In any case, as I moved along through the lessons, I discovered that programming language involves a lot of syntactical precision. After all, a program can only run if the writer is incredibly explicit in his/her directions. Let me try to provide an example:

The exercise wanted me to command the program to parse out two letters from the string “hello” (in this case, the letters in the first and second positions of the string). Alas, do you see what mistake I made the first time around?

That’s right: I put a period at the end of the command while I should have left it open. That one little dot messed up the entire operation! Isn’t that bananas?

Of course, syntactical accuracy is not the only thing I learned to be wary of. Logic is a hugely central to programming, something I had never realized before I began Code Year.

This makes complete sense, of course. How would a program know how to function if it did not account for all possible contingencies?

One concept I especially struggled with was that an “equal” sign does not always mean “equal.”

I mean, what? Equal is not equal? What are you trying to do to me, Javascript? Are you going to tell me next that people aren’t people?

So, as it turns out, one equals sign simply identifies a variable. It does not necessarily mean that the variable at the end of the “equal” sign is going to be the “answer” to the program (especially if it’s a mathematical program). Three equal signs together (===) is used to check if one variable’s value is equal to another variable’s value in the program.

Oof, yeah, I had to read that a few times over, too. My brain is not used to considering all of these different mathematical contingencies!

The primary circumstance in which a programmer may use the “=” and “===” signs is for “if” statements. Here’s an example:

Do you see what’s going on here? Basically, this is a program that will spit out one of the console logs (i.e. “Your name is Sam” or “Your name isn’t Sam”) depending on whether the user of the program answered the prompt (“what’s your name?”) with – well – Sam or not Sam. The “if” statement (with the three equals signs determines) what the response for the user will be if “Sam” is entered or not entered.

See, it really makes perfect sense. It’s just a matter of completely rethinking syntax.

In any case, I felt pretty confident in my understanding of how the “if” and “else” statements work in a program. What’s (still) tripping me up are the “while” statements.

A “while” statement should – in theory – set up a continual loop within the program. However, I seem unable to nail the syntax to create these while statements successfully and I don’t quite know what to do. Any thoughts, cyberspace? Here’s the problem I’m running into:

Perhaps it’s difficult to read the instructions (they are in tiny-ish script), but I’m supposed to create a program that prints the word “hello” twice using the “while” loop. However, I’m not sure where the variable “i” fits into that and how I help the program to understand that I’m not using any numbers here. I’m afraid I’m a bit stuck! Perhaps some future Googling will help me to solve this program.

In any case, I’m really trying not to let myself get frustrated. Even in this first lesson, I found myself reading and re-reading instructions for even the most basic of “activities.”

Perhaps I’m simply not acclimating to thinking from “the back end” like this. Indeed, I fancy myself somewhat creative, yet from what I can gather, successful programs are not merely creative: they are able to envision whole words and define the terms that creates those worlds.

That’s mind-blowing to me.

I suppose for now I’ll have to be content with the mere shrubs and brushes I’m starting to program before I can think about the tall buildings and – goodness knows – the people to populate this digital world.

Sails Up!


My name is Jenae. This is what I look like:

High Quality Laptop Camera FTW

I’m a first-year PhD student in the English Department at UC Davis and I’m going to do something I’ve never done before: I’m going to learn to code in JavaScript.

Perhaps the title of this blog is misleading: I’m not a luddite. In fact, I was born in 1988, which makes me a “digital native,” right?

Indeed, when I buy a new electronic product, I don’t read a users’ manual. I tend to dive into new products, darting between screens, pressing different buttons, and simply seeing what works and what doesn’t. Only on computers do I approach the unknown with such brazen disregard for rules.

Yet computers are governed by rules. Scripts upon scripts dictate what we see on our screens. There’s a whole language that determines why our keystrokes appear the way they do.

For a long time, I’ve been content with ignoring this “man” behind the curtain, the words, letters, and symbols that do the work of my computer before me. As a humanities student, I am often firmly content with delegating technical understanding of the world to skilled engineers. How does that stove turn on? Magic! How do magnets work? It’s a miracle! Why do objects fall to the ground? Um, gravity?

But understanding how a program works has some very tangible relevance for me. If you’re reading this, you know that writing is changing. It’s no surprise that digital communication is the primary means by which we exchange information in the 21st century and, for better or for worse, fellow luddites, that’s the way it’s going to be. I love a dusty, old book as much as the next English student, but goodness knows I’m not going to resist this pressing change in our literacy practices.

I’ve tried this once before. This past summer, I attempted to teach myself Python, partially for the professional value and partially because mentioning my interest in programming scored me a lot of messages on the online dating site, OKCupid (SIDE NOTE: it really is incredible how many men are interested in a woman who knows a technical skill. This, in and of itself, is worthy of some sociologist’s dissertation work).

I perhaps should also mention that I’ve felt hugely hypocritical for remaining absent from the blogosphere. After all, as part of my English degree program, I am pursuing what is known as a “designated emphasis” in Writing, Rhetoric, and Composition Studies (WRaCS) and plan to specifically focus my (eventual) dissertation research on digital writing practices in some way. In what way that will be, I’m not entirely sure.  All I know is that our digital literacy practices have huge implications for our future study of literature and writing and I’m not about to miss out on that.

With that said, this blog will chronicle my process of becoming less of a technological noob and more of a technological neophyte. There will be some musings here about my own relationship with digital literacy, cool links/websites I find related to digital literacy and practices, and perhaps mostly my journey in learning Javascript.

I am currently working through Codeacademy‘s Code Year project to learn Javascript. Each week, Codeacademy will send me a new lesson and I will complete it within the week.  Some weeks I may look like this:

This was captured candidly when I was trying to figure out my webcam...

Other weeks, I may look more like this:


But by making my thoughts public, I will hopefully be held accountable to push on through and avoid looking too much like this:

In the meantime, I’ll be balancing graduate school coursework, but will likely tinker with some web design as well, not only to personalize this page and make it beautiful, but also to become a more apt, savvy, and comfortable tech communicator.

See you in cyberspace!