Posts

What is Coding?

print “Hello, World!”

We’re going to talk today a little bit about coding. Specifically we’ll answer the question, What is Coding? and also cover a little of what happens when we code. Before you begin, though, I want you to right click on your browser window and choose the View Page Source option. What you just got was a view of that web page’s code. Which is to say, you got a glimpse of the language that tells your computer how to make that webpage look the way it looks.

The first time I actually looked at the code in a browser window was a revelation to me. Here was the internet in the internet’s own voice. Sure I didn’t understand most of it, but I could pick out snippets of words and phrases I understood. I knew a font name or two, understood pixel sizes more or less. It was alien to me, but I could understand how it worked. Here was the language that my computer spoke. Or so I thought.

If you’re planning on learning to code at all, it’s worthwhile thinking through what exactly is happening when you code, what exactly it means when we say someone is coding, what the difference is between coding vs. programming, what languages you might end up coding in, and how to get started coding.

<style type=awesome_sauce.css>

So let’s start briefly with what coding isn’t. I mentioned above that when I first saw the source code of a web page, I thought that I was looking at the language my computer spoke. This is one of the common ways of talking about what coding is. It’s not exactly true, though.

Your computer doesn’t really understand the nuances of language. In fact, the only terms your computer understands well at all are “Yes” or “No.” Imagine talking to a group of engineers, but your phone has gone out and your radio only works one way. You can only communicate with a flashlight. One flash for yes, two for no. It might take a while, but eventually, the bridge will get built and all will be happy.

This is how a computer communicates with people. The language the computer speaks is binary code, a mathematical language that looks like a line of ones and zeros. Essentially the computer understands “Turn this function on. Turn this other one off,” and nothing else. So unless you’re typing strings of ones and zeros into your text editor (which, you’re not…just no), you’re not really writing code in a computer language.

OK, so if writing code doesn’t amount to writing in the computer’s own language, what are you doing?

Well, think about it like this. You don’t speak binary and the machine can’t come close to understanding human languages. So in order for you to tell the machine what to do, you have to have a translator who can act as an intermediary. This is code. It’s a form of writing that isn’t binary, but that the computer can understand.

For most of the programs you’re likely to write, the code is actually several steps removed from the binary code. You write in a high-level code that’s closer to human language, and programs built into your computer translate them down into binary. It’s like if you needed to speak to someone who knew Mandarin, but the only translator you could find spoke only French. You would need another translator to translate from English to French and then they can translate to Mandarin.

What sort of blows my mind about all of this is that it works somehow. We have programs translating programs to a machine that only speaks binary, which is an insanely complicated prospect. Yet here I am typing human words on my binary speaking computer.

Luckily, when you start coding, it’s not really important to understand how this all works as long as you understand what programming is you’re headed in the right direction. The important takeaway is that coding is writing in an intermediary language that both you and your computer can communicate in.

<{Coding=Programming} YES>

When I was growing up, my dad was a computer programmer and all the people he worked with were programmers. This was how I understood people who wrote for computers for a long time. They were programmers.

Then it seemed like there was a shift in either terminology or industry, and suddenly people who wrote for computers were coders. Which has prompted me to wonder whether there is a difference between the two activities.

A little research shows me that it depends greatly on what school of thought you subscribe to. Several forums I have looked through say that there really isn’t a difference between a coder and a programmer. It’s a difference in terminology rather than activity.

The egalitarian in me likes this way of looking at things. However, Jonah Bitautas makes an interesting argument that there is a real difference that amounts to a matter of scale. Essentially, a coder is someone who writes language for computers. A programmer is someone who oversees the writing of a whole program — that is to say, a whole project’s worth of code writing.

It’s the difference, I think, between calling someone literate and calling someone a writer. A literate person can write and read words, but doesn’t necessarily see how they work together into elegant paragraphs and sentences. A writer, on the other hand, understands how those words work together in a larger, more complex structure and can maneuver through that structure with intelligence and choice.

Like I said, I love the egalitarian quality of the first definition, but I’m all for preserving a sense of difference between the activities, if for no other reason than it gives people something to reach for. I have written code, but I am not yet a coder. When I am a coder, I think I’d love to be able to look forward to the day when I can call myself a programmer.

Languages

There are literally dozens of languages a person can learn to code in. Although a few languages are all-purpose (or multipurpose), most serve a specific function. CSS, for example, functions primarily to make things look pretty on the web. JavaScript, a relatively old language, exists to make web pages more functional. Depending on what you want to accomplish, you’re going to have to choose a specific language. There are a few common ones that you might want to work with, especially if you’re just learning to code.

HTML

