“Simple” != “Easy”

(Previous: Projects, Projects, and More Projects: Free Code Camp)


Early in my journey into learning software development, I made the mistake of looking at a few lines of code and thinking “Oh, it’s so short! I’m sure I can figure that out in no time.”

I was wrong.

Good coding, like good writing, is an art form, and some of the simplest and best results (in both) are actually the product of hours of hard work.

There are obvious pop culture examples (anyone want to argue that the three-part movie version of The Hobbit was superior to the previous LOTR movies because it was so much longer? Yeah…).

And there are some obvious programming examples as well, like a few months ago when someone unpublished 11 lines of code and broke the internet. 11 lines.

In fact, a lot of the code we depend on–the functions that sort lists, replace whitespace with “%20”,  calculate math functions, tell us the length of a string (or an array), to name a few–is fairly short.

But these functions are powerful. So powerful that we don’t think much about them, but we depend on them being built into the programs that we use (imagine if you had to write a function to calculate the length of something every time you needed to use it! It would be both boring and unproductive). And so every language has certain pieces of code already built in behind-the-scenes, and part of learning software development is knowing what is and isn’t accessible in the language that you’re using.

Of course, someone has to write and debug all of that code, and that’s a big part of what developers are hired to do. That’s why whiteboard interviews are so important for certain types of jobs–if you’re going to be writing code that other people are going to depend on, you need to figure out how to create it, test it, and debug it from scratch. You can’t depend on what is already out there.

Similarly, in certain situations, or in certain jobs, you might find that the existing code in place for performing a function isn’t working correctly for what you need it to do… so you have to rewrite it, or tweak it, so it does what you need it to do.

I spent a chunk of my morning debugging a quicksort. I followed an algorithm to create it, but it turned out that the algorithm was slightly wrong (albeit pretty high on my google search). So I went through the code line by line to figure out what was failing and why, and fixed it (and found a correct version of the same algorithm along the way).

The current version is about 18 lines, nicely spaced, divided into three functions (one main one that calls the other two). It is easy to follow, with comments above the main lines that explain how it is working, in case I forget later, or want to modify it.

Only 18 lines, but 18 very important lines; one variable out of place and the function will overwrite a list of numbers instead of sorting them, or move them around without producing anything.

A year ago, I wouldn’t have understood the triumph of those 18 lines–I would have looked for something longer, or showier, or less routine.

But today, I’m feeling pretty good about what I accomplished.

(Next: Kal Academy: Seattle Coding Bootcamp Alternative)


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s