I was scrolling down my Facebook feed and realized that almost everything on the page was information that was obviously sponsored and that I definitely hadn’t “liked” (or wanted). Measurements are in square units (couldn’t figure out what type of units in photoshop). 

I was scrolling down my Facebook feed and realized that almost everything on the page was information that was obviously sponsored and that I definitely hadn’t “liked” (or wanted). Measurements are in square units (couldn’t figure out what type of units in photoshop). 

“Pride” or “Wanting the thing you make to be freaking awesome.”

I was at dinner last night and an interesting thing happened.  The restaurant was called “Hash House A Go-Go” (in the Gold Coast) and it was awesome.

My girlfriend Marissa ordered a sandwich that came with a side of potatoes. As the waitress put the plate down, she noticed a problem. “I’m so sorry, there was supposed to be pesto sauce on your side of potatoes – want me to take it back?” she asked. “No, it’s totally fine,” Marissa replied, and we began our meal.

Five minutes later, a different waitress stopped by the table and said “I heard your potatoes came without sauce, would you like me to take them back to the chef?” Again, Marissa said, “they’re really delicious anyway, there’s no need to bother the chef with it.”

Another five minute passed and the waitress came back again. She put down a plate with a fresh side of potatoes. “The chef insisted that you try it with the sauce,” she said, smiling.

The Chef had made a mistake, but his customer hadn’t minded. The food was delicious anyway. But the chef wasn’t satisfied because his customer didn’t get the experience he had intended. He took pride in what he was doing and he knew that with the sauce, the potatoes would be freaking awesome.

We should all take so much pride in what we’re doing that even when our customers are satisfied, we are not. We should all want our products to be freaking awesome.

A call to action does not a button make

I was on Gmail today and noticed this button:

Which button, you ask? Great question, Mom*.  Because there are so many buttons and calls to action on this page.  This button:

Which one? You still can’t tell? The one in between the 1 and my face. the “+ Share” button. I wonder how many people click on this and it made me think…Just because there’s a button on the page doesn’t mean I’m in the mindset to click on it. Sure, it’s not bright red like the “1” next to it. But still, how many times are you in Gmail and thinking “you know, I really want to share something publicly on Google+ right now.” It’s an interesting question and I think the answer could change over time. But compare it to this:

Sure there are lots to do on this page, I can like stuff and run ads and find new friends, but right in the middle of the thing it’s asking me “What’s on your mind?”

Now, of course one of Facebook’s core functions at this point is to get people to share with each other to keep the newsfeed populated, so it makes sense that almost every single call to action on this page aims to meet that goal. Like = put it in my friends’ newsfeed; Comment = put in my friends’ newsfeed; Share = put it in my friends’ newsfeed. 

Email is almost definitionally intended to be private. The expectation is that it’s as private as a phone call or even a conference call (leave aside for a second the notion that it’s also forwardable, so the expectation of privacy isn’t actually the same as a phone call). The opposite of an email is a billboard. It’s a speech. It’s twitter.

My observation is this — people are in a very specific mindset when checking their email. It’s a mindset of sharing with a very small group of people, with the expectation that it’s going to be mostly private. There is probably a place for Google+ integration, but a “Share+” button at the top of my email where the default is for the message to be shared completely publicly is probably not it.

I’d be curious how often that button gets clicked relative to the people who are active on Google+.  My guess is that while in their private email, most people aren’t in the mindset to post something publicly. But maybe I’m weird…What do you think (about the post, not about me being weird…)?

*I’m assuming the only person who actually reads this is my mom.

Determinate Optimism & Startups / Life


Here is an essay version of my class notes from Class 13 of CS183: Startup. Errors and omissions are mine. Credit for good stuff is Peter’s entirely.

Class 13 Notes Essay— You Are Not A Lottery Ticket

I. The Question of Luck

A. Nature of the Problem

The biggest philosophical question underlying startups is how much luck is involved when they succeed. As important as the luck vs. skill question is, however, it’s very hard to get a good handle on. Statistical tools are meaningless if you have a sample size of one. It would be great if you could run experiments. Start Facebook 1,000 times under identical conditions. If it works 1,000 out of 1,000 times, you’d conclude it was skill. If it worked just 1 time, you’d conclude it was just luck. But obviously these experiments are impossible.

The first cut at the luck vs. skill question is thus almost just a bias that one can have. Some people gravitate toward explaining things as lucky. Others are inclined to find a greater degree of skill. It depends on which narrative you buy. The internal narrative is that talented people got together, worked hard, and made things work. The external narrative chalks things up to right place, right time. You can change your mind about all this, but it’s tough to have a really principled, well-reasoned view on way or the other.