When I asked you a minute ago to open the source code for this web page a minute ago, it took you to lines of code written in HTML. Short for Hypertext Markup Language, HTML works as sort of the bones of the Internet. It tells web pages what should be displayed where and how they’ll fit within a given style sheet. It also tells your browser where to look for content like images and videos that you might want to include, as well as where to find the style sheet you’re working off of.

CSS

CSS is the stylesheet. If you open up a CSS file, you’ll see a lot of references to font families, colors, bold or not, etc. When your browser loads a page, the HTML tells it “Hey. Make this part of the page look like a header. OK?” It also says “Here’s where to look to understand what a header should look like.” This will always be a CSS file.

Javascript

Javascript is a language that brings interactivity to the web. It’s a language that makes things happen on a web page. When you click a button on a web site, for example, it’s JavaScript that makes the button seem to click. The controls for video players on the web, animations, etc. Most of these are JavaScript of some other dynamic programming language. In a later post, I’m going to be writing about front-end versus back-end work using Javascript and PHP. Which is to say, programming for the user of the website versus programming for the server of the web site. More on that to come.

Ruby on Rails and Python with Django

We actually already have a baller post on the differences between these two framework languages, which is worth ducking away to read when you’re done here. The short version is that Ruby on Rails (Rails to its friends) and Python (named for Monty Python) are both programs that are used to develop web applications. Which is to say they create programs that allow web pages to do things at a high level of interactivity. If you want to, for example, build a bot to automatically create an automatic payment system for your clients, you’ll probably use one of these. They’re great programs to learn to work with because they are extraordinarily versatile and there is a lot of extant code for you on the web to begin playing with this.

Learning to Code

There are actually a lot of parallels between learning to code and learning to write well (as there should be, since coding is just writing in computer languages). I think the most frustrating of these is that, as with learning any language, you have to be willing to spend time practicing it and doing it poorly.

There are some people who are just natural coders, sure, just as there are people who can speak Italian after listening to a couple of operas. For the vast majority of us, though, learning to code is a process that involves trying to tell the computer to do something, having the computer come back with an error message (which is its way of shrugging its shoulders and saying “Qua?”), and then trying a new way of doing the same thing.

The most successful self-taught coders I know are people who regularly take on coding challenges just to see what they can make. I know a guy who writes Python bots for Twitter as a sort of hobby. He’s made some things that are pretty awesome to behold.

Coding languages now are dynamic and complex enough that often times if you can conceive of a thing you want to have happen on the web, you can do, and probably there’s a web site that can help you work out how.

There are also many ways to find classes that can get you started on the basics of whatever program you want to make. That means there’s really no reason to not start playing a bit. There’s no risk to trying something (you can’t break the web; Kim Kardashian already did that), and the gains are huge. So go for it. Conceive a bot, conceive a web page, conceive a font family, and get started.

Understanding HTTP Basics

One thing that always surprises me when teaching a security class to developers is how little they understand about HTTP. Sure, everyone knows that a HTTP 500 error is a problem on the server, and 404 means the file is missing, but few actually understand how HTTP works at a lower level. This is critical to understanding most web application vulnerabilities and will help you be a much better web developer, so lets dive in!

Skip this if you have a decent understanding of HTTP. Otherwise, it will be a great refresher. First, let’s start with the super-basic before we quickly move into more advanced topics — HTTP. HTTP is the protocol that is used by web servers and browsers to communicate. HTTP is based on a request and a response.

When the you type in a webpage URL in the browser and hit Enter, the browser makes an HTTP GET request. Here is an example of what that looks like:

There are a few things worth noting in the screenshot above. Let’s take a look at the first line. First, the HTTP “verb” is GET, which is generally used to retrieve a document, image, or other internet resource. We will look at the other verbs in a minute. Next, the webpage being requested is “/home”. Anything after the “?” are parameters, which come in key/value pairs. Finally, the HTTP version is provided, which in this case is 1.1.

The rest of the lines are HTTP headers, which do things like: tell the webserver what website to retrieve, based on the domain (Host:); report the user-agent and acceptable encoding and language; and other browser-specific options.

From a security perspective, we need to be aware that parameters in the querystring get logged all over the place, so we want to make sure nothing sensitive or important goes there (think passwords, email addresses, or API keys).

Another HTTP request is the POST, which works almost exactly like the GET request except the parameters are sent in the body of the request instead of on the first line. This is good for security since these values are generally not logged by default on webservers, proxies, or other software as the request is transmitted over the internet.

Other request types are OPTIONS, HEAD, PUT, DELETE, and a few other more obscure values, however GET and POST are the most common. Let’s take a look at the HTTP response:

HTTP responses are similar to HTTP requests in that they are text based and contain HTTP headers. On the first line above, the HTTP response returns the HTTP status code. When everything is going right, this will be 200 OK. Below are the list of status codes which can be returned:

