Posts

What is Web Security?

Key Takeaways

Web security is protecting your website from hackers before it gets broken into.

If you’re a web security expert, you have the following skills:

  • You know how to code.
  • Can review your code for vulnerabilities.
  • You help fix the vulnerabilities you find.

How to Learn Web Security Today

  1. Read about OWASP. It stands for Open Web Application Security Project. They’re an international nonprofit that puts out lots of documentation, events, news, and web security projects. This is in an effort to improve software security across the world. Start here: https://www.owasp.org/index.php/Main_Page (15 minutes).
  2. Read the OWASP Top 10 Vulnerabilities.  Here’s how to succeed in 5 minutes: browse through the list, and read it aloud. Think of it as jumping in over your head! This will plant a seed for getting you on the right path. Start here: https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet (5 minutes).
  3. One Month Web Security — By the end of One Month Web Security, you will be able to review your own applications for security issues and ensure the code is properly hardened against malicious attacks. You will also be able to design new applications with security in mind. This will significantly lower the risk and cost associated with deploying new applications.

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).  There you can see the full range of skills. This is what 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. 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. This way your portfolio can 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.
  • The amount of experience you have working in your field.
  • How long you have worked at a particular company as a part time or full time employee.

Salary

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. 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. 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. 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. This makes 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!

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?

Becoming a translator

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.

Start learning now!

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

Post

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
  • It is made up of requests and responses
  • Its’ 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 , ways of solving the same problem. But rather than that being a weakness of Ruby, the flexibility of the language is an incredible strength 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 need to keep going?

Flexibility=Creativity

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 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. This is 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. It is also 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?
  • Which language should I use?
  • Is there a specific kind of computer I should 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 building blocks of programming that you’re taught in college are the internals of the computer. 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. It used to be that being a programmer without training in it was unattainable. 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.

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