Read More

(Source: blakemasters)

Romney Etch-a-Sketch comparison drives up Etch-a-Sketch maker Ohio Art Company stock 140%

Romney Etch-a-Sketch comparison drives up Etch-a-Sketch maker Ohio Art Company stock 140%

Why I Moved To Chicago To Start My Company

A debate is beginning to heat up over Trevor Gilbert’s Post about the Chicago startup community, beginning with Matt Moog’s response.  When I first read Trevor’s article, I got defensive for Chicago. Then I read Matt’s response and got defensive for Trevor.  I think there is a fundamental disconnect that I may be able to fill in here. Why am I someone who might be able to bridge this gap? Because I have worked for a “Hot Venture Backed Startup” that was a big, ambitious idea first, and would figure out its business second.  Then, I moved to Chicago.

The fundamental argument Trevor makes, which I happen to agree with, is that great product people and programmers are attracted to working at hot startups with big, ambitious ideas. To some degree, it’s the difference between starting an “idea” and a “real business” (interestingly, entrepreneurs working on one or the other type of company always seem to think the grass is greener).  I don’t want to put words in his mouth, but Trevor’s logic goes that wildly ambitious ideas — which may not even have revenue models — attract the best talent, and in an era where talent is already in short supply, how can Chicago hope to compete without funding crazy ideas?  I know I’m simplifying here, Trevor, but not only do I think this is the core thesis of your argument, but I also think that it’s got some merit, so bear with me.

How do wildly ambitious ideas tend to be funded?  If we look back to very near history, they’re funded by rich people who know that if the crazy company can actually manage to solve the problem at hand, it’s going to be a massive success. Sean Parker saw the value in the problem Facebook was solving extraordinarily early on. Google was dealing with a problem of search — largely considered to be solved — and I’m sure its investors realized that Google had a key insight and if they could pull it off, it was going to be a massive company.  If I had to guess, Eric Lefkofsky and Brad Keywell saw that The Point was doing something nobody else was doing — something fundamentally different. They saw value in the problem The Point was trying to solve. Eventually, The Point did solve a problem, for an enormous market, and I don’t think they should have to apologize for monetizing what was originally a really, really crazy idea.

While entrepreneurship in Chicago is as old as the city — which is to say, it’s pretty old — the digital entrepreneurship scene is in many ways a startup itself. New York City had Gilt Group (a “real” business, with, like, revenues and stuff), which paved the way for “ideas” like Four Square, Hot Potato, Turntable.fm, GroupMe, and others. It’s not that these ideas had no idea how they were going to monetize — but they chose to spend their limited resources focusing on building awesome products, not on monetizing immediately. Chicago is just coming out of that first period where more traditional businesses make early entrepreneurs wealthy. There have been some amazing startups founded by brilliant, technology-centric, serial entrepreneurs, many of them named by Matt Moog in his response to Trevor’s article. 

Maybe wildly crazy, massively ambitious startups are still fairly sparse in Chicago.  The story here is not what isn’t here, but what I, as a technologist, would call the “back-end” that’s being built out right now. The community is beginning to coalesce, and some of the early serial entrepreneurs have made some real money.  We have a place that looks a lot like New York did five years ago. Over the past five years New York has built itself into a technology powerhouse. It hasn’t been easy — it’s taken political support, investor support, and community support. They all happened and the people who made that happen should be extremely proud of the “back-end” they created which allowed the entrepreneurship “front-end” reach the next level.

So it is with this backdrop that I asked myself — what is more ambitious for a technology entrepreneur than being part of the technological renaissance in an amazing city?  We’re not talking about the middle of nowhere, we’re talking about the third biggest city in the United States.  The home of minds from Abraham Lincoln to Barack Obama, neither of whom was born here. Like me, they actively chose this city (that may be the extent of what we have in common). 

In the coming years, when entrepreneurs are used to dropping in at 1871 to share ideas and prolific entrepreneurs, technologists, and investors are thrust into the spotlight through event platforms such as Technori and Entrepreneurs Unpluggd, we will look back and see that there are lots of big, ambitious companies in Chicago. They might not even know exactly how they’ll make money! But just as it didn’t happen overnight in New York, it hasn’t happened overnight here in Chicago either. The story here isn’t what isn’t in Chicago. At best, it’s what isn’t in Chicago yet.  And as someone constantly in pursuit of massively ambitious ideas, being part of Chicago’s digital entrepreneurship renaissance makes it the best city on earth to be a technology entrepreneur.

Learning to Program: lesson 4