After the status code, some server headers are sent, including information about the type of server and software it’s running. Next, the body of the response contains the data we requested, which is generally HTML, CSS, Javascript, or binary data like an image or PDF.

Since HTTP is a text-based protocol, it’s easy to make HTTP requests. You can try this by running telnet and connecting to an HTTP server and then manually making a HTTP GET request. Try it yourself by typing “telnet google.com 80”.

Then, when telnet connects to the webserver, you can manually make an HTTP request by typing:

“GET / HTTP/1.0 (return, return)”

This should return the HTTP response for the homepage.

That’s it, now you know the basics of HTTP. Here are the important parts:

  • HTTP is a text based protocol
  • HTTP is made up of requests and responses
  • HTTP responses have a status code

Now that you have that covered, check out some hacking tools in the blog post Web Hacking Tools: Proxies.

What People Really Mean When They Say “I Want To Learn How To Code”

There are two important things to know about coding education:

  1. Most people don’t actually want to learn to code
  2. Learning to code doesn’t mean one thing anymore

It’s important to know these two things because otherwise the way we teach people about coding is wrong, and people won’t learn.

The first point I’ve seen over and over again. People who tell me they’re going to learn how to code, then they start learning, and they think it’s boring as hell.

I call it the coding fallacy. People think they want to learn to code but what they really want to do is build a product.

When we think about it, this should be fairly obvious. Knowledge of code in and of itself is not valuable if you can’t do anything with it. So for most people the biggest motivation for learning to code is building something (although a close second is getting a higher paying job).

That brings me to point number two. Learning to code doesn’t mean the same thing anymore.

It used to be that in order to code you had to know almost everything about computers (hence the term “Computer Science”). Then things were abstracted to the point where you didn’t really have to dive into certain topics unless you really needed to. For example, as a web application developer at this point I need to know very little about system administration because it’s mostly done for me by tools like Heroku and Amazon Web Services.

So when people say they want to learn how to code, most teachers start where they assume they should (where they always have), with data types, the various structures of a language, and help students develop a deeper understanding of computers.

The problem is that’s not what people want. They want to build something. And we should no longer take for granted that in order to build something you have to learn everything about computers or even coding in general.

For example, if someone is already working with a great back-end developer, it would make sense to just teach them the front-end, because that’s going to be the most useful thing for them. They will actually get what they want done faster, and they will be able to learn the back-end at a later point in time. By doing so we reduce the cognitive load on the student and enable him or her to learn faster.

There’s so much that could possibly be taught about coding that we need to start identifying at least semi-complete subsets that someone could learn. At the very least I want to pose the following important distinction I’ve learned:

  1. Web development
  2. Non-web development

When you’re developing for the web you specifically have to deal with:

  • HTML
  •  CSS
  •  Routing
  • Databases
  • Hosting/DNS
  • Application structure

There’s a lot here to learn. And most of it is pretty irrelevant to non-web development (except databases and application structure obviously).

The way I see it, most coding education involves a bait and switch. It goes like this:

Student: “I want to learn how to code.” (But what they really — but don’t know enough to ask — is I want to build a web or mobile application.)

Teacher: “Okay let’s start with data types.”

Student: “…”

(2 weeks later)

Teacher: “Now we can design efficient algorithms.”

Student: “But I just wanted to make a cool-looking website!”

As teachers, we need to recognize that when people say they want to learn how to code, they often really mean that they want to build a web or mobile application.

That’s because to them, that’s what coding IS. It’s all they’ve ever been exposed to about coding. The problem is that they don’t know how to ask for it! So we shouldn’t just be taking everything they say at face value. It’s our job as educators to read between the lines.

I remember watching a play a few years ago in which a priest says that you have to tell the truth even in difficult circumstances. The person he’s talking to asks: “but what if someone asks you a question and you know the truth will hurt them?” The priest responds: “When someone asks you a question, answer the question they are REALLY asking.”

In education as well, you have to read between the lines to figure out what people really want. If they’re asking some specific thing, you have to guide the person towards what’s going to lead them towards their ideal learning experience.

So it’s up to us as educators and as experts to guide people in the right direction and not just let them flounder. If we can do this, then we can empower a lot more people to do amazing things.

As a student: learn what you want to learn.

One of the best things you can do in your own learning adventures is learn a little bit about a lot of things — so you know what you want to dive deeper into later. Here at One Month, we’re launching a Learning Library in the new year, a free resource of videos, essays, and information on topics related to coding, design, and entrepreneurship. It is your first 1 minute, 1 day and 1 week of content for any subject.

Some People Say Ruby Is Too Complex for Beginners…

Is Ruby the right programming language for beginners?

One of the biggest criticisms I hear lobbed against learning Ruby as a beginner language is that Ruby has so many different ways of doing things. People say that these different ways of doing the same thing makes it hard for beginners to learn.

