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.

Why Should You Incorporate Your Startup In Delaware?

Startup Series: Why Delaware?

Why should you incorporate your startup in Delaware, even if you’ve never been there?*

A whole lot of companies in the US are incorporated in Delaware, even if the company doesn’t actually exist there. One Month, for example, is incorporated in Delaware, even though we’re headquartered in New York (and we’ve never been to Delaware)!

The reason? There’s a body of law in Delaware where many court cases have already been tried, so companies and potential investors have more certainty about how different legal disputes will turn out. It’s riskier to incorporate your startup in a state where the outcomes for legal problems don’t have any legal precedent, and it’s unclear what would happen if a case were to go to court.

For investors, it’s also more attractive for them if they know you’re incorporated in Delaware, because this gives them more certainty. If your business has a legal question and it needs to be figured out in the court system, investors prefer the certainty of knowing that previous cases have established precedent (known as case law) in this state.

*Of course, for questions specific to your particular situation, it’s best to seek the advice of an attorney or accountant.

Key Takeaways:

  • Ideally, you’ll be incorporated in Delaware (you don’t have to live there to incorporate there) because many of the laws and cases have already been figured out
  • The steps to incorporating a business are fairly simple, hence there are people who can do it for you.
  • If you try to do it the manual way, it can be more complicated, but still do-able.

More Links:

Startups + Fundraising Series:

The Newbie Guide to Ethical Hacking

I hack websites. I’ve been doing it for a long time, across various industries, tech stacks, and programming languages. When I tell people what I do, especially those in the tech community, they often ask how I started and how can they learn more. So today, I’m going to give you a quick intro of the tools and tricks to get started with web hacking. The best way to start is to dive into the details and start using some hacking tools.

Here’s how I recommend starting:

  1. Understand the tools of the trade
  2. Understand common attacks and defenses
  3. Practice on test sites

Since we will be focusing on web hacking, a basic understanding and/or refresher may be useful. If so, check out my post on, “Understanding HTTP Basics,” then come back. Don’t worry, its pretty simple but lays the groundwork for later.

Tools of the Trade

I think anyone trying to get involved with web app security needs to know is how to use the most common web hacking tool. Most noteworthy is the proxy. Proxies let you intercept HTTP requests and responses. This allows you to fully understand how a website works and lets you uncover security issues. I wrote a post, “Web hacking Tools: Proxies,” which walks through installing and using the most common web proxy used by security people, Burp.

After you spend some time using a web proxy, it’s pretty eye-opening to see how some of your favorite sites work, under the covers at the HTTP layer. This is also super-useful during normal development to debug and troubleshoot web application problems.

Common Attacks

Next, you need to gain an understanding of the common attacks hackers use to break-in, so you can test your sites and code for these vulnerabilities. You should check out my article on the iCloud attack here. OWASP provides a list of the top 10 attacks. This is a great place to start, although I should warn you that some of them get into the weed fairly quickly. By understanding those you can review sites you build to make sure they are protected.

Practice makes perfect

Armed with your first hacking tool, the web proxy, and an understanding of common attacks, it’s time to put your newfound knowledge to the test with a few hacking challenges. There are great sites out there where you can learn and try out hacking techniques without being worried about breaking the law. These are a few of my favorites:

After you brush up on your skills, you can also take it to the next level with a few public bug bounty programs. These programs are great because they pay for you finding vulnerabilities in public websites, such as Google, Facebook, and Paypal. Make sure you read all the rules before starting:

Also, if you don’t want to deal with these companies directly, you can also join a bug bounty program through a dedicated bug bounty company. These work with various businesses to test security using a pool of freelance hackers, including you! These two are the best:

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.

Learn How to Launch An MVP In One Minute

Key Takeaways

A Minimum Viable Product centers upon the idea that you should release a new product ASAP. Don’t spend nine months building all the features. Instead, build the most important features — just enough to learn whether or not people even want the thing you’re making.

Repeat after me: an MVP means getting the most learning for the lowest amount of effort. Ask yourself, “How can I get this product in front of people as quickly as possible?”