Okay, now that we’ve finished lesson 3, we’re ready to build our first text-based game. This is going to be pretty simple / boring because it’s just going to run in the command line (i.e., the Terminal window). But it will be a game nonetheless…

I couldn’t find a really simple example of a command-line game for Ruby so I came up with my own. It’s called “Math Wars”. We’ll give the user a series of math problems and keep track of how many they get right and wrong. Each math problem will be either addition, subtraction and multiplication.  When the user gets 10 problems right, the game will be over and we’ll report back a score.

So let’s start with what’s called an “algorithm.” It’s basically a set of instructions on what our program will do, without regard for writing the exact code we’ll need. Here’s my algorithm:

Print “Welcome to Math Wars!”
var currentNumberRight = 0; #this will be an integer
var currentNumberWrong = 0; #this will be an integer also 

#create a loop that continually asks questions 
do the following until the currentNumberRight >= 10:
var firstNumber = Random Number between 0 and 9
var secondNumber = Random Number between 0 and 9
var randomNumber = Random Number between 1 and 3
var operator; #declare the operator variable, which will be random 

if (randomNumber == 1) then
operator = “+”
else if (randomNumber == 2) then
operator = “-“
operator = “*” 

var correctAnswer; #create a variable for the correct answer  

if (operator == “+”) then
 correctAnswer = firstNumber + secondNumber
else if (operator == “-“) then 
correctAnswer = firstNumber - secondNumber
else if (operator == “*”) then 
correctAnswer = firstNumber * secondNumber

Print firstNumber + operator + secondNumber;
var userAnswer = answer inputted by the user

if (userAnswer == correctAnswer) then
print “you’re right!”
currentNumberRight = currentNumberRight + 1;
print “sorry, the right answer was ” + correctAnswer
currentNumberWrong = currentNumberWrong + 1;

 if (currentNumberRight == 10) then
print “you win!”
var totalQuestions = currentNumberRight + currentNumberWrong
var userPercentage = currentNumberRight / totalQuestions
print “your percentage right was: ” + userPercentage

Okay, Adam — get going! One hint — ruby has a function to generate a random variable. Take a look here to learn about it.

Learning to Program: lesson 3

Okay, now we’ve learned a bit about how to create a simple program in Ruby (in lesson 2), there are two more concepts we have to learn before we can create an interesting program (perhaps we’ll make a game, Adam!)

Those two concepts are (1) Logical Constructors and (2) Loops

Logical Constructors — these are if / then / else statements. Here is a good tutorial to understand them: Ruby If Then Else. In that markup, I commented on things like <= and != these are called “operators.” Here is some info about them: “Ruby Operators

Loops — this is the first time that what we’ve learned deviates significantly from high school math. It’s not more complicated, but it’s not something you’ll immediately recognize. This is a pretty good tutorial on loops in ruby: “Ruby Loops.”

Okay now I think we’re ready to build a really simple game in Ruby. So check out lesson 4.

Learning to Program: lesson 2

In lesson 1, we learned how to use ruby in the command line, how to save a bunch of commands to a file, and how to execute that file from the command line. Now we’ll learn about functions. First, “functions” are the same as “methods” literally just two names for the same thing.  We’re going to learn about functions first conceptually and then in ruby:
  1. Functions conceptually. Before we learn how to create our own functions, we need to learn how to understand what they are. Check out “What is a function?"  This should remind us what functions are in math. Programming functions are essentially the same thing, but they use less math-y language and language that’s a little easier to read.  So a function to print someone’s name might, conceptually, look like: "WriteName(myName)" and when you use it, you’d say "WriteName(matt)" and it would output "matt".
  2. Okay this conceptual stuff is nice but now let’s write a function in Ruby. A pretty good tutorial on this is “First Ruby Program.”

Okay now that we understand functions I want to step back for a second and talk about variables, variable scope, and variable types.  You’ve actually already used these so far but we didn’t define them:

  1. Variables — every time we named a value, e.g., “cost” or “mpg” in the example above, we are doing what’s called “declaring a variable.”  The value we assign to that variable is stored until we need it again. We only need to declare variables once.  
  2.  Variable Scope — we’re going to worry about this later because i can’t find a good tutorial in the Ruby language that doesn’t assume more knowledge than we’ve established.
  3. Variable Types — in order to understand this, we have to step away from Ruby for a second. Then we’ll come back to it. First, here is what variable types are in another language (Python instead of Ruby). Only read the stuff I’ve put in boxes, otherwise it might get a bit confusing: Python Variable Types