To be specific, here’s one example of this argument that I read on reddit recently in response to my earlier post, Why Beginners Should Learn Ruby on Rails:

“Ruby almost always has 100 ways of doing any problem, and frequently the user-submitted examples on Stack Overflow are meant to dazzle rather than instruct.”

or

“So much shorthand and so many options that when I’m trying to learn one particular function, I get 100 different users telling me to do the problem 100 different ways, none of which helps me understand the thing I’m trying to learn.”

This is true.

Ruby in particular has lots of instances where there are multiple, equally good (and sometimes not equally good), ways of solving the same problem. But rather than that being a weakness of Ruby, I actually think the flexibility of the language is an incredible strength, especially for beginners.

But rather than that being a weakness of Ruby, I actually think the flexibility of the language is an incredible strength, especially for beginners.”

You see, there’s no one way that you learn something, and whichever way sticks is usually the best for a beginner.

Here’s an example.

In Ruby, there’s the select method (in Ruby, functions are called “methods”), which lets you take a list of things and pull out a sub-set of that list.

It looks like this:

list_of_numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
list_of_numbers.select { |number| number.even? }

Even if you’ve never coded in Ruby in your life, read that second line and take a guess at what you’re going to get. That’s right, you’re going to get the sub-set of even numbers: [2, 4, 6, 8, 10]

There’s a second way to do the same thing. It’s called the find_all method.

So instead, you could write:

list_of_numbers.find_all { |number| number.even? }

What do you think you’ll get here?

Right! It’s exactly the same result as the select method.

So why does Ruby have at least two ways of doing exactly the same thing?

It’s because the people who created Ruby were inspired by a few other programming languages — Perl, Smalltalk, and Lisp are a few — and they borrowed the different names for doing things from those languages. Also, it happens to be really easy to write a method once in Ruby and just point other methods to it. That’s not as easy to do in other languages.

So why is this an advantage?

Well, because you don’t have to remember both of these ways of doing things! You just have to remember the one that works for you. I almost always use select.

Doesn’t this get confusing? Maybe, if you’re looking at lots of different people’s code. But by that point you’ve already learned that select and find_all are the same, and it’s not so hard to figure out. Language is a lot like this. There are many ways to say the same thing in English:

Language is a lot like this. There are many ways to say the same thing in English, which enables creativity.

I’m happy, I’m cheerful, I’m pleased, I’m delighted, I’m jolly, I’m beatific, I’m glad, … do I needto keep going?

The flexibility actually opens up creativity, which I think is one of the coolest parts about a language like Ruby. Meanwhile, in most other languages when there’s only one way of doing something, if you don’t remember that way then you’re screwed.

Another clear example that people like to hate on all the time: parentheses.

In Ruby, parenthesis are optional in methods. So are brackets { } a lot of the times, and you can basically use either single quotes or double quotes interchangeably.

Take that same list from before:

list_of_numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]

What if you wanted to see if it included a particular number?

You could use the include? method:

list_of_numbers.include?(2)

But you could also leave out the parentheses in this case (and lots of Rubyists do) because it’s prettier and easier to read:

list_of_numbers.include? 2

Sure, there’s a few rules about this. You have to put a space beforehand instead of parenthesis (otherwise Ruby would think you were trying to run a method called include?2 which doesn’t exist).

The point is, you can try many different ways of getting at the same issue, and get an answer to your question in many ways. Rather than get stuck on needing to know the exact way to write something, you can solve your problem in more than one way.

The same is true for software applications, like AutoCAD. As a user, you can type into the command line, navigate towards a button, or use drop-down menus. In addition, you can choose to draw a line with at least eight different tools (line edit, polyline, arc, points, etc). One way isn’t better than the other — they’re just all different tools for drawing. Having many different ways to get shit done makes it easier for people to remember the technique that works best for them.

Flexibility! It’s a beautiful thing.

I’ve never understood why people thought that having multiple ways of doing something was a bad thing. When you’re first learning, you have to grasp and understand whatever concepts you can, as a starting point.

Meanwhile, a language like JavaScript is a truly hard language for beginners to learn, because there are so many specifics that don’t come naturally to a beginner, and you have to do them that way. I’m not saying you can’t learn it, but the amount of times I’ve heard beginners so frustrated they were ready to give up because they’ve forgotten a “;” somewhere and have no idea where.

If you’re interested in reading more about why Ruby is a great language for beginners, check out Why’s (Poignant) Guide to Ruby. It’s one of the most beautifully and interestingly written pieces about programming, and is one of the biggest reasons I fell in love with Ruby in the first place.

And then, if you want to learn more about Rails, watch our free one-minute video or check out our Rails course to go build your first app.

3 Ways to Know If A Developer Is Good

