Confessions of a Baby Coder: Coding Terrifies Me

In January 2014, my husband, Kevin, and I started a new together project: Harvard’s MOOC CS50. This wildly popular, college-freshman-level course is supposed to be a beginner’s guide to computer science principles and coding using the programming language C. Generally, it is a well-planned program, with lecture videos, tutorials, walk-throughs, etc. It even has its own Roku channel, where you can watch the lectures from the comfort of your couch when you get tired of staring at your computer screen.

As a college graduate interested in learning to code, I thought, “Surely I can handle a freshman-level course!”

Spoiler alert: I couldn’t.

The first week or two were fine, but it bothered me that the lectures were major stage productions. The instructor would strut around the stage like an off-Broadway actor, filmed at several angles by multiple cameras that made sure to show off not only the decadent theater hall that, had I not known better, could have been the site of Abraham Lincoln’s infamous murder but also the hundreds of eager students who took notes furiously and laughed at the appropriate times — just like a studio audience. These issues — among a few others that, were I to list them, would make me sound like an even worse person for judging a free class from an Ivy-league university — clouded, rather than enhanced, my learning experience.

How is this camera angle enhancing my understanding? More importantly, how do those kids in the third level ask questions?

The other thing that detracted from my learning experience was the fact that CS50 uses C as its base programming language.

In programming, languages are sort of separated into two families: low-level and high-level languages. Low-level languages provide little or no abstraction between the language and the computer’s instruction set architecture (i.e., machine code, assembly). The language’s commands map closely to the machine’s language. By contrast, high-level languages are very abstract compared to the machine’s language. Generally, high-level languages (e.g., Python, Visual Basic, PHP, Ruby) are easier to use and tend to automate or mask more important functions of computing, like memory management, ameliorating the development process.

In the 1960s, C was considered a high-level language. Now, as programming languages continue to be more and more of an abstraction of machine code, C is arguably a low-level language, or at least a high-level language with more access to low-level programming functions than most high-level languages. Perhaps it is safest to say it lies somewhere in between — a medium-level language.

Arguably, because C is lower on the scale, it is more difficult to learn — at least, I thought it was. In quick succession, I was learning memory management as well as programming logic as well as C syntax. Some people argue that C is one of the better languages in which to learn programming because of these things. For me, however, it was a lot to take in, especially since I had only ever dabbled in simple HTML commands to improve the look of my LiveJournal.

So I did something really uncharacteristic for me: I gave up.

Admitting I couldn’t do CS50 was really hard for me. I’ve never had to quit something that was intellectually challenging. From calculus to physics, I’ve always done well (albeit not without some struggle) in my math and science classes. Granted, I’d never taken an online class AND taken a class while working full-time. While these seemed like good reasons to lose interest in CS50, the truth was that I just thought I couldn’t hack it (no pun intended).

And thus began my multi-year dread of programming. For me, attempting to learn programming again represented another opportunity to fail. I had tried it once, it didn’t work out, and that was it. I was just going to have to find something else computer-related to put my mind to.

In August 2015, I started working toward my master’s degree in Information Systems and Operations Management at the University of Florida. For this degree, students choose one of three tracks to follow: IT (i.e., programming), supply chain, or business intelligence. For the sake of dodging as many programming classes as I could, I chose supply chain, even though it wouldn’t matter what I chose until my third and final year.

While I put all of my efforts into avoiding programming, Kevin put all of his into learning programming. It seemed like, overnight, he was making little programs: sitting in the dark of our home office, blasting avant-garde techno from his Gemini headphones, spending many hours debating the merits of a for-loop versus a while-loop, and yelling at anyone who dared interrupt his thoughts. I admired him; he stuck with something I couldn’t.

During this time, Kevin found a programming aptitude test online and decided to give it to me. It goes something like this:

a = 10
b = 20
a = b
b = 5
What is the value of a?

Sadly, I failed. (Looking back, I don’t know how I failed, but I failed.) I threw myself upon my bed dramatically, feigning tears but taking this as a sign that I was, in fact, not destined for programming glory. Kevin gently explained where I went wrong and that, since I understood his explanation, I could still be a programmer. Apparently, some people never understand this assignment problem, even after hearing the explanation.