Example of Minimum Viable Product in action

  • Dropbox started as an MVP
  • Here at One Month, we use Launchrock to build a landing pages, and to collect email addresses for classes that aren’t yet in development. This helps us learn which classes are most in demand.

How to Learn to Build an MVP Today

  1. Steve Blank, and Eric Reis: Read about the experts and follow them on Twitter (5 minutes).
  2. Data Drive Products Now! (slideshow): Check out this cool case study from on Etsy developer Dan McKinley (12 minutes).

Additional Resources

If You’re Not Embarrassed By Your Startup, You Launched Too Late

“If you’re not embarrassed by the first version of your product, you’ve launched too late.” — Reid Hoffman

If your startup is successful, no one will remember how ugly your product looked the day you launched. (And if it’s not successful, no one will care.)

When we think about successful companies like Google, Facebook, and Twitter, we tend to forget the modest beginnings from which they came. As Paul Graham recently wrote, “Think of some successful startups. How many of their launches do you remember?”

In celebration of modest beginnings, here’s a dose of reality: I recently came across the landing pages of some of the most successful companies we know. This is something everyone should see.

The moral of the story: don’t name your company BackRub. Also, don’t worry about making something pretty, worry about making something people love. As Reid Hoffman (the founder of LinkedIn) once said, “If you are not embarrassed by the first version of your product, you’ve launched too late.”

It’s easy to say “have a growth mindset,” and “follow lean startup principles.” It’s a lot harder in reality, when you have to launch quickly, and put out versions of your product that feel unfinished, raw, or even ugly. Take a look at the startups below, and how they launched their first product — and maybe you can launch a little earlier. Or a lot earlier.

(Credit goes to Phil Pickering for finding these.)

Twitter’s first landing page:

Early Facebook screenshot:

Early Google homepage (from 1997):

The precursor to Google, BackRub:

An even earlier Google homepage:

Yahoo!’s homepage in 1994:

Early tumblr dashboard screenshot:

Early Amazon homepage screenshot:

Apple circa 1997:

AuctionWeb before it became eBay:

Burbn (a Foursquare clone) before it pivoted to… Instagram:

The first ever prototype of Foursquare (shown at SXSW in 2009):

Reid Hoffman’s original LinkedIn:

And finally… Reddit (some things never change):

What stands out to you? How would you have designed things differently?

It’s easy to think that you need to have a great design and get everything polished before you release it to the world. In reality, you should launch things as soon as you can, as quickly as you can, to get validated learning. The Lean Startup talks about this as validated learning — getting immediate feedback from users as to what they actually want, not assuming you know all the answers.

How can you launch a beta version earlier? Why is getting feedback on a somewhat-shitty design more valuable than perfecting a design that no one wants? Post your thoughts in the comments below.

Creative Email Campaigns: Why an Online Education Company Sent an Email About Football

Can a coding company send a relevant email about football? Or will we just spam our friends and students?

Every week, over team brainstorms how to reach out to people in clever, funny, and interesting ways. We don’t want to clog up your email inbox (annoying!) or send messages that just push sales (boring). Our aim is to inspire, delight — and just maybe deliver something unexpected in your inbox. Our company is focused on accelerated learning, experimentation, and a little bit of quirkiness.

Last week, our team had to think about how to connect over football. (At least American football, because the Super Bowl was this weekend — some of us are soccer fans, or what the rest of the world knows as “football.”)

“I don’t understand football, honestly,” I admitted sheepishly to my colleague.

He laughed — “Me neither!”

“Wait,” I said. “Can we go with that?”

What if I sent an email about football and asked people to teach me what they knew? We crafted an email to reach out to people and sent the following:

What happened next was pretty cool. Over 200 people wrote back to me, and I spent Saturday morning hanging out and writing replies back to folks.

A lot of people had REALLY funny things to say, and I have to say, you taught me a lot about football. Moreover, I got to know several hundred faces in the One Month community and get to know a lot about who reads our blog, what they’re interested in learning, and — of course — what they know about football.

The thing is, we’re always learning here at One Month, and when there’s something we don’t know much about (like football), we want to learn from each of you. Thanks for taking the time to write in and teach us. It was a great way to learn about y’all.