If you don’t necessarily have a technical background and you’re thinking about bringing in a developer, how do you assess them? How do you even know if they have the very particular set of skills your site or application needs?

On this Founder Friday, Mattan and Chris tackle how to win devs, and make an exciting announcement for all you geeks on the comic book side of the spectrum.

Programming is its own language. Or rather, it’s a language with lots and lots and lots of different languages that different developers speak. But as a non-speaker, there are several ways you can break through all the C++ and CSS to get an honest, accurate picture of a potential developer.

1: Master The Phrasebook

The hard truth is if you’re hiring someone to code for you, you should learn at least a little bit of code. That takes time, and some effort, but it’s worth it for a couple of reasons.

The first is that you need to know what you’re talking about, at least at the surface level, because that’s going to inspire confidence and trust in your developer that they’re working for someone who knows what they’re doing; that they’re working for someone who values their contribution.

But beyond that, you need to, at least on the surface level, know what they’re talking about, and the basics of the argument they’re making for themselves. There are many places all over the internet you can get access to an hour of code, just to start you off.

But rather than leaning only a little bit of HTML, or a little bit of Java, the best play is for you to develop (ha) a holistic sense of what code is and how it’s useful to your business/startup/site. More about that at the bottom.

2: Check The Portfolio

It’s not your job to know everything, however. The best lens into a developer’s skills and experience is through a portfolio of their work.

Whether it’s just screenshots or whether they’re able to bring in an application they worked on, actually being able to see examples of their work can give you a sense of what they’re capable of.

But you can’t just look at webpage. You need to be strategic in how you’re ask a potential developer to describe their experience, and drill down on their portfolios. Find out what their personal contributions were. Push for the reasoning behind why they make that choice and not a different one. Get them to describe how they worked on their projects, whether it was remote and freelance or leading a team.

Look not only for their expertise, but how engaged they are in telling those stories. It’s worth taking at least 5 minutes on each example to really get a candidate talking. People will reveal themselves once they’re put in the position of having to relate their experience.

You want someone who’s thoughtful and excited about what they do, not disengaged, condescending to a non-programmer, or talking over your head.

3: Ask For Recommendations — From the Candidate

The other way to get a thorough, but thoroughly non-technical, sense of a good developer is to ask for recommendations. Before you make a call or shoot off an email, ask the candidate what they think their references are going to say.

Before you actually call and contact the references, ask the candidate what they think their references will say. This will tell you a lot.

Again, pay attention to the language they use — whether they’re hesistant or dismissive or really eager to talk about their old team.

Don’t worry about the imagined imposition of reaching out to someone who’s worked with a candidate. It isn’t one.

Talking to someone on that person’s team can give you a whole other window into not only what that person’s skills are, but how effective they are in accomplishing projects and collaborating.

Whatever you need a developer for, you’re going to need them to keep you in the loop. So, just keep the “no jerks” rule in mind. No jerks. Don’t do it. You want someone on your team to be on your team.

And lastly… Should you require a developer test or not? Some specific questions to ask if you do:

There are a few additional ways to judge a developer.

A trial period, or beginning a working relationship with someone on a project basis, is almost never a bad idea. It gives you a chance to test their ability to contribute effectively to your team — and see the progress they make with their code — without the full commitment of a salary and benefits.

Ask them what their experience with and how open they are to regular check-ins. Again, good developers won’t just be able to code. They’ll also be open to feedback and willing to present their ideas to non-technical teammates.

Some specific questions that can help you gauge a developer: ask them what their favorite stack is, what language do they like to code in and why? Do they do any testing, and if so, what kind of system? Do they use version control, like Git? Just because someone’s been coding for a while, that doesn’t mean they’re good.

Look for someone who’s open to trying new things, and who seems like they can adapt to the constantly changing methods and technology.

It’s really that willingness to communicate, and the ability to explain themselves and be held accountable, which separates good developers from just developers.

Even if you only need some one-off help, you’re bringing someone into your team’s locker room. It’s not enough that they can code. They also have to communicate.

Refactoring: Stop Worrying and Code, You Can Fix It Later

Do you write perfect code on the first try?

When a writer decides to produce a novel they don’t sit down and plunk out perfect copy in one go — rather, first comes an outline, then a draft, then revisions, refinements, and finally, a publishable final draft. This process works because it lets a writer begin with big vague ideas and work through them, ironing out all the details as they surface.

Software engineers have a similar technique to editing, and it’s called refactoring. Refactoring is where a coder changes the structure of a piece of code without changing it’s function. It’s a very useful way to clean things up once your code is actually working. Most importantly, knowing how to refactor allows you to get down to coding faster, and without fear of “screwing it up.”

Lets take a look at how the writer’s pattern can be applied to converting your ideas into code.

Start With Pseudocode

