On meeting strangers

You should be meeting more strangers. Strangers are scary, smelly, often have lopsided feet, and more than anything, have a lot to offer you. Whether you are sitting on a bus, picking up your mail, getting a cup of coffee, or sitting in your house watching TV while secretly watching what you neighbors do, the strangers in your life have a lot to offer you.])

Talk to everyone and anyone.

I mean everyone. You would be very surprised how much the people you casually talk to can offer you exactly what you need. Once you talk to your first stranger, you will be on your way to learning more about the world. Through talking to strangers, you can learn about different careers, life struggles, current events, and occasionally a new cookie recipe. When your standing in line for groceries, getting a cup of your favorite drink, or sitting alone quietly. You can simply start a conversation with “hello, my name is _____” (please don’t actually say ‘underscore-underscore-underscore-underscore". Fill in your name instead). Another effective method is joining conversations that have nothing to do with you. While you feel like this is totally unacceptable and disrespectful (it mostly is), occasionally its a great way to get past all the awkward conversation and get straight to the point (“I love chocolate chip bacon covered whiskey dipped cookies too!”) From there you can take the conversation anywhere.

Break all the ice.

Global warm that shit. Start by being as intrusive as possible, so as to learn about the persons personal life. The sooner you can break the ice, the sooner you can have a new friend. Don’t worry that you don’t know anything about this person. Did you hear a word that sounds vaguely interesting? Does the person have really well hemmed pants? Maybe you want to know whats in the bag they are carrying (“So whats in the bag?”). Take them off guard with a question they wouldn’t expect from a stranger. Find a commonality and make some personal association to its relationship to you. (“Nice novel on ax murdering. I love ax murdering…”).

Make it easy to get in touch.

Get a business card. Have a portfolio website to show off. Make your twitter handle easy to pronounce. Stop using that email address you made in 2001 and make something that doesn’t have the . By talking to strangers and asking them what they do, you will naturally start up a conversation. (Unless you just creep the person out and need to run away out of fear. If you run away, don’t worry. They can’t judge you because they are still trying to figure out what just happened.)

But seriously. Go talk to a stranger. Go make friends with someone on the street. Jump in a taxi with someone, even if you’re not trying to go anywhere. And start making friends.

Why learn?

I have spent the past three years developing websites. I have been hired by clients ranging from startups to fortune 500 corporations. Yet, I don’t have any formal training as a computer scientist or digital designer. I went to school to study in a Liberal Arts program in the humanities. I read books on cultural theory, history, and adopted an obscure love for classical literature (Goethe I’m looking at you).

So why does this all matter? Well, like most people, I wanted to get on the band wagon of utilizing the immense power available today in the form of technology. I saw computers as the beginning, but instantly knew before smart phones that mobile technologies were offering amazing opportunities through widely distributed data networks. I wanted to use this, but I didn’t have any training. I think a lot of people around my age (and those who are not) have this feeling.

I started learning web development, and more recently Javascript. Javascript was my “in” to the growing digital frontier. Making a website was foreign to me, but I found people would pay me to do it, so I invested my time to get good at it. I identified the front-end (User Experience, User facing elements, Design) web development as most interesting to me.

Deciding the front-end

Deciding I would become prolific at front-end technologies (HTML/CSS/Javascript), I found myself struggling with the abstract concepts of Javascript. I also noticed that Javascript could potentially offer the most learning value. As the founder of Javascript says, “Always bet on Javascript”.

I traverse the infinitum of blog posts being written on software engineering to find the rare nuggets of informative learning resources. I find myself attracted by titles to blog posts, but unable to comprehend the complex code blocks. Instead, I browse the (often Jekyll or Octopress) blog posts, only to read the commentary and skip of the code segments.

My greatest obstacle when reading code is that I’m feeling like I understand the code, but fail to absorb the lessons. Overcoming the mammoth that is learning to code by adopting good practices has significantly helped. I can confidently say, I am not good at learning over the internet or even teaching myself how to do “stuff”. Instead, I am good at identifying my faults in remembering and make up for it by creating processes that make me “fail forward”.

I know that I fail at absorbing coding concepts. I also know that I am good at learning from mistakes. I combine the two understandings about myself by forming a practice to force myself to fail at absorbing coding concepts by making guided mistakes. I do this without another teacher guiding me or a tutor.

Note: The term “Failing into the pit of success” was a term developed by a software developer at Microsoft.

I have developed a four step process to help me learn from coding blogs. There seems to be an endless number of programmers who enjoy sharing their software development discoveries in blog posts and articles. I often find these very informative, although not always well written. Sometimes there is (what seems like) a missing part or gap. I find that the core concepts are discussed, but the directions seem to miss explaining how to get “there”.

Although instructions are not present, I find that code examples are numerous. Specifically, code examples without explanation behind their inner-workings or core-concepts. As a result, I started pragmatically reviewing the code myself. I use the code examples that are completely foreign to me, to begin a process of exploration and discovery. I have documented this process with examples for readers.

Step -1: Always be coding

I find the best way to solve a problem is by having a contextual and relevant application. Without the relevance, you won’t be able to remember the problem. You might forget the idea, but you won’t be able to apply what you learned when the same problem appears out of context. I find the problems I understand best are the ones I learn to solve when encountered during actual development. This is one of the reasons side-projects are crucial. Always be coding and you will always be learning.

Step 0: Identify well written articles and dependable educational resources

There are literally hundreds of email newsletters that compile the “best” articles of development in your field. I get no less than 10 a week. Some of languages I feel overly confident about and others that I am only just starting to learn. Regular exposure to newsletters, as well as online coding communities (such as Reddit/r/webdev or HackerNews) will keep you exposed to the well written articles and best educational resources available.

My personal favorite for front-end questions is the Mozilla Development Network (MDN). The MDN has the best documentation on all web related APIs. This means anything you want to learn about HTML5, CSS3, Javascript and web APIs are well documented here. To discover these resources, you can use Google. Simply add the string “MDN” to a search query and you will find the relevant resources

Using Twitter and Github to follow well known developers has been priceless. Whenever I find an article I enjoy, I follow the authors twitter account (This is a great time for me to say “Follow me on Twitter @Lkbcc”). By following developers, you can see what links are being shared and most importantly who they follow. The twitter feeds of developers, open source projects and companies are often the best place for discovery.

Step 1: Place your browser beside a note taking application

Open up a code editor or note taking application and open it side-by-side your browser window. You are going to write down every idea/snippet/word that you don’t understand. This is crucial. Being aware of what you don’t know will allow you to advance. It may be painful to realize you read a paragraph, only to write down nearly every word in your notes, but this is where you can start moving forward.

You picked an article with an interesting but difficult topic and lines-on-lines of coding examples. You are about to learn some thing new. Be confident that you can learn this idea, even if it seems completely out of reach. Most of programming is not about being smart, but pushing through the foreign ideas until it “clicks”. Just as Woody Alan says, “Showing up is half the battle”. Seriously, just read through the stuff you don’t understand, and the exposure to the foreign ideas will be hugely beneficial.

For note taking, I use a program called Notational Velocity. Its a very simple application that makes all my notes easily searchable. I’ve seen people effectively use Evernote, TextEdit, and even Word Processors. I find the most important thing is reducing the friction to start the note taking process. I like Notational Velocity because it natively binds a keyboard shortcut to pull up/hide the editor. This process can actually be assigned to any application through a computer’s System Preferences.

Step 2: Copy down code examples. Write them out again from memory

When you read articles, if you just read the articles, they won’t do sit nicely in your head. Like a poorly written Backbone application, you’ll have a memory leak, until all the time you took to learn will be forgotten. The best way to remember is to physically go through the code and write it down. If I learned anything from Zed Shaw in his Learning Python the Hard Way, it was the value of copying code.

Often, you will get into the flow of copying/writing out code, without being conscious. Other times, you will be conscious of how impossibly terse a code block is and will not understand it. This is okay. At times, I physically write out code blocks with pen and paper, because it forces me to slow down. Regardless of how you do it, the next part is very important.

Write out the previously copied code purely from memory. You can do it write underneath the copied code or in a new page or document. The exercise will force you to be present. No copying aloud. You should go back as needed and look at the original code to jump your memory, but the purpose of this important step is honestly reflecting on what you don’t know.

The hardest part of learning to code for me is stubbornness. I either like to default to assuming something is too hard to understand or make believe that I don’t need to know an idea. I almost always find myself encountering the same problem or code concepts without fully committing time to understanding them. Don’t do this. But sometimes you can write something from memory and still not understand it.

Step 3: Write out directions to write the previous code

Next, write out english sentences that tell you exactly what each line of code does. You need to be clear enough that reading these sentences will allow you to understand how to recreate the original lines of code. Do this without giving yourself specific coding syntax. If possible, use the vocabulary to properly describe the code. If you don’t know the vocabulary, then its good to check out places like the MDN to review.

This may be weird because you just effectively “memorized” the previous snippet. A proven effective method of learning is to teach what you know. In the context of coding, you can teach yourself. By treating yourself as both the teacher and student, you can deepen your ability to communicate the coding concepts. Your success in this step will be seen when able to use the instructions to recreate the exact same code as the original code block.

Step 4: Recreate the original code using your instructions

Using your instructions, attempt to write out the original block of code. Be strict with yourself and follow your instructions. Don’t pull from your memory (Assume an irreversible memory leak). Go through your instructions, and line-by-line try to write what you communicated to yourself.

// Example for completed description
// define function called getHTTPObject
// check if XMLHttpRequest exists
// if it does return it as a constructor
// otherwise try to return the constructor for ActiveXObject with Msxml2.XMLHTTP attribute
// check for errors
// and if they come up try to return a constructor for ActiveXObject with Microsoft.XMLHTTP attribute
// check for errors again and kill the process
// After the original conditional, return false

function getHTTPObject(){
  if (typeof XMLHttpRequest != "undefined"){
    return new XMLHttpRequest;
  } 
  try {
    return new ActiveXObject("Msxml2.XMLHTTP")
  } catch (e) {
    try {
      return new ActiveXObject("Microsoft.XMLHTTP")
    } catch (e) {}
  }
  return false;
}

If you do anything like me, then your initial instructions are going to suck. Through this forced consciousness process, you will notice parts that you either missed or didn’t understand enough to explain. Review the actual code and try to revisit your instructions again.

It’s important that during this process, you are not looking at the code while writing the instructions. As much as possible, try to understand the idea, move away from the original, then document your understanding. This is maximize your opportunity to discover where you don’t understand.

Step 5: There is no step 5

You have iterated this process enough to accomplish your end goal of writing instructions that clearly explain the code, you will have accomplished one of two things: mindlessly memorized completely useless code, or remembered the syntax/framework/structure of some code which you don’t completely understand.

If you are in the latter, then you’re on the right path. You realize that no code is perfect and often your understanding of concepts too is imperfect. More importantly, you realize how to communicate what you know and also provide yourself a mechanism for understand what other people are trying to communicate. You provide yourself a strong tool for learning from the plethora of undocumented, but very useful code.

Hopefully this idea was not new to you and you have now learned an effective way to push yourself to learn new coding concepts. Take notes, copy down code examples, give yourself instructions to rewrite the examples, and most importantly look up all the questions you have!