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.

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!”

Learning to code will never make you this happy.

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.

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.

Front-end vs. Back-end Developers

Do you have an interest in programming, website development, and application development? If so, then becoming a developer is a career move you may want to research. When it comes to developers, there are typically two groups to choose from: front-end developers and back-end developers. In this post, we’re going to look at the differences of each in terms of description, skills, programming languages, and earnings to help you in your decision.

Front-end vs. Back-end Developers

If you are either wondering what the difference is between a front-end developer and a back-end developer, or looking for an explanation that you can easily give your friends when they ask you what you do, here are a few ways of describing the two.

  • Think of your head. Your face would be the front-end that interacts with others using input from the eyes, ears, and nose and producing output through the mouth. Your brain would be the back-end where information from your eyes, ears, and nose is stored and where information to the mouth is sent from.
  • Think of your house. Things like the interior design, furniture, shingles, siding, windows, doors, etc. would be the front-end. The framing, insulation, beams, and foundation would be the back-end.
  • Think of your car. The engine, computer system, oil, gas, lights, etc. are a part of the back-end. Everything else is the front-end.

A front-end developer is someone who creates the front-end of a website or other application, or the part that users engage with to get to the information in the back-end. A back-end developer is someone who creates the storage and output capabilities of said information.

Let’s say that a client wanted a custom WordPress website developed for their business. The front-end developer would work on the website that is shown to visitors on the web, plus anything that the client would see and use in their day-to-day business. This includes the WordPress theme itself and any customizations needed to the WordPress admin panel / dashboard.

The back-end developer, on the other hand, would work on optimizing the database, customizing the WordPress software itself, and creating the plugins needed to create the overall functionality of the client website, whether it is a simple blog or an ecommerce store.

Skills

So what kind of skills does a front-end developer need versus a back-end developer? Both are required to do some heavy lifting in the programming department. But front-end developers need a better eye for user interface design and visual appeal than back-end developers.

While front-end developers are not always the actual designers for the user interface of a website or application, they do have to know how to make the user interface aesthetically pleasing as well as functional. They will likely work closely with a designer if they are not designing the website or application themselves.

Additional skills that front-end website developers will need beyond programming include the ability to wireframe a website layout and design, create website designs in PSD or take PSD designs and turn them into functional websites, and deploy the website to the customer or employer’s hosting company.

Back-end developers, on the other hand, have little to do with the design of a website or application. Their job is to focus on what makes everything work behind the scenes. Hence, if you are not interested in design, then back-end development should be your focus.

Additional back-end developers skills needed beyond programming include the ability to integrate the user interface created by front-end developers with the server side logic, creating reusable code and libraries for future use, application optimization for speed and scalability, design of data storage solutions, and implementation of data security.

If you know what type of developer you want to be, the best way to determine the skills you will need is to look at profiles of other freelancer developers or job listings for specific types of developers.

Browse several different freelancer profiles or job listings (preferably ones that are at the income rate you desire to make) so you can see the full range of skills you should be developing or highlighting when you approach customers or employers for work.

Programming Languages

Want to base your decision on whether you should be a front-end developer or back-end developer based on the programming languages you will need to be proficient in? Here’s what you need to know.

Front-end: There are only three front-end languages HTML, CSS, jQuery and Javascript.

Back-end developers need to be proficient in programming languages that render on the server side of a website or application. The most popular back-end programming languages are PHP, Ruby, Python, Ruby on Rails and Java. Others include .NET, C, and Perl. Back-end developers also need to proficient in working with databases like MySQL, Oracle, and SQL Server.

If you don’t have experience in any of these just yet, you may want to start by taking some beginner courses in a few different programming languages to see which ones you are most comfortable working with. Alternatively, you may want to determine what types of projects you would ultimately want to work on, then find out what would be necessary to know to work on them.

Education

Fortunately, there are lots of different ways to learn both front-end and back-end skills and programming languages. The route you take in education may depend on the type of employment you seek. If you want to work for a company full-time, you may want to browse job listings to see the requirements they have as some will require specific degrees from universities to apply.