Here are some of the highlights of what you shared and taught us about football:

“Football to me is all about memories, nostalgia and loyalty. Just like a group of developers get together and nerding out over the latest grunt or rails package, football is a common thread that we can all get behind to rally for — regardless of race, religion or any other preference.” — Andrew

“It’s like a new episode of a TV show every Sunday and Monday, except it’s a very real business with very real people.” — Shafiq

“The Super Bowl is like Thanksgiving in February: Your family wants to do a big dinner and bring everyone home for the weekend while you secretly wish you were drunk with friends watching the game without having to talk about what you’re thankful for.” — Saif

“I felt similarly to you, until I was watching the Ravens take on the 49ers in the 2013 Super Bowl. Suddenly, I saw the strategy, the patterns, how each team used each play to advance further along the board. Each player had a role, a specific skillset and position. The coach and quarterback coordinate to take control of the game. The game is even more complex, as each position is dynamic with injuries and individual player performance. In order to win, you must keep track of a strategy that is constantly changing in response to the other team’s moves, players, and the end objective to move along the board and win the game. I’m now a fantasy football addict.” — Melinda

“It’s a national ‘Sickie’ day in the UK on Monday for those that stay up to watch.” — Howard

“You mean the Katy Perry concert? The show opened and closed by some soccer thing?” — John

“Loving a football team is like working at a company. So when your company/team does well you feel like you did well. Even if all you did was cheer in the stands or write emails asking about football, you share the glory of your team’s success.” — Taylor

“It may not look like it, but there is real grace and skill behind it, both individually and on the field and as a team. The things these players execute are as athletic and sometimes as elegant as figure skaters or gymnasts, even on the Offensive or Defensive lines (the pile up).”

“They are trying to open up or close down gaps where someone might run or throw the ball, and like sumo wrestlers, they push against each other to do so, leveraging their bodies to knock the opposing blocker down. The game is also deeply rooted in American history. Listen to this week’s Radiolab for the full version, but it does come out of a tradition where guys had to show they were tough…because previous generations of men had The Civil War and wars in the west against native Americans to really show their toughness. Teddy Roosevelt had to intervene to make the game less brutal (people were dying on the field playing the game)…the biggest thing to come out of that era was the forward pass.” — Ian

“Every play is an opportunity for strategy. It’s like playing a more complicated version of rock, paper, scissors. Whatever both players just picked will affect each player’s decision in the next round. And both anticipate the other side’s anticipation of their own behavior, leading to a sort of strategy arms race.” — Peter

“I’ll probably get punched for saying this, but one of my favorite things about football is honestly the food and beer/whiskey, then onto friends and family and lastly it’s the game.” — Brandon

“At a basic level movies are great because they transport you to a different world (the willing suspension of disbelief). Football fans experience something similar; when your team is on the field nothing else matters, you’re in a different world.” — Michael

And if that doesn’t convince you, maybe these videos will:

In addition to all of the helpful commentary, we also got a bunch of links, videos, and references. Radiolab did an exceptional piece on American Football, and the YouTube videos we got were hilarious. Here’s a few of the best:

Andy Griffith explaining football in this 1953 commentary:

Bad British NFL Commentary:

And a Guide to American Football:

What about the haters?

As Taylor Swift says, “Haters gonna hate, hate, hate …”

You can’t please everyone. As a marketer and a long-time communicator, I’ve learned this through trial and error. You simply cannot please everyone. One of my favorite branders and designers says that it’s better to have a brand that’s both loved (and hated) than to have something that people feel indifferent about.

With emails — the only way you can have zero unsubscribes is if you have no one on your email list, or if you never send any emails at all. We track all of our open rates, subscribes, engagements, and unsubscribes and we learn from every campaign. (The highest opened email of all of our blog campaigns so far has been the “Drunk Mode” video release.)

Everyone has different opinions, and for the football email we got a couple of replies (just a few, thankfully) that sounded like someone got out of bed on the wrong day. (In that case, I just crank out the T-Swift and keep going).

In one instance, someone said:

“Who the *bleep* is Sarah?”

Right. So, hey y’all. I’m Sarah. I joined the One Month team to help them with creative writing, copywriting, marketing, and content creation. You can see all the awesome people on the One Month team on our about page or check out the recent talk Mattan and I did on content marketing last week in our free webinar (info below). I’ve been writing a few blog posts and I’ll be writing new essays on accelerated learning, growth, and ideas here on the blog. (If you want us to cover anything specific, or you have a question, just leave a note in the comments or reach out to me by email, happy to chat).

Another person more politely asked: what’s the point of this email?

Emailing is a conversation — it’s not just blasting information and shouting at people. If you use it creatively, it can be a way to get to know more of the faces at One Month, including many of our students, friends, and alumni.

Out of 200+ responses, we had three grumps, hundreds of awesome explanations, and a lot of conversation. As a marketer — which to me, means conversationalist, you’ve got to hold space for dozens of conversations with tons of customers, students, and people engaging with your brand. How do they interact with you? What’s the overall tone and reaction?

Several people cheers us for not selling anything —

“Great (and engaging) email. Way to not sell anything, and not be offering anything, but still be interesting. Well done!” — Josh

“I admire your willingness to dive in and learn about this wonderfully complex game. I hope that you received some clever tutorials.” — Jay

In addition, being able to explain a game — a process, a strategy, a theory, a team — is much more similar to understanding coding and creation strategy than you might expect. Here at One Month, we think learning new things is fun, and we might continue to surprise you every now and then — with new classes, interests, ideas, and questions.

Or email campaigns.

In all the responses I got, I learned so much from everyone, which resonates with our own spirit of wanting to learn, well, everything. Lee is practicing to become a world-champion DJ, and Mattan is teaching himself to play piano. Chris and Mattan take improv classes and I just signed up for my first singing lesson. What can I say? We’re nerds who like accelerated learning.

Thanks to everyone who played along! Hope you enjoyed the sport, the entertainment, and the conversations. We had a blast doing this.

We’re constantly experimenting with what we send people — developing a style and then testing out new things to see what we can tweak, improve, and better. If you want to learn more about content marketing and how to communicate in a way that’s different, unique, and fun — check out our content marketing free webinar or our upcoming class launching the last week of February.

In the end, the highest email open rates come from creative emails.

In our free webinar, Mattan and I chat about our top ten quick-wins for making content that actually gets shared. We break down the definition of content marketing and share ten strategies for engaging with your audience in a more meaningful way. In our upcoming class, we’ll be breaking down what content marketing is, who’s doing it really well, and how to construct email campaigns, experiments, and incentives so you can grow your own business, brand, or project.

And last but not least, the email winners:

Also, I have to announce the winner!

We had so many creative replies. Congrats to Craig Morrison for having the funniest response. You made me laugh out loud.

Here’s what Craig wrote:

The best part about football is the singularity of the sport.

It’s just you, versus your opponent.

You’re both surrounded by thousands of people, staring down at you as you play, all intensely watching your every move.

It’s intoxicating, knowing those players and the pressure they’re under.

Seeing them play what is much more a mental sport than any kind of physical one.

The sweat on your hands, the racquet slipping from your grip as you swing.

The pain in your knees you barely notice as you sprint across the court to take a last ditch effort at hitting the ball back to your opponent.

Wait that’s Tennis, football sucks.

PS: Don’t get me started on football, with all those different clubs and the tiny white balls. It’s barely even a sport.

And congrats to the following people who also sent amazing emails:

Also, bonus congratulations to Melinda Pandiangan for your awesome storytelling and sharing that football is about patterns, strategy, and complexity. Scott Johns explained that that football strategy is more like game theory than crushing humans, Caroline Bagby for sharing her evolution from not caring to learning all about the game to becoming a marketer for the Patriots (and subsequently learning all about the game), Jeff Charleston for giving some insight into the game (having played a super bowl himself!), and Yonathan Ayenew for reminding me to stick to my guns and read a book if that’s what I want to do next. You all rock!

What’s the best email campaign you’ve ever received? What do you love getting in your inbox?

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.