Pseudocode just means “shorthand that describes code,” and it looks like plain English. I begin by writing in comments that describe the code I’m about to create, as much for my current benefit as for future documentation needs. Don’t think, just pseudocode the first approach that comes to you. The nice thing about pseudocode is that if it’s bad you haven’t wasted any time writing actual code. Once you have something that looks halfway decent, move on.

Stub It Out

Bits of code usually have an input, an output and some main variables; writing these around the pseudocode forms a sort of a skeleton called a stub.

Fill It In

Write actual code!

Iterate Until It Works

In this case, the above code didn’t work, but don’t be discouraged. Even for the most experienced coders, 90% of the job is debugging, just keep pushing until it works.

Clean It Up

Now that it works, look at your code. What’s ugly? What could be simpler? What is running slowly? Because your code is functional you can fearlessly modify it to make it better as long as you test it after each change. If it doesn’t work after a change, just undo it and try again!

Refactoring is your friend

The important lesson here is that you, like a writer, should not worry too much about the quality of your first draft because it can always be made better later. What’s great about this approach is that it works just as well for tiny snippets of code as it does for whole scripts or huge projects.

What’s great about this approach is that it works just as well for tiny snippets of code as it does for whole scripts or huge projects.

All software is made of little simple bits of code that all build up to a big complex whole. In the world of coding, we have a thing called a function or method that lets you draw a box around a bit of code, define it’s input and output, and re-use it as a black box that performs that some action.

One of the many reasons it’s good practice to write code using functions instead of copy-pasting is that if you want to change code later you only have to do it in one place (the function). Another benefit is that it’s much easier to think about small pieces of code. Once your code is working, you may notice that some functions work, but aren’t very good.

Refactoring means freedom!

Understanding refactoring means freedom from the worry of “writing it wrong”. When you sit down to solve a problem, don’t stress, remember no one writes perfect code the first time.

So focus instead on writing something that works, and remember that you can always refactor later!

Let’s Change How We Think About Learning to Code

Before I ever had my first paid job as a programmer, I spent a lot of time contemplating what it means to get paid as a programmer. I was a hobbyist, teaching myself to code in grade school and high school.

When I became a freshman in college studying Computer Science, I began thinking about the future. I was being asked to commit to being a programmer for the rest of my life. I had no idea what it meant to work with programmers or even work as one on a team.

I’m sure anyone looking to dive into software will have the same questions.

  • How do I start learning to code?
  • What language should I use?
  • What kind of computer should I have?
  • What operating system do I need?
  • What books should I read?
  • Should I go to a bootcamp?

The trouble is that all these are surface level questions. You feel frustrated because every time you ask these questions, you don’t feel like the answers satisfy you. Someone can write a post telling you the differences between Ruby vs Python and yet at the end you still can’t make a decision between the two.

That’s because there is a laundry list of meta-questions you might not even be aware of yet. What you’re really trying to answer are questions like these:

  • Why do we have so many programming languages?
  • How do I know if I’m on the right path, using the right technologies, and working with the right people?
  • What is the difference between a bad programmer and a good one?
  • How can I tell if other people are good or bad programmers?
  • How will I know when I’m a good programmer?

These are just scratching the surface of the underlying questions you probably have.

You will have this intense feeling of discomfort for a while. You know there are lots of important questions you should be asking, but you don’t know what they are yet or how to articulate them.

This experience shouldn’t be unfamiliar to you. Remember in high school when they tried to prepare you for college? You took these career quizzes, teachers gave you advice, your parents pushed you in different directions. It was a huge decision to make and you didn’t even know where to begin.

It’s the same thing when you start programming. The fundamentals of computers have always been the same.

It is called a programming *language* for a reason.

The most obvious purpose of a programming language is to tell the computer to do what you want. I type some code, it reads it, and adds two numbers together and gives me the result just like I expected it to. Perfect.

The hidden purpose of a programming language is to talk with other human beings.

The hidden purpose of a programming language is to talk with other human beings. We have many natural languages like English, Spanish, German, Chinese, the list goes on. There are many ways we can communicate with other human beings. The same thing applies to programming and this is why we have so many different programming languages.

There are a thousand ways to explain an idea. The computer can understand all of them, but humans can’t. When you write code, you have to express your ideas in the clearest ways. Code that you wrote six months ago looks like gibberish because you think differently now. There is so much difference in human thinking due to learning, culture, and experience. That means that great code emphasizes human understanding first and computers second.

Great code emphasizes human understanding first and computers second.

There is a broad spectrum here and each programming language falls somewhere on it.

Some programming languages are designed more for computers than they are for humans. In fact, the most computer-focused programming language would actually be 1s and 0s. Something that, as humans, we wouldn’t even consider a language at all.

As you move up the chain, you can see things shift more towards humans.