If you want to be a freelancer or start your own company, you may be able to forgo the format university route and self-educate through online courses. So long as you can deliver proven, you do not need to show a degree to make a living. If you are starting completely from scratch, you may need to develop a few projects on your own for your portfolio to demonstrate your experience to your first couple of clients. A strong portfolio is especially important for front-end developers.

Earnings

What you will make as a developer will depend on a lot of factors. These include the following:

  • Whether you are a freelance developer, contractor, part time, or full time employee.
  • Your specialties as a developer — the programming languages you are most proficient in, the tools you are most familiar with, etc.
  • Whether you are able to interact directly with the customer, have project management skills, and are able to manage a team.
  • If you are a freelance developer or contractor, the network you use to offer your services through.
  • Where you live and where you work from (telecommute or in-house).
  • How much education you have in your specialty.
  • How much experience you have working in your field.
  • How long you have worked at a particular company as a part time or full time employee.

While there are averages you can expect in terms of salary, all of the above will factor in on whether your earnings are closer to the lower end or upper end of the echelon. Indeed.com, for example, shows the following as average earnings for specific types of full time back-end developers. Note that some of the related job titles cross over into front-end development for comparison.

You can compare these to averages for full time front-end developers. Note that some of the related job titles cross over into back-end development for comparison purposes.

As you can see, the salaries can vary dramatically based on your experience (noted by junior, lead, and senior titles) and based on your specialties. Specialties also have an effect on salary, as noted by the difference in salary between a senior Javascript web developer who outearns the senior front-end developer.

For freelancers and contractors, what you will earn will be affected by the network you market yourself through, your reviews and ratings on that network, and your competition. Here’s a quick look at what the top back-end developers are charging on networks like UpWork (formerly oDesk).

These networks appeal to customers who are looking for developers who meet their budgets, and they allow customers to find developers who charge anywhere from $10 per hour and to over $100 per hour. If you market yourself on these networks, you will have to compete with people across the gamut in terms of rates. Increasing what you charge on these networks will require you to demonstrate your skills through testing on the networks themselves, having a complete portfolio, and having great ratings and reviews.

Full Stack Developers

People who have skill in both front-end and back-end development are often referred to as full stack developers. In other words, they have a full range of skills that can be applied to the user interface and everything that makes it work in the background.

Some people consider a full stack developer not as good as a front-end or back-end developer, and often refer to the saying, “Jack of all trades, master of none.” But it’s also worth noting that the full phrase is “Jack of all trades, master of none, though oftentimes better than a master of one.”

As a developer, having both front-end and back-end proficiency means more opportunities. You will be able to apply to more contract, part time, or full time employment positions. Or, as a freelancer, you will be able to take on more projects without being limited to front-end only or back-end only.

From the customer or employer perspective, you will be able to understand projects as a whole — both how it needs to work for the user and how it needs to work in the background. You will give them one point of contact for all of their needs. And you will be able to support them when things go wrong on either side, making you even more valuable over the long term.

Demand for both front-end developers and back-end developers is continuously growing. Therefore, choosing either can help you create the career or business you have always wanted. Be sure to explore both worlds of development to determine which one is the best fit for you!

5 Reasons Why Swift is Perfect for Beginners

“I’m new to programming — what’s a good language for me to learn?”

So you’ve just joined the world of programming. You got your introductory crash course, learned the basics, and got enough of a taste to know you want to do this. Now there’s just one question: where to start?

If this sounds like you, don’t worry — you’re not alone. Every new programmer has to face this question, and all too often the “right” choice isn’t right for what you want to get out of programming. If you’re new to programming and you want a language that’ll get you fast results, I recommend trying out Apple’s Swift language. Today, I’m going to give you five reasons why I think Swift is great for new programmers. Ready? Let’s get –

Hold on, hold on. Just a quick disclaimer before we start. There’s a lot of fame-and-fortune-related reasons to pursue Swift. Maybe you’re interested in creating the next phenomenon that takes the App store by storm. Maybe you’re interested in following in the footsteps of apps like Getty Images, Yahoo! Weather, or LinkedIn, all of which were created with Swift. Maybe you just want to get in on that sleek, smooth Apple aesthetic.