With each passing month, Kevin encouraged me to learn programming. But between working full-time and my hectic school schedule, I didn’t have the time. And while programming continued to frighten me, I had no problem choosing and then crushing the hardest business electives in my program: two semesters each of Accounting and Finance.

It wasn’t until January 2017 that the tides started to turn in my relationship with programming. First, Kevin, after studying programming for only a year and a half, had earned a great job as a software engineer. I was very motivated by the fact that, if I worked equally as hard, this could be my future too. Plus — let’s be honest — employers are always looking to diversify their rather male programming workforce.

Second, I knew my own programming classes were approaching (here’s lookin’ at you, Fall 2017), and I didn’t want to go in on Day 1 not having written anything more than a print statement.

And, after discussing my programming blockage with my close friend, James, he sent me the following message:

Hi! I just wanted to encourage you to check out the programming side of things. I’m confident you’d be good at it.

When you hear your parents and husband tell you you’ll be good at something, it’s hard to believe them because they love you and think you’re good at everything. When you hear friends encourage you, knowing they have no ulterior motive to do so, it’s more eye-opening and believable. Thus, James’ words inspired me to give programming another — and much better — try.

Through edx.org, I enrolled in another free programming MOOC: Georgia Tech’s Introduction to Computing Using Python. Using a higher-level language than C, this course is taught at a slower pace, with more modest, digestible video lectures and shorter exercises that helped reinforce the material. I found Python to be very accessible and, compared to C, a much better start to learning the basics of coding.