Assembly is introduced to make the 1s and 0s more memorable for us.

C is designed to be an easier level than assembly but you still have to heavily think about how the internals of a computer works.

C++ begins to introduce some human concepts into the language so we can represent ideas better in code.

Java builds upon the ideas of C++ but abstracts away the internals of the computer as best it can. You don’t need to care about how things inside your computer like RAM is used as much.

Python takes another step towards humans and focuses on a syntax that’s more readable for humans but still has a lot of the structure inside it.

Ruby is focused on flexibility. They want your code to be like writing a story or a poem. Sure, you still have to worry about how the computer works somewhat, but even less so than Python.

Every programming language fits on this scale somewhere.

The trouble is that it’s hard to even understand what this means as a beginner programmer. If you don’t know how the computer works, then Assembly is going to sound scary. At the same time, if you only ever learn Python then you will feel something is missing because you’ve never learned how the internals of the computer actually work.

The trouble is that it’s hard to even understand what this means as a beginner programmer.

The internals of the computer are the building blocks of programming that you’re taught in college. The problem is that college is on one end of a spectrum that we didn’t realize existed until recently.

In a college computer science degree, you’re put in a world of heavy theory and concepts. There is little practical application of these ideas, but you dive deep into these topics. You learn about algorithms and data structures and how the electricity flows through the computer to make it work. Yet, you learn all this without seeing its value applied to problems that make money in the business world. At the end of the day it feels very disconnected.

Bootcamps tend to be the opposite end of the spectrum. You learn how to type code without ever learning how a computer works. The stuff you learn is built upon a fragile foundation because you’ve been quickly pushed through a system designed to get you a job after just three months (or less).

Until the recent rise of bootcamps and online learning, I don’t think it has been obvious this spectrum even existed in education. As you read this, 5 more bootcamps are getting started and 5 more colleges are committing to teaching old technology for another year (not really, but basically).

The value of programming and tech is becoming apparent to the entire world and it’s becoming cool.

The value of programming and tech is becoming apparent to the entire world and it’s becoming cool. Being a programmer used to be considered unattainable if you weren’t trained in it. With the rise of popularity in startups and the financial success of tech companies, learning programming and investing in technology is becoming the cool thing to do. The barrier to entry isn’t as high as it has been in the past and the average person is able to hop online and start learning Rails in 30 seconds.

The value of having skills in tech are becoming increasingly obvious as well. Being a programmer means you can work from home, remotely, and still take home a six figure salary. Print designers are looking to add web design to their skill set because they know they can advance their careers that way. Corporate managers are looking to start a startup because they feel like they would get more value out of it. The list goes on and on.

The important piece of all this is that these are all people without a technical background.

They come from careers where software was not a large part of their job. The need for learning software from a more human focused vantage point is clear.

It is likely that college will persist as the place to learn deeply technical things and bootcamps will be the place to dip your toes in the water.

There is a middle ground though that is largely unfulfilled — and what online education startups are beginning to address. A place where you can go to dip your toes in, but shows you that going deeper isn’t scary.

The reality is that everything about computers that exists today was created by humans. It’s all a product of our imaginations and hard work. We have the tools for anyone to learn it.

The path to becoming a programmer is simple. You start at a point on the spectrum where you feel most comfortable and you work your way towards the middle.

The path to becoming a programmer is simple. You start at a point on the spectrum where you feel most comfortable and you work your way towards the middle. The middle ground is a place where people are equally comfortable with people and computers. It’s the future we’ve dreamed about where most people are able to write their own software to solve their problems.

If you start on the deeply technical side of the spectrum, you’ll be best served by figuring out how to apply your technical skills to solve human problems. All the hard work and innovative software you create can be used by thousands of people to solve their problems in unique ways.

If you start on the human side, learning technical skills and programming will give you a tremendous advantage in solving those human problems you work on every day. Maybe that nagging issue you can’t seem to fix is solvable by writing your own tool to improve communication.

The important thing to realize is that there’s no one way to start and no one direction to go. If there were, everyone would be doing this and it would be easy. But you should keep trying because coding is one of the most valuable and creative things you could ever do. You can literally build things out of thin air that don’t exist yet.

And one day you’ll step back from the computer and realize you finally get it. There’s no feeling like it. As Neil Gaiman says, “Perfection is like chasing the horizon. Keep moving.”

Top Five Reasons You’re Wasting Your Money When You Don’t Know How To Code

Here’s a guy.

He works in Bushwick, Brooklyn.

“Creative Director” they call him. Well, he isn’t introduced that way, but if you saw him; you’d know. He doesn’t give pep talks. Doesn’t own a car. He donates to NPR, and cares deeply about Meatless Mondays.

He’s changing the world. Or so he thinks.