So now we’ve learned what functions are, how to pass values to them, and about some different variable types like Int, Float, and String. Some programming languages make you decide what type a variable is going to be from the beginning. This can be annoying because what if you don’t know whether you’ll want a string or an integer? However, for learning purposes it’s kind of annoying because some functions may require that a variable be of a certain type. For instance, what if you try to find the square root of a variable and it turned out to be a string. You’ll get a big fat error. So even thought Ruby doesn’t require us to define the type of variable, we want to make sure we understand what the different types are so we don’t make a mistake later.  There are some other variable types that we’ll consider later, but for now, Ints, Floats, and Strings will be fine. 

One last thing about variables before we move on. Just like we think about a variable’s type, there is also a concept called the variable’s scope. This isn’t important conceptually yet, but it might make you confused if you see a variable written down that has a certain scope. So far we defined our variable simply by giving it a name. But we can also define a variable’s scope by putting a symbol in front of it (I’ve only ever seen this in Ruby, other languages don’t do this). Here are some examples:

We’re not going to cover variable scope quite yet, but it will be important to understand later, and I don’t want you to be confused when you see these different symbols. It still means you’re referring to a variable, but it changes some of the qualities of the variable — like which functions can see the value of the variable.  Point is — for now, just realize that when you see any of those symbols before a variable name, it means we’re referring to a variable.

Learning to Program: lesson 1

I’m creating this subgroup of blog posts to help my friend Adam learn how to program. I’ve decided to teach him using Ruby. Here’s why — my first instinct was to start out teaching him HTML, move on to Javascript, then to backend databases. The problem is that if you want to get anywhere beyond rote memorization, you have to understand objects. Even thought HTML is a tag-based language, as soon as you start accessing it via javascript, you need to think in terms of objects, not tags.

For example, we built a simple HTML form and I wanted to use javascript to pop up the value that had been entered in the “First Name” field. We started using document.getElementById(“firstname”) and I realized that without the context of object-oriented programming, it’s extremely difficult to explain navigating different elements in the document tree and their properties (e.g., “value” or “class”).  Since he’s ultimately going to have to understand object-oriented programming later in order to do the back-end development properly (especially in something like Ruby on Rails), I thought it made sense to start out teaching him about objects using the terminal in Ruby. 

It had, by the way, occurred to me to teach him object oriented programming using Javascript. It’s much more likely that he’ll use Javascript when making his first webpages than Ruby. However, it seems silly to teach him how to create a class in javascript when in reality he won’t be doing that type of coding in Javascript. With the exception of Node.js. However, Node isn’t quite there yet in terms of accessibility to new programmers, so I decided to stick with Ruby for o-o programming, and then translating the concepts of objects, loops, etc into javascript later. My hope is that this will reinforce the idea that the abstract concepts stay the same regardless of syntax (i.e., “programming language”). 

A side goal I have is not to reinvent the wheel. So instead, I’m trying to find the best tutorials from around the web and make comments on them as necessary. I’m not spending a ton of time doing this, just doing Google searches to find an adequate tutorial to teach the specific concept I think he needs to learn. I’d prefer for my focus to be on structuring the lessons as opposed to generating content for the lessons, which I’m sure is already out there (read: I want to do as little work as possible while teaching him as much as possible).

Finally, I’ll be using markup.io to add my own notes to the existing content.  

So with that, here’s the first lesson…

Lesson 1: basic programming concepts.

In this lesson, we’ll go from how to write a single line of code that does basic calculations to learning about objects and classes and putting the code in a document that runs by itself (i.e., so you don’t have to retype it every time).  

  1. Read the “Compiling languages” section of “Ruby Object Oriented Programming" to learn more about the theory of classes. Don’t do any of the exercises, but this will give you some background on the exercises you’re going to start.
  2. Start out with the first page of “Ruby in 20 minutes.” This will teach you how to use Ruby in the terminal.
  3. Now let’s do one more exercise in the terminal. It’s from this page, but all you have to do is follow the instructions I’ve written in the markup: “My First Ruby Program.”
  4. Okay, now that we’ve seen how to program in the terminal, let’s move that same code to a separate file. In this case, we put all the code into a single text file and then in terminal, we just tell ruby to run everything in that text file. In order to do this, you have to become a little bit familiar with the Terminal commands so that you can go into different directories directly from Terminal. Here is a quick tutorial. Once you’ve gone through it, here’s a quick reference guide for the commands in Terminal. No markup on either of those two links.
  5. So now that you know how to navigate to directories in the terminal, we’ll use the same page as in step 3, but this time we’ll follow the directions: “My First Ruby Program

Okay, so now we’ve learned a bit about how to use ruby in the command line, how to save a bunch of commands to a file, and how to execute that file from the command line. Time to start learning about functions. That will be lesson 2.