Feeling a renewed sense of interest in programming, I emailed my advisor at UF and informed her that I was changing my focus from the supply-chain track to the IT track. I figured if I’m going to do this programming thing, I might as well challenge myself to the fullest. (#YOLO)

Around March, I received an email from Kevin entitled “Stop being a code wuss” with a link to HackerRank’s 30 Days of Code. Taught in and geared toward Java, I was nervous about learning two languages at once, but I discovered that Java is relatively straightforward too, and I’ve really enjoyed 30DoC.

While I’m still a very baby programmer, I feel more motivated to learn programming than ever before. The challenges in 30DoC have been mixed — some really simple, others quite difficult — but the experience is very rewarding and has taught me so much in such a short time. I plan to spend the summer finishing the Python class, keeping up with this blog, and embarking on other challenges on HackerRank. Coding is still slightly elusive and scary to me, but I at least have a little more confidence that I can handle the challenges that lie ahead.

I’m sure I’m not the only person in the world who has tried programming only to find it intimidating and terrifying. To anyone else who has had a similar experience, I encourage you to try programming courses in several languages, with a few different instructors, before giving up completely. Use free resources like edx, Coursera, Khan Academy, Code Academy, and HackerRank. With the plethora of free resources available, there is bound to be something that speaks to your unique way of learning. You can do it!


30DoC: Day 0 – Hello, World.

No matter which programming language you choose to start your coding education with, and regardless of which MOOC or platform you choose to learn it from, your very first project will most likely be to print “Hello, World.”

At first, you might think your teacher is just being cute, but this is actually a tradition that spans back to the early days of programming. Brian Kernighan, a Canadian computer scientist who worked at Bell Labs, wrote the first known version of the Hello, World code in his 1972 paper, “A Tutorial Introduction to the Language B.”

(What?! There is a language called B?!

Yes, but we don’t speak of it. It is a sad tale that ends in B becoming extinct and superseded by its more popular cousin, C.

You almost made it to popularity, B. RIP in peace.)

Anyway, after subsequently appearing as an example in the book The C Programming Language (which Kernighan co-authored) in 1978, coders informally adopted the phrase as a test message that is still used today to introduce new programmers to a programming language, as a sanity test to make sure a language is installed properly, and as a proof of concept when testing new devices.

Day 0 of HackerRank’s 30 Days of Code continues the tradition.

Why Day 0? You might notice that 30DoC starts at Day 0 and ends at Day 29 — technically, still 30 days but numbered beginning at 0. Though you can complete 30DoC in any a variety of languages, the series is demoed and geared toward Java, and Java is a zero-indexed language. This means that, in any list of items, the first item in that list is assigned 0, the second is 1, the third is 2, etc. Mathematically, we are simply reducing by 1 the number we would normally assign to these spots. Thus, our first task is numbered 0 (1 – 1 = 0), and our final task is numbered 29 (30 – 1 = 29).

Before I go into the code for this task, I want to first explain the setup you will see for all of the 30DoC challenges. If you’ve never seen a requirements page before, it might be confusing. It certainly was for me.

The first few parts — Objective and Task — are fairly straightforward. However, what do the other sections mean?

  • Input Format and Output Format: In words, these explain the input your program will receive from HackerRank, and the output your program should produce based on the input. This is important, because we need to know whether our program needs to accept strings, integers, characters, etc., as input so that we can create the correct variables.
  • Sample Input and Sample Output: In words and numbers, these are examples of the actual input your program will receive from HackerRank and the actual output your program should produce based on the input.
  • Explanation: Many words generally explaining how the program produces the Sample Output.

In other words, HackerRank is telling you what your program should expect to receive and what it should produce. It’s up to you and your program to make sure that the input becomes the proper output.

Since this is the first day of the series, the task is pretty simple, and HackerRank gives you a LOT of help in the form of comments and code. Here is what you start with:

public class Solution {
    public static void main(String[] args) {
        // Create a Scanner object to read input from stdin.
        Scanner scan = new Scanner(System.in);

        // Read a full line of input from stdin and save it to our variable, inputString.
        String inputString = scan.nextLine();

        // Close the scanner object, because we've finished reading
        // all of the input from stdin needed for this challenge.

        // Print a string literal saying "Hello, World." to stdout.
        System.out.println("Hello, World.");

        // TODO: Write a line of code here that prints the contents of inputString to stdout.

If you’re like me, you might be really confused by the idea of the Scanner class. Admittedly, it took me longer than it probably should have to really wrap my head around the scanner. What the heck is it scanning? What does it mean?

You know how websites or programs will prompt you for input sometimes? Programs have to have a way to look for input and then use that input to complete the functions of the program.

That’s exactly what the Scanner class does. In the case of 30DoC, though, we ourselves won’t be the user giving our little program input. Instead, HackerRank will provide input to scan. By telling the Scanner to scan System.in (i.e., “stdin” as HackerRank says), we are directing it to go to a certain location and read the information that is stored there.

Speaking of System.in, what is that? And what is System.out?

These are sources or destinations of data in Java. System.in is a way to pass information from a source into your program. System.out outputs the data you request to the console.

So let’s go through the first line of code, which HackerRank writes for you:

        Scanner scan = new Scanner(System.in);
  • Scanner: Identifies that we want to make something that belongs to the Scanner class. This is similar to how you create a new int or string by first identifying “int” or “String” ahead of the name that you give that int or string.
  • scan: A unique name. This is what we will use to reference the scanner throughout the program. You can name it almost anything you want. Typically, coders name it “scan” or “scr.”
  • = : Assignment. What comes after this sign is what we are assigning to this thing “scan” that we’ve created.
  • new Scanner(): Creates a new object of the Scanner class.
  • System.in: Calls a constructor of the Scanner class that allows you to read from the standard input stream of the program.

With this, we have initialized our scanner, but it isn’t actually scanning anything yet. That’s what the next line of code does:

        String inputString = scan.nextLine();

scan.nextLine() is a method that is part of the new Scanner object we created in the previous line. It’s a little counter-intuitive, because, like me, you might be thinking, “But I want to scan the first line, not the next line!” This is something you just have to accept as true: scan.nextLine() will, in fact, return the first line the first time you call it.

This method will return something — an integer, a character, a string, etc. We are told in the Input Format section that the input will be a string; therefore, in this instance, this method will return a string. That is why we start this line of code with String inputString: We initialize a string variable, name it inputString, and then assign it the value of whatever we retrieve using scan.nextLine().

The next line of code — scan.close() — is a mini lesson is responsible programming. Once you have written all of your code related to scanning, you should always close your scanner. (And I’m definitely guilty of not doing this.) It doesn’t matter as much for 30DoC, but it matters in real development, because leaving the scanner open can lead to resource leak (i.e., memory loss or waste), a pattern in which a program does not release the resource it has acquired and wastes a bunch of memory keeping it running when it doesn’t have to. When you’re working with limited memory in the real world, this can cause you major headaches.

Moving on!

        System.out.println("Hello, World.");

BlondieBytes already covers this, so I won’t spend too much time on it, except to discuss a few methods of printing in Java. When I started, I wondered why System.out.println() was, in fact, called println and not just print. What did the ln mean?

Indeed, Java also has System.out.print()! The difference? println prints its contents and then moves the cursor to the next line. It’s like typing something on a line and then hitting enter on your keyboard. print simply prints its contents and does not move to the next line. Not a big deal, but good to know.

Finally, our big moment is here; it’s time to shine! If you understand everything that has happened thus far, writing your first line of code should be easy peasy; if not, that’s OK!

HackerRank comments-out a TODO for us: Write a line of code here that prints the contents of inputString to stdout.

Let’s think through this. We know we need to print something, and we know the code for that: System.out.println()! (And in this case, you could also use System.out.print() if you wanted to try it out.) But what goes in between the parentheses?

Well, if we want to print the contents of our variable inputString, we simply type the name of our variable in the parentheses, and it will print the values we assigned to that variable. We assigned to inputString the value that the scanner read from the first line of stdin. So, if we write System.out.println(inputString), the program will print the string that HackerRank provides as standard input!

So, with all of the comments removed and just our fresh code in place, here is one possible answer to this problem:

public class Solution {
    public static void main(String[] args) {
        Scanner scan = new Scanner(System.in);
        String inputString = scan.nextLine();     
        System.out.println("Hello, World.");

Woo! We did it! Hopefully, your code passes the test cases. If not, read it very closely to ensure you didn’t mistype any variables, make any spelling errors, or misuse any syntax (i.e., check those periods, brackets, and semicolons!).



Q. Why write about my coding adventures? Isn’t there enough out there already in the Google-verse about coding?

A. Several reasons, and probably.

Last month, I embarked upon HackerRank’s 30 Days of Code series in an attempt to learn the basics of coding before I have to start programming for grades in my graduate program. I’m the type of person who doesn’t want to show up completely unprepared. I’m also really competitive, so I don’t want to be the only kid in class on the first day who hasn’t written a single line of code.

For the first nine days, 30 Days of Code went really well for me. I followed the tutorials closely, not just watching but also coding along with BlondieBytes in my own NetBeans files, mostly so that I could get the practice and have the files as references if I needed them. I stumbled successfully through the challenges. I was beginning to feel like a dev god.

Then came Day 10. It was the first time that I not only had to look up others’ solutions before crafting my own (something that I was not proud of myself for doing) but also did not understand why the solution worked.

Thus, I ran into the brick wall of learning to code online: Plenty of solutions, very few detailed explanations.

See, I don’t want to just look up someone else’s code and pretend it’s mine. That isn’t teaching me anything. What fun is it to hit that submit button when you know that you yourself haven’t actually done anything worth submitting? How is that going to help me in a job interview? In life?

What I really want is a step-by-step tutorial of the logic behind why a coder made a certain decision or wrote a certain line of code. And while this may exist already for specific coding issues (e.g., Stack Exchange), it doesn’t really exist for 30 Days of Code, at least that I have found.

Admittedly, I am more than a novice when it comes to coding. But while other programmers are pros at, well, programming, I outshine most of them in one area: writing. So, as I work through 30 Days of Code (and, in the future, other coding challenges), I plan to blog about not only my code but also my explanations for my thought processes that led to what I wrote. My hope is that others don’t just copy my code but learn something from it. As I’ve already begun to learn, writing the code is hard; training oneself to think about problems like a software engineer is harder.

And while I didn’t solve Day 10 on my own, I learned something that helped me solve Day 11.

(Oh, and {carlyBracket} is an arguably cute play on “curly bracket,” which we hear a lot of in 30 Days of Code.)