All of those are all great reasons to learn Swift, but that’s not what I want to talk about. I want to focus on why Swift isn’t just a great language, but a great language for someone who is learning how to code. Here’s five reasons why Swift will be a great fit for your programmer origin story, starting with:

1. Swift Was Designed to Remove Complexity

Created as a (long overdue) replacement for Apple’s Objective C, Swift is a coding language for the people, by the people. Okay, maybe it’s not quite there yet, but it is a system that was made with simplicity and efficiency in mind.

Its syntax was designed to close the gap between the human mind and the computer operations, getting rid of a lot of the moving parts that most other languages need to get off the ground.

Imagine, for instance, that you were coding with something from the C family. Before you could get the code to compile into anything remotely resembling a functional app, you’d need to master everything from functionals to optional chaining. Other languages might have you spend hours working the finer points of headers and compilers, and that’s all before you even feel like you’re getting started. The thing about programming is that you want to build something. So when you’re starting out with programming languages, it’s often a good idea to pick something that you can pick up easily, learn quickly, and build fast.

The thing about programming is that you want to build something. So when you’re starting out with programming languages, it’s often a good idea to pick something that you can pick up easily, learn quickly, and build fast.

2. Fewer Special Characters

If you glance at anything written in Objective-C, Swift’s predecessor, you’re bound to notice one thing all over the place: semicolons. Semicolons at the end of every single line. It’s a veritable flood of semicolons, a plague of semicolons. Just take a look:

That’s the way that many of the older coding languages work. Every line break needs a semicolon, except for the ones that need brackets, or square brackets, or curly brackets or who even knows anymore! And if you miss even a single one? Disaster strikes, and you get to spend the next three hours combing through your code. Swift does away with most of that nonsense, letting you focus on getting the computer to understand what you want it to do. (AKA: the important stuff.)

3. Try It in the Playground First

One of Swift’s greatest “no pressure” innovations is the inclusion of a playground feature to Xcode, the main development tool for the language. Here’s the basic idea: rather than throwing you into the deep end with a full-fledged app, Swift gives you a safe space where you can simulate the apps or programs you’re creating.

This makes an enormous difference in how you can play around with Swift. Go ahead, try out that gut instinct and see if it works. It doesn’t? No sweat, just try another tweak and see if that does the trick. The sandbox model is there to get you working quickly, and to eliminate the ever-present fear of, “Am I about to break everything?” Whether you’re taking the first tentative steps or trying out a hare-brained scheme, the Swift playground’s got your back.

Which leads us to…

4. Swift Gets You (Nearly) Instant Gratification

Think about the last time you were learning a new language. Or mastering a new dish. Or picking up any new skill. Now imagine trying out something new… and then not being able to see if you got it right. Or, even worse, not being sure where in a series of steps you went wrong. Doesn’t sound like a great learning environment, does it?

A lot of programming languages take time to bear fruits, or force you to jump through all sorts of hoops just to get your code to compile.

A lot of programming languages take time to bear fruits, or force you to jump through all sorts of hoops just to get your code to compile. But Swift was built with a sense of immediacy as one of its guiding principles. The playground lets you see what you’re building with just the touch of a button, and, even as a novice, you can put together a simple app in just a matter of days. You get concrete results, see your work in action, and get to hone your skills at a much faster pace.

5. Swift is About to Go Open Source

Earlier this year, Apple made a big announcement: Swift is will soon be made open source. That may sound scary, but it’s actually a really good thing for programmers everywhere. Long story short, it means that the source code for the language will be made public, contributions from the community will be accepted, and the compiler will be available for systems outside of the Apple family. Translation: the language is about to become much more open, much more exciting, and available to a lot more people.

This means that there’s no time like the present to jump on board the Swift train. The community that surrounds the language is about to grow at an exponential rate. There’s about to be many more people coding in Swift, writing about it, teaching it, and more resources dedicated to it! It really is about to become a coding language for the people, by the people, and you want to make sure that you’re there to catch the wave when it does.