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.


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.


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 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 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.

Sass vs. Less

If you’ve been in the world of web development for at least a few weeks, you’ve probably heard about Sass and/or Less.

That’s because Sass and Less are two of the most common CSS preprocessors in the industry, and are used by many web designers and developers alike.

In this article we’re going to talk about the differences between Sass vs. Less, and more importantly which you should learn as a beginner.

I’m a newb, what’s a preprocessor?

Formally speaking, a preprocessor is a program that takes in one “type of data and converts it to another type of data,” according to Shay Howe.

CSS preprocessers, like Sass and Less, convert into CSS so that web browsers can read the styles.

Some say Sass and Less are like supercharged CSS, because they are extensions of the CSS we know and love. They extend the CSS language by adding features like variables, mixins, functions, and more.

Don’t worry if you don’t understand what these words (mixin, etc.) mean yet.

What is important to understand is that using a CSS preprocessor like Sass or Less makes writing CSS easier, allows you to organize your stylesheets better, and is more maintainable.

The main takeaway: using a CSS preprocessor makes your workflow faster and more efficient. Overall, it makes your life as a designer or developer easier.

Learning a CSS Preprocessor

There are several options when it comes to CSS preprocessors, but the two most common are Sass and Less.

The good news is that once you learn one CSS preprocessor, it is not difficult to switch to another if needed.

Below I’m going to talk about reasons why you should consider each.

Reasons why you should learn Sass

Note: There is Sass (Syntactically Awesome Stylesheets) and then there is Scss (Sassy CSS). In this article, I will be saying Sass, but will be referring to both Sass and Scss.

1. Sass has better language ability.

When comparing Less vs. Sass it’s clear that Sass is more like programming. It has if/the/else statements, for loops, while loops, and each loops.

If you are familiar with writing programming languages, like JavaScript or Ruby, this will be nothing new. Except now you’re able to use them in your stylesheets, thanks to preprocessors.

Less has most of these capabilities, too. They are just not as complex.

Moreover, Sass allows you to do a more variety of math equations. And it has better selector nesting, which can help you keep your stylesheets more in line with DRY principles.

Overall, Sass has more advanced language features and capabilities.

2. Sass has Compass.

Compass is a beloved open-source CSS authoring framework.

Translation: Compass is a framework that goes along with Sass.

And people who use Compass, love Compass.

Even more, lots of big name websites rely on Compass, such as:

The problem? Getting started with Compass is not so easy. (However, there are a lot of awesome tutorials to help you out!)

Aside from Compass, there are other Sass libraries/frameworks. And, yes, there are libraries/frameworks for Less, too. (Check out a list of them all here.)

But none of the Less extensions compare in popularity to Compass.

Learn to Code Websites and Apps →

Reasons why you should learn Less

Less came to the scene after Sass in 2009. Less stands for “Leaner CSS”.

1. Setup (may) be easier

Less uses JavaScript. And you can get going with Less just by downloading less.js, where it will compile the stylesheets in the browser. However, this is not a good approach to take. (Because it will perform AJAX requests to grab the Less files, convert into CSS, and then inject the result back into head of document.)

Obviously, this is inefficient. However, if you’re just playing around and testing out the Less waters — this method will do.

Now, with both Sass and Less most designers/devs will use the command line to compile their files into CSS.

But if the command line terrifies you, fear not. There are a variety of GUI compilers available.

One last thing to keep in mind when setting up either on your machine:

While Less uses JS, Sass uses Ruby. Windows machines do not have Ruby pre-installed. Meaning setting up Sass on a Windows computer may be more difficult. (Again, this is where one of the GUI compilers could be helpful.)

2. Less is like training wheels

Many people say that Less is easier to learn than Sass. Some even say it’s like training wheels.

Moreover, Less’s syntax is more comparable to CSS. Which may be nice for people just starting out, wanting to move from CSS to a preprocessor.

The main differences between Sass and Less

Differences between the two are not massive. Here are a few key ones.

1. Less runs on JS, Sass on Ruby.

As we talked about previously, this could make a difference when setting up your environment.

Again, there are several GUI compilers available where you don’t need to venture into the command line at all.

Meaning this shouldn’t be a factor when determining which to use.

2. Less doesn’t have as many awesome frameworks, like Compass.

As mentioned previously, Less does have some extensions. But nothing like Compass — which people rally behind. In fact, some people use Sass because of Compass.

3. The way you write variables differs.

This is not a huge issue. Both store values in the same way, they just use different symbols.

Sass uses $, whereas Less uses @.

One issue that could arise for some would be confusion while using Less’s @ symbol because in CSS the @ symbol has other meanings—like @media queries and @keyframes. In CSS, the dollar sign has no other value.

In the end, this mostly it comes down to personal preference.

4. In Less, loops only allowed for numeric values.

Again — back to the more complex capabilities with Sass. In Sass you can iterate through any kind of data.

But in Less, you can only loop through numeric values with recursive functions. Being able to loop through any kind of data, like you can with Sass, is much more helpful.

5. Better nesting in Sass

Both Sass and Less allow nesting, but Sass takes it a step further by allowing you to nest individual properties.

Still unsure? Go with Sass.

Unless you are working with something that relies on Less (like a certain frontend framework), go with Sass.

Yes, the learning curve may be steeper at first. However, most agree that Sass is better in the long haul bauce:

  • Sass has a better language syntax
  • Sass has more features
  • Sass has Compass (and other frameworks to choose from)

Basically, Sass is next level.

At the end of the day, using a CSS preprocessor (any preprocessor) is better than using none. It’ll speed up your workflow and make your styles more efficient regardless.

Plus, you can always switch later on. Just start using one.

Which team are you on? #teamsass or #teamless?

What is Responsive Design?

Key Takeaways

Responsive design means writing code ONCE, and having the page look great EVERYWHERE. A great, responsive site should be able to adapt to various screen resolutions. It will look good on a desktop computer, iPhone, iPad, or any of the other devices that people carry around in their pockets.

Your Assignment: Learn Responsive Design Today

  1. Look at the images of Pack below. What is the difference between the smallest screenshot (on the left) and all of the other screenshots? Write down at least 3 differences that you see.
  2. After writing down the differences you will quickly see what it means for a site to be “responsive”. After you complete Pack, do the same for The Japanese Times. More examples can be found at (5 minutes).
  1. “Media Query” is the official CSS property largely responsible for making a site responsive. If you’re a developer, try adding this CSS into your stylesheet. See what happens!
@media (min-width: 400px) and (max-width: 600px) {
    h1,h2,h3,p {
        color: red !important;

The code listed above should make your h1, h2, h3, and p tags (headers and paragraphs) red. You can play around with some example code over at Google’s page on media queries.

Additional Resources to Keep You Learning

Bootstrap: a popular framework for making a responsive website. Download it for free.

Zurb Foundation: another framework for making responsive websites. It’s free.