Because… while his non-profit has been steadily raising money for water in Africa (over $2m came in from donors just this year!) …a fat chunk of that cash has already been lost. Lost on spaghetti code and fucking abysmal project management.

If you’re going to be working with a web development team you should know, at the very least, some coding fundamentals. Otherwise, you’re likely wasting money. Money that might be your savings, your company’s investment, or money that is owed to a group of children 7,500 miles from America.

Here are 5 reasons you waste money not knowing how to code:

1. It takes you 30 minutes to understand a basic coding concept

“So…. tell me again, the CSS is doing the who?”

2. You have to ask your developer to make every little change

“Hey Tom, can I see the text in Red?”, you ask, “Blue?”, “Dragon Green?”, “Honey Yellow?”

If you knew just a little bit of code you might be able to check it out the text editor yourself, or even update the CSS (it’s not that difficult). Okay, not that you should, but if you could then at least you’d know how long it takes.

You might also just use Chrome’s Web Inspector (which could test out all 4 of those colors in less than one minute), saving you and your developer a lot of back and forth time on revisions.

All tips that come within the first 20 hours (or so) of learning to code.

3. You Hire the wrong people

4. You chose the wrong language!

“Should we use CSS, XML, SSL, or CMS?”

5. You can’t properly estimate a project

In programming, it can be hard to explain the difference between the easy, and the virtually impossible. Knowing how to code makes that easier.

During my career I’ve watched tens of thousands of dollars slip away from non-profits — mostly due to mismanaged developers, and poor technology choices. Money that could have been literally feeding children in Africa!

I used to work for a non-profit. It was dark period. But it doesn’t have to always be that way.

Even if you don’t work at a non-profit, I’m sure you’d like to save some money: learning to code helps project managers manage better, it makes team leaders more confident, and most importantly it makes you look more attractive.

jQuery vs. JavaScript

Here is a question that floats around a lot when people are thinking about learning languages or methods to bring interactive content into their web sites: What’s the difference between JavaScript and jQuery? So to understand the difference you need to look at a little bit of code.

Now, don’t worry if you don’t understand code. The main point of this is to see how jQuery and JavaScript do the same thing in different ways and what makes jQuery so much easier for some of the things you’ll want to do. Trust us. You’ll be fine.

Coding Interactivity

So let’s say we’ve made a simple web site — it just says “Hello” and “Goodbye” (not a terribly inviting web site, but it’s just here to make a point) — and we want there to be a little bit of interactivity in it. So our web site is built of three basic frontend languages. You’re going to have a little HTML, a little CSS, and a little JavaScript.

If you’ve seen our earlier video on what JavaScript is, you know it’s there to add interactive elements to the site. It can be complex interactive elements, like a clickable “button” or simpler things like changing the text color when you click on it. Those are all doable because of languages like jQuery and JavaScript.

A Condensed Way to Code

To see the difference between them, let’s look at a simple example of one application of these: making a line of text change color. If we want to do that using JavaScript, this is what the code would look like:

If you don’t code much you’d be forgiven for getting lost in all that! It’s a lot of code for one action and if you’re new to coding, it kind of looks like five lines of nonsense.

The same action in jQuery looks like this:

You can see it’s one line that says “grab this class and add this extra class from CSS to it.” Essentially, it takes all those steps you saw in the JavaScript and makes them into one command.

You can kind of think of it like this. When you have to ask someone to do a task with a lot of steps — like making a pot of coffee — you don’t tell them to do the steps again and again, you just say, “Hey, could you make some coffee?”

That’s jQuery. A group of developers said, “Look. There’s these things we have to do all the time in JavaScript an it takes us five complicated lines every time we have to do that.” And they didn’t want to write five lines every time, so they came up with a way to do that in just a line or two.

Hey could you animate this, please?

This is what we see when we look at jQuery. We see a list of familiar titles — Animate, Delay, Fade-In — all these things that would have taken lots of lines of code in JavaScript, and now you can just click on them and write them out as maybe five or six lines total. That is jQuery in a nutshell. It’s all the functionality of JavaScript, but it simplifies the process immensely.

To get started with jQuery, you just have to type this one bit of code into the header of your project:

It’s kind of like in The Matrix when Neo (aka Keanu Reeves) gets an injection of knowledge uploaded into his brain and he wakes up and is all like “I know kung fu.”

By typing this jQuery line into the top of your code, your code is all of a sudden like, “I know what animate means” and “I know what animate AddClass means” with one line of code.

Takeaways

  • jQuery is a framework that lets you write JavaScript quicker and easier.
  • The developers of jQuery created it to condense common JavaScript tasks into fewer lines of code.
  • You can code most common JavaScript actions using jQuery (and you can actually check out their API page for a complete list of what you can do)
  • It’s easy to install and get the code to understand jQuery.