If you automate a process which you repeat Y times, that takes X minutes, what would your payoff be?

Payoff = XY minutes saved, right?

Surprisingly I've found that is almost never the case. Instead, the benefits are almost always greater than XY. In some cases, much greater. The benefits of automating a process are greater than the sum of the process' parts.

Actual Payoff = XY minutes saved + E

What is E? It's the extra something you get from not having to waste time and energy on XY.

An Example

Last year I did a fair amount of consulting work I found via craigslist. I used to check the Computer Gigs page for a few different cities, multiple times per day. I would check about 5 cities, spending about 2 minutes on each page, about 3 times per day. Thus, I'd spend 30 minutes a day just checking and evaluating potential leads.

I then wrote a script that aggregated all of these listings onto one page(including the contents so I didn't have to click to a new page to read a listing). It also highlighted a gig if it met a certain criteria that I had found to be promising. The script even automated a lot of the email response I would write to each potential client.

It cut my "searching time" down to about 10 minutes per day. But then something happened: I suddenly had more time and energy to focus on the next aspect of the problem: getting hired. It wasn't long before I was landing more than half the gigs I applied to, even as I raised my rates.

I think this is where the unexpected benefits come from. The E is the extra energy you'll have to focus on other problems once you don't have to spend so much time doing rote work.

Automate. Automate. Automate

Try to automate as much as possible. The great thing about automation is that once you automate one task you'll have more time to automate the next task. Automation is a great investment with compounding effects. Try to get a process down to as few steps or keystrokes as possible(your ideal goal is zero keystrokes). Every step you eliminate will pay off more than you think.

I wrote a simple php program called phpcodestat that computes some simple statistics for any given directory.

I think brevity in source code is almost always a good thing. I think as a rule your code base should grow logarithmically with your user base. It should not grow linearly and certainly not exponentially.

If your code base is growing faster than your user base, you're in trouble. You might be attacking the wrong problem. You might be letting feature creep get the past of you.

I thought it would be neat to compute some stats for popular open source PHP applications.

My results are below. I don't have any particular profound insights at the moment, but I thought I'd share my work as I'm doing it in the hopes that maybe someone else would find it useful.

NameDirectoriesFilesPHP FilesPHP LOCPHP ClassesPHP Functions

../cake-1.2.6 296

677 428 165183 746 3675

../wordpress-2.9.2 82 753 279 143907 149

3827

../phpMyAdmin-3.3.1-english 63 810 398

175867 44 3635

../CodeIgniter_1.7.2 44

321 136 43157 74 1211

../Zend-1.10 360 2145 1692 336419 42

11123

../symfony-1.4.3 770 2905 2091

298700 362 12198

If a post on HackerNews gets more points, it gets more visits.

But how much more? That's what Murkin wanted to know.

I've submitted over 10 articles from this site to HackerNews and I pulled the data from my top 5 posts (in terms of visits referred by HackerNews) from Google Analytics.

Here's how it looks if you plot visits by karma score:

The Pearson Correlation is high: 0.894.

Here's the raw data:

karma,visits,page 53,3389,/twelve_tips_to_master_programming_faster 54,2075,/code/use_rsync_to_deploy_your_website 54,1688,/unfeatures 34,1588,/flee_the_bubble 25,1462,/make_something_40_of_your_customers_must_have 14,1056,/when_forced_to_wait_wait 4,214,/diversification_in_startups 1,146,/seo_made_easy_lumps 1,36,/dont_flip_the_bozo_bit

All the time I overhear people saying things like "I will start excercising everyday" or "We will ship this software by the end of the month" or "I will read that book" or "I will win this race." I'm guilty of talking like this too.

The problem is that often, you say you will do something and you don't end up doing it. Saying "I will do", might even be a synonym for "I won't do".

Why does this happen? I don't think it's because people are lazy. I think it's because we overestimate our ability to predict the future. We like to make specific predictions as opposed to predicting ranges.

I'll explain why we are bad at making predictions in a minute, but first, if you find yourself making predictions about what you will do that turn out to be wrong, you should fix that. You can either tone down your predictions, giving ranges instead. For instance, instead of saying "I think I will win the race", say "I think I will finish the race in the top 10". Or, even easier: stop talking about things you will do entirely, and only talk about things you have done. So, in the race example, you might say something like "I ran 3 miles today to train for the race." (If you do win the race, don't talk about it a lot. No one likes a braggert).

Why we are bad at making predictions.

Pretend you are walking down a path:

Someone asks you whether you've been walking on grass or dirt. You can look down and see what it is:

Now, they ask you what you will be walking on. You can look ahead see what it is:

Easy right? But this is not a realistic model of time. Let's add some fog:

Again, someone asks you whether you've been walking on grass or dirt. Even with the fog, you can look down and see what it is:

Now, they ask you what you will be walking on. You look ahead, but now with the fog you can't see what it is:

What do you do? Do you say:

1. Dirt
2. Grass
3. I don't know. It could be either dirt or grass, or maybe something else entirely.
4. I don't know. I've been walking on grass. Not sure what I'll be walking on in the future.

In my opinion you should say something like C or D.

This second example models real life better. The future is always foggy.

Why is the future foggy?

I don't know. Maybe a physicist could answer that question, but I don't know the answer. And I don't think I ever will.

Notes

1. In other words, don't overpromise and underdeliver.

If a book is worth reading, it's worth buying too.

If you're reading a book primarily to gain value from it(as opposed to reading it for pleasure) you should always buy it unless it's a bad book.

The amount of value you can get from a book varies wildly. Most books are worthless. Some can change your life. For simplicity, let's say the value you can derive from any one book varies from 1 cent to $100,000(there are many, many more worthless books than there are of the really valuable kind).

The cost however, does not vary as much. Books rarely cost more than $100, and generally average to about $15.

You shouldn't read a book that you think will offer you less than $100 in value. Time could be better spent reading more important books.

So let's assume you never read a book that gives you less than $100 in value. Thus, the cost of a physical copy of the book is at most 15% (using the $15 average price) of the value gained.

Would owning that book help you extract 15% more from it? It nearly always will. When you own a book, you can take it anywhere. You can mark it up. You can flip quickly through the pages. You can bookmark it. You can easily share it with a friend and then dicuss it. If these things don't help you get 15% more out of that book, I'd be very surprised.

Where it gets even more certain, is when you read a really valuable book--say a book offering $1,000 of value. Now you'd only need to get 1.5% more out of that book.

The investment in that case is a no brainer.

Notes

1. Even if a book is more expensive, say $50, the numbers don't change too much.
2. Pardon my scribbling. Got a new toy.

My room was always messy. Usually because clothes were strewn everywhere On the floor, on the couch, anywhere there was a surface there was a pile of clothes. Dirty, clean, or mostly-clean scattered about.

I tried a dresser. I tried making a system where I had spaces for each type of clothing: shirts, pants, etc. Nothing worked.

Then a friend saw my room and quipped, "Duh. You have too many clothes. Let's get rid of most of them."

So we did. About 75% of my clothes were packed up in garbage bags and sent off to the Salvation Army that day.

Ever since, my room has been at least 5x cleaner on average.

Almost always, there is one simple change you can make that will have drastic effects.

This change is called the least you can do.

I had a website that was struggling to earn money even with a lot of visitors. I added AdSense and almost nothing happened. Then I moved the AdSense to a different part of the page and it suddenly made 5x more money. A week later I changed the colors of the ad and it suddenly made 2x as much money. Now the site makes 10x as much money and I barely did anything.

These are trivial examples, but the technique works on real problems as well.

The key is to figure out what the "least you can do" is.

You can discover it by working harder or smarter:

• The hard way. You can try a ton of things, go through a to-do list dozens of items long, and hope you hit upon it.
• The smart way. You can invest time learning instead of doing. Reading books, learning new math or programming techniques, talking to other people, thinking critically, etc. You'll then have a much better hunch at what the "least you can do is".

In reality you need to do things both ways. But try to put extra effort into doing things the smart way, and see where it takes you.

Notes

1. Thanks to Conor for providing feedback.
2. I never shop for clothes. Once a year, maybe twice. The reason I had so many was because I never got rid of any clothes.
3. This AdSense site doesn't make a ton of money, but it now makes enough to pay all my server bills, which is nice.
4. Finding the least you can do is kind of like diff. You are trying to find the smallest change you can make to turn the status quo into an improved version.
5. Another relevant computer science topics is the The longest common subsequence problem.

Good communication is overcommunication. Very few people overcommmunicate. Undercommunication is much more common. Undercommunication is also the cause of countless problems in business.

Instead of striving for some subjective "good communication", simply strive to overcommunicate. It's very unlikely you'll hit a point where people say "he communicates too much". It's much more likely you'll come up a bit short, in which case you'll be left with good communication.

Here are 4 tips that will bring you closer to overcommunicating:

1. Say the hard things. Often the hardest things to talk about are the most important things to talk about. If something is stressing you out, just say it. Getting it out there, even if not in the most eloquent way, is much better than not talking about it at all. A good strategy when approaching a hard subject is to bounce your approach off a neutral 3rd party to see if your angle is smart. Many times it's the other person who has something they're stressed about but isn't talking about. It's your job to be perceptive and ask them questions to get it out on the table.
2. Repeat yourself. People have bad memories and even worse attention spans. Repeat yourself. If something is very important, repeat yourself multiple times. If someone hasn't gotten the message, it's more likely your fault for not repeating yourself enough than it is their fault for not getting it.
3. Use tools. Email, Facebook, Google Wave, Basecamp, Skype, Gchat, Dropbox, Github, Sifter...these are just a sample of the modern tools you can use to communicate. Embrace them. Try different ones. Try pen and paper and whiteboards. Ideally you'll find two or three tools that cover all the bases, but don't be afraid to use multiple tools even if you have to repeat yourself across them a bit.
4. Set a regular schedule. Set aside a recurring time for communication. It could be once a week or once a day. Even if there's nothing new to talk about, it will help to just go over the important topics again as you can rarely repeat yourself too much.

That's it. Good luck!

Network effects are to entrepreneurs what compounding effects are to investors: a key to getting rich.

Sometimes a product becomes more valuable simply as more people use it. This means the product has a "network effect".

You're probably familiar with two famous examples of network effects:

• Windows. People started using Microsoft Windows. Therefore, developers started building more software for Windows. This made Windows more valuable, and more people started to use it.
• Facebook. People joined Facebook and invited their friends. Their friends joined which made the site more valuable to everyone. People invited more friends.

All businesses have network effects to some degree. Every time you buy a slice of pizza, you are giving that business some feedback and some revenue which they can use to improve their business.

Giant businesses took advantage of giant network effects. When you bought that pizza, you caused a very tiny network effect. But when you joined Facebook, you immediately made it a more valuable product for many other users(who could now share info with you), and you may even have invited a dozen more users. When a developer joins Facebook, they might make an application that improves the service for thousands or even millions of users, and brings in a similar number of new users.

The biggest businesses enabled user-to-user network effects. Only the pizza store can improve its own offering. But Facebook, Craiglist, Twitter, and Windows have enabled their customers and developers to all improve the product with extremely little involvement from the company.

Notes

1. This is probably easier said than done.

1. Is there any subject which cannot be explained simply?

No.

1. What about quantum mechanics, organic chemistry, or rocket science? Surely these cannot be explained simply.

Any and every subject that can be explained logically, can also be explained simply.

1. So you are saying that even I can become an expert at quantum mechanics?

No. I am saying that every logical thing there is to learn in quantum mechanics can be explained simply. This holds for all subjects.

However, that does not mean that every person can master every subject. Only people that master the basic building blocks of human knowledge can master any subject.

1. What are the basic building blocks of human knowledge?

First, the ones you learn early on: reading, writing, and arithmetic. Then, a few you are not forced to learn: probability, statistics, evolution and psychology.

1. Why do I have to learn probability, statistics, evolution and psychology?

Because these subjects explain 99% of what you see in the world. You need to learn probability and statistics to understand subjects like chemistry, physics, and engineering. You need to understand evolution and psychology to understand subjects like history, economics, government and religion. You need to know probability and statistics to understand these latter subjects as well. Thus, probability and statistics is as core to learning as reading, writing, and arithmetic.

1. I took a prob/stat course in high school. Is that good enough?

Probably not. After you took your reading and writing classes in elementary school, did you stop reading and writing or did you start practicing these skills everyday? You continued to use and practice them, right? Did you continue to practice your prob/stat skills? You should.

1. You're wrong. I've mastered probability and statistics, evolution, and psychology, and there are still subjects I can't find simple explanations for.

I'm not wrong. You just need to look in the right places. You probably won't find simple explanations in school. Schools are in the business of making learning seem complex and expensive. Better places to search for simple explanations:

• Online. Sites like Khan Academy, Ted, Wikipedia and Google.
• In books. Browse around Barnes & Noble or Borders.
• From a friend. Find someone that knows the subject well and ask them to teach you.

1. Do I need to master the building blocks to be successful in life?

No. But you need to know them if you want to be able to learn any subject.

In computer programming, one of the most oft-repeated mottos is DRY: "Don't Repeat Yourself."

The downside of DRY's popularity is that programmers might start applying the principle to conversations with other humans.

This fails because computers and people are polar opposites.

With computers, you get zero benefit if you repeat yourself. With people, you get zero benefit if you don't repeat yourself!

Four Ways Computers and People are Different

A computer's memory is perfect. A computer forgets nothing. Tell it something once, and it will remember it forever. A human remembers almost nothing. I forget what I had for breakfast 2 days ago. I don't remember which people I talked to last week, nevermind what was said. If memory were cheese, a computer's would be cheddar and a human's would be swiss. You've got to repeat yourself when communicating with people because people forget. A computer is always paying attention. Computers are perfect listeners. They are always listening to your input and storing it in memory. You, the operator, are the only thing they care about. Computers don't have needs. They don't daydream or have cellphones(yet). People on the other hand, rarely if ever pay full attention. They zone in and out. It's hard to even tell if they're zoned in, as we've all learned it's better to nod our heads. People have their own needs and concerns and opinions. You've got to repeat yourself when communicating with people because people don't pay attention. A computer understands your logic. When you write a program, a computer never misunderstands. It will execute the program exactly as you typed it. People, however, do not communicate so flawlessly. Until I was 22 I used to think "hors d'oeuvres" meant dress nice. I did not understand the pronunciation. One time a friend emailed me about an event and said "Our place. Hors d'oeuvres. 7pm" and I responded "Awesome. Will there be food?" You've got to repeat yourself when communicating with people because people don't understand. A computer doesn't need to know what's most important. Computers don't make decisions on their own and so don't need to know what's most important. A computer will remember everything equally. Then it will sit awaiting your commands. It won't make decisions without you. A person, however, will make decisions without you and so needs to know the order of importance of things. For example, if you're not a fan of peanuts, you might tell the waiter once that you'd prefer the salad without nuts. But if you're deathly allergic to peanuts, you should probably repeat yourself a few times so the waiter knows there better not be any nuts on your salad. You've got to repeat yourself when communicating with people because people need to know what's most important. A Numeric Explanation

If you tell something to your computer once: The odds the computer remembers: 100%. The odds the computer was paying attention: 100%. The odds the computer understood you: 100%. The odds the computer gets the importance right: 100%. If you tell something to a person once: The odds the person remembers: 30%? The odds the person was paying attention: 40%? The odds the person understood you: 50%? The odds the person gets the importance right: 30%? In other words, the odds of communicating perfectly are very low: 1.8%! You are highly likely to run into at least one of those four problems.

Now, if you repeat yourself 1 time, and we assume independence, here's how the probabilities change:

The odds the person remembers: 51% The odds the person was paying attention: 64% The odds the person understood you: 75% The odds the person gets the importance right: 51% By repeating yourself just once you've increased the chances of perfect communication from 1.8% to 12.5%! Repeat yourself one more time and the probability of perfect communication increases to over 90%. Well, in this simplistic model anyway. But I hope you get the idea.

Repeat yourself until you overcommunicate

To communicate well you should try to overcommunicate.

Overcommunicating is hard to do. It's much easier and more common to undercommunicate.

If you're not repeating yourself a lot, you're not overcommunicating.

An example of how I repeat myself

On the various projects I'm involved with we use Gmail, Google Docs, Google Wave, Basecamp, Github, Sifter, gChat and Skype. Which one do I prefer?

None of them. I prefer pen, paper, whiteboards and face-to-face meetings. I write down my own todo list and schedule with pen and paper. Then I login to these sites and repeat what I've written down for the sake of repeating myself to other people. This isn't inefficieny, it's good communication.

Some people prefer Google Docs, some prefer Basecamp. I'll post things to both, to ensure everyone knows what I'm working on.

With every new project I repeat a lot of messages and questions to the team. "How many people love this product?", "How can we make this simpler?", "Which of the 7 deadly sins does this appeal to?". I think these are important questions and so I'll repeat them over and over and add them to the todo lists for every project, multiple times.

Notes

1. I've yet to be part of founding a big Internet company, so you don't have to agree with me that repeating yourself is critical to success.

When a problem you are working on forces you to wait, do you wait or switch tasks?

For example, if you are uploading a bunch of new web pages and it's taking a minute, do you almost instinctively open a new website or instant message?

I used to, and it made me less productive. I would try to squeeze more tasks into these short little idle periods, and as a result I would get less done.

Multitasking during idle times seems smart

Doing other things during idle times seems like it would increase productivity. After all, while you're waiting for something to load you're not getting anything done. So doing something else in the interim couldn't hurt, right? Wrong.

Switching tasks during idle times is bad, very bad

While you're solving one problem, you likely are "holding that problem in your head". It takes a while to load that problem in your head. You can only hold one important problem in your head at a time. If you switch tasks, even for a brief moment, you're going to need to spend X minutes "reloading" that problem for what is often only a 30 second vacation to Gmail, Facebook, Gchat, Hackernews, Digg, etc. It's clearly a bad deal.

Don't multitask

If you're doing something worth doing, give it all of your attention until it's done. Don't work on anything else, even if you're given idle time.

Why you can't multitask well

Human intelligence is overrated. Even the smartest people I know still occasionally misplace their keys or burn toast. We are good at following simple tasks when we focus, most of the time. But we are not built for multitasking.

Can you rub your head clockwise? Can you rub your belly counterclockwise? Can you say your ABC's backwards?

Dead simple, right? But can you do all three at once? If you can, by all means ignore my advice and go multitask.

Wait out those idle times

If what you are doing is easy or mundane, multitasking is permissible because loading a simple problem like "laundry" into your head does not take much time. But if what you are doing is important and worth doing, you are obligated to give it your full attention and to wait out those "idle times".

If you switch tasks during your idle times, you're implying that the time to reload the problem is less than the time gained doing something else. In other words, you are implying what you are doing is not worth doing. If that's the case, why work on it at all?

Notes

1. Influenced by Paul Graham's Holding a Program in One's Head
2. Of course, if you're given a very long idle time, then feel free to switch tasks. Don't spend 4 hours staring at your screen waiting for a coworker to get back to you.

Whether you're an entrepreneur, a venture capitalist, a casual investor or just a shopper looking for a deal, you should know how to buy low and sell high. Buying low and selling high is not easy. It's not easy because it requires too things humans are notoriously bad at: long term planning and emotional control. But if done over a long period of time, buying low and selling high is a surefire way to get rich.

Warren Buffett is perhaps the king of buying low and selling high. These tips are largely regurgitated from his speeches and biographies which I've been reading over the past two years.

Let the market serve you, not instruct you.

Everything has both a price and a value. Price is what you pay for something, value is what you get. The two rarely match. Both can fluctuate wildly depending on a lot of things. For instance, the price of gas can double or triple in a year based on events in the Middle East, but the value of a gallon of gas to you largely remains constant.

Don't let the market ever tell you the value of something--don't let it instruct you. Your job is to start figuring out the intrinsic value of things. Then you can take advantage when the price is far out of whack with the true value of something--you can make the market serve you.

Google's price today is $187 Billion. But what's its value? The average investor assumes the two are highly correlated. Assume the correlation is closer to 0. Make a guess about the true value of something. You may be way off the mark in you value estimating abilities, but honing that skill is imperative.

Be frugal.

You've got to be in a position to take advantage of the market, and if you spend your cash on unnecessary things, you won't be. Buy food in bulk at Costco. Cut your cell phone bill or cancel it altogether. Trim the fat wherever you can. You'd be surprised how little you can live off of and be happy. Read P.T. Barnum's "The Art of Moneygetting" for some good perspective on how being frugal has been a key to success for a long time.

Always be able to say "no".

The crazy market will constantly offer you "buy high, sell low" deals. You've got to be able to turn these down. If you don't have good cash flow or a cash cushion, it's very hard. That's why being frugal is so important.

Be Happy

If you're happy with what you have now it's easy to make good deals over the long run. Buying low and selling high requires long term emotional control. If you're unhappy or stressed, it's very hard to make clear headed decisions. Do what you have to do to get happy.

Make the Easy Deals

Out of the tens of thousands of potential deals you can make every month, which ones should you act on? The easy ones. Don't do deals in areas that you don't understand. Do deals where you know the area well. I wouldn't do a deal in commodities, but I'd certainly be willing to invest in early stage tech startups.

Margin of Safety

The easy deals have a wide margin of safety. An easy deal has a lot of upside. An easy deal with a wide margin of safety has little to no downside. Say a company has assets you determine are worth $1 Million and for some reason the company is selling for $950,000. Even if the company didn't grow, it has a good margin of safety because the price of its assets alone are worth more than the price you paid.

Read a lot

How do you find these easy deals? You've got to read a lot. You've got to keep your eyes open. Absorb and think mathematically about a lot of information you encounter in everyday life.

Buy a business

Businesses can be the ultimate thing to buy low and sell high because they have nearly unlimited upside. Real estate, gold, commodities, etc., can be good investments perhaps. But when's the last time you heard of someone's house going up 10,000%? Starting a business can be your best investment ever, as you are guaranteed to buy extremely low, and have the potential to sell extremely high.

Possibly the biggest mistake a web startup can make is to develop in a bubble. This is based on my own experience launching 13 different websites over the past 4 years.

The raw numbers:

fleebubble td{ border: 1px solid #d2d2d2;} Total ## of SuccessesAverage time to Beta LaunchCumulative Gross Revenues% of Total Traffic(to all my sites over this period)Cumulative ProfitsEmotional Toll Bubble30Months99%GoodNone-low

What is "the bubble"?

The bubble is the early, early product development stage. When new people aren't constantly using and falling in love with your product, you're in the bubble. You want to get out of here as fast as possible.

If you haven't launched, you're probably in the bubble. If you're in "stealth mode", you're probably in the bubble. If you're not "launching early and often", you're probably in the bubble. If you're not regularly talking to users/customers, you're probably in the bubble. If there's not a steady uptick in the number of users in love with your product, you're probably in the bubble.

Why you secretly want to stay in the bubble

A part of you always wants to stay in the bubble because leaving is scary. Launching a product and having it flop hurts. You hesitate for the same reason you hesitate before jumping into a pool in New England: sure, sometimes they're heated, but most of the time they're frickin freezing. If the reception to your product is cold, if no one falls in love with it, it's going to hurt.

The danger of the bubble

You can stand at the edge of the pool for as long as you want, but you're just wasting time. Life is too short to waste time.

In addition to wasting time, money and energy in the bubble (which can seem like a huge waste if your product flops), two things happen the longer you stay in the bubble:

• The marginal return of each additional unit of effort decreases.
• Expectations increase.

This is a very bad combination that can lead to paralysis. The more you pour into your bubble product, the less impact your additional efforts will have yet at the same time the more you will expect your product to succeed.

Don't wait any longer: jump in the water, flee the bubble!

How to Flee the Bubble

Here are four easy strategies for leaving the bubble: launch, launch & drop, pick one & launch, or drop.

Launch. Post your product to your blog today. Email your mailing list. Submit it to Reddit or Hackernews or TechCrunch. Just get it out there and see what happens. Maybe it will be a success.

Launch & Drop. Maybe you'll launch it and the feedback will be bad. Look for promising use cases and tweak your product to better fit those. If the feedback is still bad, drop the product and be thankful for the experience you've gained. Move on to the next one.

Pick One & Launch. If you're product has been in the bubble too long, chances are it's bloated. Pick one simple feature and launch that. You might be able to code it from scratch in a day or two since you've spent so much time already working on the problem.

Drop. Ideas are for dating not marrying. Don't ever feel bad for dropping an idea when new data suggests it's not best to keep pursuing it. It's a sign of intelligence.

That's all I've got. But don't take it from me, read the writings of web entrepreneurs who have achieved more success. (And please share what you find or your own experiences on HackerNews).

At our startup, we've practiced a diversification strategy.

We've basically run an idea lab, where we've built around 7 different products. Now we're getting ready to double down on one of these ideas.

The question is, which one?

Here's a 10 question form that you can fill out for each of your products.

Product Checklist 1. How many users/customers does the product have?

1. What percentage of these users/customers would be disappointed if this product disappeared tomorrow?

2. Explain the product in one sentence:

3. Is the product good/honest? Yes

4. What is the predicted customer acquisition cost? $

5. What is the predicted average lifetime value per customer? $

6. Which of the 7 deadly sins does the product appeal to? Lust Greed Sloth Gluttony Pride Envy Wrath

7. What's the go to market strategy in one sentence?

8. What resources do you need to do this?

9. What's the total addressable market size? people $

Over the past 6 months, our startup has taken two approaches to diversification. We initially tried no diversification and then we tried heavy diversification.

In brief, my advice is:

Diversify heavily early. Then focus.

In the early stages of your startup, put no more than 33% of your resources into any one idea. When you've hit upon an idea that you're excited about and that has product/market fit, then switch and put 80% or more of your resources into that idea.

How Startups Diversify

An investor diversifies when they put money into different investments. For example, an investor might put some money into stocks, some into bonds, and some into commodities. If one of these investments nosedives, you won't lose all your money. Also, you have better odds that you'll pick some investments that generate good returns. The downside is that although you reduce the odds of getting a terrible outcome, you also reduce the odds of getting a great outcome.

A startup diversifies when it puts resources into different products. For example, a web startup might develope a search engine and an email service at the same time and hope that one does very well.

The 4 Benefits of Diversification for Startups

There are 4 main benefits to diversify:

1. Better odds. Creating multiple products increases the odds of finding a great idea in a great market. The Internet provides very fast feedback about whether you've found one. After building your team, the next big thing to decide is what product to focus on. You should not choose one until you're built a product you're excited about and found product/market fit. You've found product/market fit when about 40% of your customers think your product is a must have.

2. Builds individual skills. Entrepreneurs need broad skillsets. Trying multiple products forces you to learn new skills. You may build a consumer video site and improve your technical scaling skills while at the same time be trying a B2B site and improving your sales skills.

3. Builds team skills. Doing multiple products gives you plenty of opportunities to interact with your team in varied situations. You'll learn faster what your teammates' strengths and weaknesses are. You'll also be forced to improve your team communication, coordination, delegation and product management skills.

4. It's fun. Let's be honest, the early stages of working on a new problem or idea are oftentimes the most stimulating and exciting. Instead of focusing on one product day in and day out that might or might not work, trying multiple ideas keeps your brain going and your enthusiasm high.

When to Focus

If diversifying has so many benefits, should you ever stop? Yes, you should.

Focus when you are ready to make money.

Coming up with new ideas and building new, simple products is the easy part of startups. Unfortunately, developing new solutions is not what creates a lot of value for other people. Bringing your solution to other people is when most value is created--and exchanged.

Imagine you're a telecom company and you build a fiber optic network on the streets of every city in America--but fail to connect people's homes to the new system. Although connecting each home can be hard and tedious, without this step no value is created and no money will come your way.

When you hear the phrase "execution is everything", this is what it refers to. If you want to make money, and you've got a great team and found product/market fit, you've then got to focus and execute. Drop your other products and hunker down. Fix all the bugs in your main product. Really get to know your customers. Identify your markets and the order in which you'll go after them. Hire great people that have skills you are going to need.

Benefits of Focusing

Let's recap the benefits of focusing.

1. Money. Creating new products in the early days is fun, but making money is fun too. Once you start focusing on growing one product, the money incentive will keep you motivated and spirits high.

2. Rewarding. Creating value for other people is perhaps the most rewarding feeling in life. Finding people with a problem, and getting your solution which solves their problem into their hands, is even better than the money you earn. You'll also create valuable jobs for your employees.

3. Resources. If you execute well, you'll end up with resources that you can use to put diversification back into the picture. For instance, after bringing better search to almost the whole world, Google can now diversify and create better email systems, web browsers, maps, etc.

Benefits of the "Diversify Early, Then Focus" approach: A Roulette Analogy

When you first begin your startup it's very similar to playing roulette. You plunk down some resources on an idea and then the wheel spins and you win more money or lose the money that you bet.

In roulette, you can bet it all on one number(focusing) or bet a smaller amount on multiple numbers(diversifying). If you bet it all on one number and win, you get paid a lot more money. But you're also more likely to lose it all.

The "game of startups" though, has two very important differences:

1. You get more information after the game starts "spinning".
2. You can always move your bets around.

You get way more information about the odds of an idea "hitting the jackpot" after you plunked some time and money into it. You may find customers don't really have as big a problem as you thought. Or that the market that has this problem is much smaller than you thought. You may find one idea you thought was silly actually solves a big problem for people and is wildly popular.

You can then adjust your bets. If your new info leads you to believe that this idea has a much higher chance of hitting the jackpot, grab your resources from the other ideas and plunk them all down on this one. Or vice versa.

Don't Take My Word for It

Sadly I bet there are paperboys who's businesses have done better than all mine to date, so take my advice with a grain of salt.

But if you want to learn more, I suggest reading the early histories of companies such as eBay, Twitter, and Facebook and see what their founders were up to before they founded those sites and in the following early period.

And check back here, I'll hopefully be sharing how this approached worked for us.

Notes

1. Fun tidbit: I wrote this on paper then typed it up and posted it all while flying on Virgin Air from SFO back to Boston. Thanks for the free wifi Google!
2. Thanks to Ben for helping me form my ideas on this issue.

It is better to set small, meaningful goals than to set wild, audacious goals.

Here's one way to set goals:

Make them good. Make them small.

Make them Good

Good goals create value. Some examples:

• Make a customer smile.
• Teach someone math.
• Learn how to cook.
• Organize weather information.

Make them Small

Start small. It is better to set one or two goals per time period than to set two dozen goals. Instead of a goal like "get 1,000,000 people to your website", start with a smaller goal like "get 10 people to your website."

If you exceed a goal and still think it's a good thing, raise the goal an order of magnitude. If you get those 10 visitors, aim for 100.

Why Small Goals Are Better

Setting smaller goals is better because:

• It feels good when you exceed a goal. Occasionally you'll wildly exceed a goal and that will feel great.
• It's better to do a few small good things, than to fail trying one audacious thing.
• It's easier to accomplish an audacious thing by going one step(order of magnitude) at a time.
• It's less stressful and makes you happier. Low expectations are good because in most cases you will exceed them and feel happy. High expectations, by definition, are bad because in most cases you will not meet them and feel bad.
• Goals are arbitrary anyway. All goals are simply arbitrary constraints that help you focus--often with a team--to get stuff done. So since they're arbitrary, and as long as they're good goals, might as well make them simpler and easier.

Setting Ranges

Another way to set goals is to use ranges. Set a low bar and a high bar. For example, your weekly goals might be:

Low BarHigh Bar - Get 2 new customers - Implement 2 product improvements - Write 1 blog post - Get 7 new customers - Implement 4 product improvements - Write 3 blog posts

If you exceed your low bar, you can be happy. If you exceed your high bar, you can be very happy.

Programming, ultimately, is about solving problems. Often I make the mistake of judging a programmer's work by the elegance of the code. Although the solution is important, what's even more important is the problem being solved.

Problems are not all created equal, so while programming you should occasionally ask yourself, "is this problem worth solving?"

Here's one rubric you can use to test whether a problem is worth solving:

1. Simplicity. Can you envision a simple solution to the problem? Can you create at least a partial, meaningful solution or prototype in a short period of time? Building a flying car would solve a lot of my transportation problems, but I don't see a simple path to getting there. Don't be too far ahead of your time. Focus on more immediate problems.

2. Value. Would solving this problem create value? Sometimes it's hard to predict in advance whether or not your solution would create value for people. The easiest way to tell if you've succeeded is if anyone would be disappointed if your solution were to disappear. If you can get a first prototype into people's hands early, you'll find out quickly whether or not you are building a solution to a problem that creates value.

3. Reach. Do a lot of people have this problem? Some problems, like searching for information, are shared by nearly everyone. Others, like online version control, are shared by a much smaller niche but still a significant amount of people. If a problem is shared by only a handful of people, it's probably not worth programming a solution.

Great Programmers Solve Important Problems

The best programmers aren't simply the ones that write the best solutions: they're the ones that solve the best problems. The best programmers write kernels that allow billions of people to run other software, write highly reliable code that puts astronauts into space, write crawlers and indexers that organize the world's information. They make the right choices not only about how to solve a problem, but what problem to solve.

Life is Short

Life is too short to solve unimportant problems. If you want to solve important problems, it's now or never. The greatest programmers only get to solve a relatively small amount of truly important problems. The sooner you get started working on those, the better.

Ignore Speed Limits

If you don't have the skills yet to solve important problems, reach out to those who do. To solve important problems, you need to develop a strong skill set. But you can do this much faster than you think. If you commit to solving important problems and then reach out to more committed programmers than you, I'm sure you'll find many of them willing to help speed you along your learning curve.

If you combine Paul Graham's "make something people want" advice with Sean Ellis' product-market fit advice (you have product-market fit when you survey your users and at least 40% of them would be disappointed if your product disappeared tomorrow), you end up with a possibly even simpler, more specific piece of advice:

Make something 40% of your users must have

Your steps are then:

1. Make something people want.
2. Put it out there.
3. Survey your users. If less than 40% would be disappointed if your product disappeared, go back to step 1.

Only when you hit that 40% number(or something in that range) should you be comfortable that you've really made something people want.

Does this advice work? I think it would for 3 reasons.

1 The Sources

PG and Sean Ellis know what they're talking about.

2 Companies that make my "Must Haves" are successful

I made a list of my "must have" products and they are all largely successful. I suggest you try this too. It's a good exercise.

My List of Must Haves:

Google Search Facebook Gmail Dropbox craigslist Windows Excel Twitter Search Firefox Chrome Wikipedia Amazon

(More Technical Products) Git + Github LAMP Stack Ruby Notepad++ Vim jQuery Firebug Web Developers Extension StackOverflow TechCrunch HackerNews Navicat

3 The Only "Must Have" Product I Built was the Biggest Success

I've worked on a number of products over the past 3 years.

One of them I can tell you had a "I'd be disappointed if this disappeared" rate of over 40%. We sold that site.

All the others did not have that same "must-have" rate. We launched Jobpic this summer at Demo Day. People definitely wanted it. But we didn't get good product/market fit. If we had surveyed our users, I bet less than 10% of them would report being disappointed if Jobpic disappeared. Our options are to change the product to achieve better product/market fit, or go forward with an entirely new product that will be a must have.

Concluding thoughts

I don't know if this advice will work. But I'm going to try it.

Startup advice can be both exhilarating and demoralizing.

On the plus side, good advice can drastically help you. At the same time, if it's really good advice that means two things:

1. This is how you should be doing things.
2. You were not doing things this way.

That can frustrating. I've spent a few years now in the space and to realize you've been doing certain things wrong for a few years is...well...painful.

But you laugh it off and keep chugging along.

Notes

1. Thanks Nivi for the great Venture Hacks interview!
2. Users/Customers refer to people who use your site regularly or buy from you. This is not "visitors". Generally a much lower percentage than 40% of visitors become users or customers. The 40% refers to the people who have made it through your funnel and have become users or customers.
3. I used customers and users interchangeably. For non-tech businesses, you can just use "customer" each time.
4. Thanks to Ben, Alex Andon, and Andrew Kitchell for feedback.

Links

1. Another piece of startup advice that didn't "click" until recently: Roelof Botha's 7 deadly sins advice.

The best Search Engine Optimization(SEO) system I've come across comes from Dennis Goedegebuure, SEO manager at eBay. Dennis' system is called LUMPS. It makes SEO dead simple.

Just remember LUMPS:

L inks U urls M etadata P age Content S itemaps

These are the things you need to focus on in order to improve your SEO. You should also, of course, first know what terms you want to rank highly for.

LUMPS is listed in order of importance to search engines. So links are most important, sitemaps are least important.

Let's break each one down a bit more.

Links.

External links--links from domains other than your own--are most important. For external links, focus on 3 things, again listed in order of importance:

1. Quality. A link from CNN.com is worth order(s) of magnitude more than a link from my blog. A link from a related source, like from ESPN.com to a sports blog, would likely be better than from an unrelated source.
2. Quantity. Even though quality is most important, a lot of inbound links help.
3. Anchor Text. You want links with relevant anchor text. Jellyfish tanks is better than click here.

Your internal link structure is also important. Make sure your site repeatedly links to the pages you are optimizing for.

External links are the most important thing you need for SEO. Internal links you can easily control, but it takes time to accumulate a lot of quality external links. Focus on creating quality content(or even better, build a User Generated Content site). People will link to interesting content.

URL Structure

The terms you are optimizing for should be in your urls. It's even better if they are in your domain. For instance, if I'm optimizing for "breck yunits", I've done a good job by having the domain name breckyunits.com. If I'm optimizing for the term "seo made easy", ideally I'd have that domain. But I don't, so having breckyunits.com/seo_made_easy is the next best thing.

Luckily, URL Structure is not just important, it's also relatively easy to do well and you can generally set up friendly URLs in an hour or so. I could explain how to do it with .htaccess and so forth, but there are plenty of articles out there with more details on that.

Metadata Content

Your TITLE tags and META DESCRIPTIONS tags are important for 2 reasons. First, search engines will use the content in them to rank your pages. Second, when a user sees a search results page, the title and description tags are what the user sees. You need good copy that will increase the Click Through Rate. Think of your title and description tags as the Link Text and Description in an AdWords ad. Just as you'd optimize the AdWords ad, you need to optimize this "seo ad". Make the copy compelling and clear.

Like URL structure, you can generally set up a system that generates good meta and description tags relatively easily.

Page Content

Content is king. If you've got the other 3 things taken care of and you have great content, you're golden. Not only will great content please your visitors, but it will likely be keyword rich which helps with SEO. Most importantly, it is much easier to get links to valuable, interesting content than to bad content. Figure out a way to get great content and the whole SEO process will work a lot better.

Sitemaps

Sitemaps are not the most crucial thing you can do, but they help and are an easy thing to check off your list. Use Google Webmaster tools and follow all recommendations and submit links to your sitemaps.

Summary

There you have it, SEO made easy! Just remember LUMPS.

Links

1. Google Webmaster Tools.
2. SEO Book - one of the best SEO sites out there.

Do you "flip the bozo bit" on people?

If you don't know what that means, you probably do it unknowingly!

What it means

When you "flip the bozo bit" on someone you ignore everything they say or do. You flip the bozo bit on a person when they are wrong or make a mistake over and over again. Usually you flip the bozo bit unconsciously.

An example

You are writing a program with Bob. Bob constantly writes buggy code. You get frustrated by Bob's bugs and slowly start ignoring all the code he submits and start writing everything yourself. You've flipped the bozo bit!

This is bad for everyone. Now you are doing more work, and Bob is becoming resentful because you are ignoring his ideas and work.

Alternatives to Flipping the Bozo Bit

Instead of flipping the bozo bit, perhaps you could work with another person. If that's not possible, take a more constructive approach:

1. Teach. Talk to Bob and figure out why he is making repeated mistakes. We all have large gaps in our education. If you've never been exposed to a concept, there's no reason why you should understand it. Try and find what it is Bob hasn't been exposed to yet, and help him learn it.
2. Change Roles. Maybe Bob should be working in another area. Find an area where you're the bozo and Bob's the expert. Let him work in that area, while you work in your area. He can even explain a thing or two to you.

Why We Flip the Bozo Bit

It seems like a simple evolutionary trick to save time. If someone is right only 10% of the time, would it be faster to ignore every statement they made, or faster to analyze each statement carefully in case it's the 1 out of 10 statements that might be true? Seems like it would be faster to just ignore everything by flipping the bozo bit.

But this is a bad solution. The two presented above are better.

Notes

1. Thanks to Tom Price for telling me about this.

Links

1. Bozo bit on Wikipedia.
2. Origin of the term?

Jason Fried from 37signals gave a great talk at startup school last month. At one point he said "software has no edges." He took a normal, everyday bottle of water and pointed out 3 features:

1. The bottle held the water.
2. The lightweight plastic made it easy to carry, and you can tell how full it was by picking it up.
3. The clear bottle let you see how much was left and what was in it.

If you added a funnel to help pour the water, that might be useful in 5% of cases, but it would look a little funny. Then imagine you attach a paper towel to each funnel for when you spill. Your simple water bottle is now a monstrosity.

The clear edges of physical products make it much harder for feature creep to happen. But in software feature creep happens, and happens a lot.

A proposal to fight feature creep

How do you fight feature creep in software? Here's an idea: do not put each new feature request or idea on a to-do list. Instead, put them on an (un)features list.

An (un)features list is a list of features you've consciously decided not to implement. It's a well maintained list of things that might seem cool, but would detract from the core product. You thought about implementing each one, but after careful consideration decided it should be an (un)feature and not a feature. Your (un)features list will also include features you built, but were only used by 1% of your customers. You can "deadpool" these features to the (un)features list. Your (un)features list should get as much thought, if not more, than your features list. It should almost certainly be bigger.

When you have an idea or receive a feature request, there's a physical, OCD-like urge to do something with it. Now, instead of building it or putting it on a todo list, you can simply write it down on your (un)features list, and be done with it. Then maybe your water bottles will look more like water bottles.

This blog is powered by software with an (un)features list.

Notes

1. Feel free to move an (un)feature to your features list if you change your mind about it.

Links

• Some more great quotes from this year's startup school.
• 37signals and their great blog.

Edit: 01/05/2010 Features are a great way to make money.

Employees and students receive deadlines, due dates, goals, guidelines, instructions and milestones from their bosses and teachers. I call these "arbitrary constraints".

Does it really matter if you learn about the American Revolution by Friday? No. Is there a good reason why you must increase your sales this month by 10%, versus say 5% or 15%? No. Does it really matter if you get a 4.0 GPA? No.

But these constraints are valuable, despite the fact that they are arbitrary. They help you get things done.

Constraints Help You Focus

Constraints, whether meaningful or not, simplify things and help you focus. We are simple creatures. Even the smartest amongst us need simple directions: green means go, red means stop, yellow means step on it. Even if April 15th is an arbitrary day to have your tax return filed, it is a simple constraint that gets people acting.

Successful People Constantly Set Constraints

Successful people are good at getting things done. They focus well. Oftentimes they focus on relatively meaningless constraints. But they meet those constraints, however arbitrary. By meeting a lot of constraints, in the long run they hit enough of those non-arbitrary constraints to achieve success. Google is known for it's "OKR's"--objectives and key results--basically a set of arbitrary constraints that each employee sets and tries to hit.

Entrepreneurs Must Set Their Own Constraints

If you start a company, there are no teachers or bosses to set these constraints for you. This is a blessing and a curse. It's a blessing because you get to choose constraints that are more meaningful to you and your interests. It's a curse because if you don't set these constraints, you can get fuddled. Being unfocused, at times, can be very beneficial. Having unfocused time is a great way to learn new things and come up with new ideas. However, to get things done you need to be focused. And the first step to get focused is to set some arbitrary constraints.

A Specific Example

Here are some specific constraints I set in the past week:

1. Write 1 blog post per day.
2. Create blogging software in under 100 lines of code.
3. Have version 0.2 of blogging software done by 5pm yesterday.

All of these are mostly arbitrary. And I have not met all of them. But setting them has helped me focus.

When You Don't Meet Your Constraints

If you don't meet your constraints, it's no big deal. They're largely arbitrary anyway. Even by just trying to meet your constraints, you learn a lot more. You are forced to think critically about what you are doing.

When you don't meet some constraints, set new ones. Because you now have more experience, the new ones might be less arbitrary.

But the important thing is just having constraints in the first place.

A lot of people have the idea that maybe one day they'll become rich and famous and then write a book about it. That's probably because it seems like the first thing people do after becoming rich and famous is write a book about it.

But you don't have to wait until you're rich and famous to write a book about your experiences and ideas.

"A few months ago I was talking to another MBA student, a very talented man, about 30 years old from a great school with a great resume. I asked him what he wanted to do for his career, and he replied that he wanted to go into a particular field, but thought he should work for McKinsey for a few years first to add to his resume. To me that's like saving sex for your old age. It makes no sense." - Warren Buffet

Likewise, saving blogging for your old age makes no sense. There are two selfless reasons why you should start blogging now:

1. You may enlighten someone.
2. Sharing your experiences adds another data point to our collective knowledge and makes us all better off.

It used to take a lot of work to publish something. Now it is simpler than brushing your teeth. So publish, write, blog!

If you need some selfish reasons, here are 5:

1. Writing is good excercise for the brain and gives you "writer's high".
2. Blogging makes you a better writer.
3. When your blog gets traffic, it stokes your ego.
4. You may spark interesting conversations with interesting people.
5. In rare circumstances, you may make money.

Blogging. Don't save it for your old age.

Finding experienced mentors and peers might be the most important thing you can do if you want to become a great programmer. They will tell you what books to read, explain the pros and cons of different languages, demystify anything that seems to you like "magic", help you when you get in a jam, work alongside you to produce great things people want, and challenge you to reach new heights.

Great coders travel in packs, just like great authors.

If you want to reach the skills of a Linus, Blake, Joe, Paul, David, etc., you have to build yourself a group of peers and mentors that will instruct, inspire, and challenge.

Here are 6 specific tips to do that.

1. Get a programming job. This is probably the best thing you can do. You'll get paid to "practice". You'll work on things that will challenge you and help you grow. And you'll have peers who will provide instruction and motivation constantly. There are tens of thousands of open programming jobs right now. Even if you feel you are not qualified for one, apply anyway, and stress how you are smart, passionate, and the experience will come with time. If you don't get a programming job today, you can reapply in 6 months or 1 year when you have better skills. Here are six job sites to check out: Craigslist (Computer Gigs, Internet Engineers, Software, Systems, Web Design) StackOverflow, CrunchBoard, HackerNews, Reddit, Startuply.

2. Take a programming class. My best tutors are my peers. People who I took a class or two with in college. We knew each other when computers were a big mystery to us, so we don't feel embarassed when we ask questions that may sound dumb. If you're currently in college, enroll in a programming class. Otherwise, look at local colleges' continuing education programs, community colleges, or professional classes. If you're in San Francisco, maybe look at AcademyX. Give unclasses.com a try. If you think classes cost too much, don't use that as an excuse until you've tried to negogiate a deal. Often someone will give you a class for free or greatly reduced price simply by explaining your situation. Other times maybe you can offer a service in return.

3. Attend a Meetup. I go to PHP and MySQL meetups frequently. Meetup.com has thousands of programming meetups throughout the country. Go to one. Every month. You'll learn from the speaker, you'll meet other programmers, and you'll meet recruiters who will try to hire you if you still haven't gotten that job.

4. Join Github. Github is the first user friendly collaborative development site for programmers. Once you get comfortable with it, you could be working alongside other programmers on open source projects in no time. I'll write a better tutorial on how to get started soon, but for now, just join and explore around. It may take you a month or two to "get it", so don't feel overwhelmed if you don't understand what's going on at first. You will eventually. And you'll start to find some great programmers to talk to.

5. Email Someone Directly. Email has been around for 35 years and it's still the favorite mode of communication for programmers. If you like someone's work, send them an email and ask for 1 or 2 tips. I've found when I email great programmers, their responses are usually short and to the point. That's not because they don't want to help, it's just that they're busy and use time effectively. Keep your emails brief and specific and they can be of great aid.

6. Enlist a Friend. If you excercise with someone else, you burn 50% more calories on average. Likewise, if you learn programming with a friend, you'll learn 50% faster. That's a significant time savings. It's also more fun. You must have a friend who has a similar interest as you in programming. Why not suggest that you get serious about learning it together?

Hopefully you'll find some of these tips useful. Feel free to email me if you need a first mentor (breck7 at google's email service). I'm not very good yet, but I may be able to help.

Notes

1. That exercise percentage is a guess, but sounds right to me.

Do you think in Orders of Magnitude? You should.

If you think in orders of magnitude you can quickly visualize how big a number is and how much effort it would take to reach it.

Orders of magnitude is a way of grouping numbers. The numbers 5, 8 and 11 are all in the same order of magnitude. The numbers 95, 98 and 109 are in the same order of magnitude as well, but their order of magnitude is one order of magnitude greater than 5, 8, 11.

Basically, if you multiple a number by 10, you raise it one order of magnitude. If you've ever seen the scary looking notation 5x10^2, just take the number five and raise it 2 orders of magnitude (to 500).

Think of orders of magnitude as rough approximations. If you want the number 50 to be in the same order of magnitude as the number 10, you can say that "it's roughly in the same order of magnitude" or that "it's about half an order of magnitude bigger". Don't worry about being exact.

Orders of magnitude is a great system because generally there's a huge difference between 2 numbers in different orders of magnitude. Thus to cross from one order of magnitude to the next, a different type of effort is required than to simply increment a number. For example, if you run 2 miles each day and then decide to run one more, 3 total, it should be easy. But if you decided to run one more order of magnitude, 20 miles, it would take a totally new kind of effort. You'd have to train longer, eat differently, and so forth. To go from 2 to 3 requires a simple approach, just increase what you're doing a bit. To go from 2 to 20, to increase by an order of magnitude, requires a totally different kind of effort.

A Business Example

Let's do a business example.

Pretend you started a business delivering pizza. Today you have five customers, make 5 pizzas a week, and earn $50 revenue per week.

You can keep doing what you're doing and slowly raise that to 6 customers, then 7 and so on. Or you can ask yourself, "How can I increase my business an order of magnitude?"

Going from 5 to 50 will take a different type of effort than just going from 5 to 6. You may start advertising or you might create a "Refer a Customer, get a free pizza" promotion. You might have to hire a cook. Maybe lower your price by $2.

Imagine you do all those things and now have 50 customers. How do you get to 500?

Now you might need a few employees, television advertisements, etc.

Growing a business is the process of focusing like a laser on the steps needed to reach the next order of magnitude.

Here are some more examples of orders of magnitude if it's still not clear:

Bill Gates has approximately $50,000,000,000. Warren Buffett has $40,000,000,000. For Warren to match Bill, he merely has to make a few more great investments and hope Microsoft's stock price doesn't go up. He does not have to increase his wealth an order of magnitude. I on the other hand, have $5 (it was a good month). For me to become as rich as BillG, I have to increase my wealth 10 orders of magnitude. That means that I'd have 10 different types of hard challenges to overcome to match BillG's wealth.

Going from $5 to $50 may mean just working a bit and could be accomplished in a day. Going from $50 to $500 would mean working a few days. Going from $500 to $5,000 might mean getting a job that pays more. Going from $5,000 to $50,000 would mean getting a job that pays more, saving more, and doing that for a longer period. Going from $50,000 to $500,000 might mean doing all that, plus making some good investments. ... and so forth.

-If your room is 200 square feet, the world is 13 orders of magnitude greater than your room. -Google indexes 10,000,000,000 pages. This site is 10 pages. There are 9 orders of magnitude more pages in the Google Index. -Facebook has 350 million users. Dropbox has 3 million. Facebook has 2 orders of magnitude more users. -The population of California is about 35 million. The population of the US is one order of magnitude bigger, about 300 million. The population of China is about 4 times that of the U.S. at 1,300,000, which is less than an order of magnitude difference. -Shaq is about 1 order of magnitude taller than a newborn, but besides that height is much more narrowly distributed. Everyone is within the same order of magnitude tall.

Links

WolframAlpha

Thanks to Mairi and Andrew Kitchell for providing feedback.

Imagine you are eating dinner with 9 friends and you all agree to play Credit Card Roulette. Credit Card Roulette is a game where everyone puts their credit card in a pile and the server randomly chooses one and charges the whole meal to it.

Imagine you are playing this game with your own friends. Pause for a second and picture it happening.

...

What did you see?

I bet you saw one person's card get picked and that person was sad and everyone else laughed.

Wrong!

This is not what really happened! In reality, despite the fact that you observed only one's person card getting picked, in reality everyone's card got chosen.

In reality, when you played the game, the world split into 10 paths, and every person's card got picked in one of those paths. You only observed one path, but trust me, there were 9 others.

This is a simple example of the many worlds law. You probably were not taught the many worlds law in school, which is a shame. It's one of the most important laws in the world.

Notes

1. I love this game because I don't have a credit card
2. You can benefit greatly from understanding the many worlds law. Take solace in the fact that somewhere out there you won the lottery and are drinking a pina colada on your private island right now.
3. The many worlds law could very well be wrong. There could be just 1 world. There could be 42. I don't think about that much. There may be no god, but betting there is one has benefits.
4. I called it the many worlds "law" because I don't want to use the word theory or hypothesis. Theory and hypothesis are too linked in people's minds with uncertainty, and some ideas, like evolution and many worlds, have way too much supporting evidence to leave any room for uncertainty, in as much as we can be uncertain about something.
5. One of the most important laws in most worlds, anyway.

Do you want to become a great coder? Do you have a passion for computers but not a thorough understanding of them? If so, this post is for you.

Saying #1: 10,000 Hours

There is a saying that it takes 10,000 hours of doing something to master it.

So, to master programming, it might take you 10,000 hours of being actively coding or thinking about coding. That translates to a consistent effort spread out over a number of years.

Saying #2: No Speed Limit

There is another saying that I just read, which inspired me to write this, that says "there is no speed limit".

In that post, Derek Sivers claims that a talented and generous guy named Kimo Williams taught him 2 years worth of music theory in five lessons. I have been learning to program for 2 years, and despite the fact that I've made great progress, my process has been slow and inefficient.

I did not have a Kimo Williams. But now that I know a bit, I'll try and emulate him and help you learn faster by sharing my top 12 lessons.

I'll provide the tips first, then if you're curious, a little bit more history about my own process.

The 12 Tips

1. Get started. Do not feel bad that you are not an expert programmer yet. In 10,000 hours, you will be. All you need to do is start. Dedicate some time each day or week to checking things off this list. You can take as long as you want or move as fast as you want. If you've decided to become a great programmer, youve already accomplished the hardest part: planting the seed. Now you just have to add time and your skills will blossom. If you need any help with any of these steps, feel free to email me and Ill do my best to help.

2. Dont worry. Do not be intimated by how much you dont understand. Computers are still largely magic even to me. We all know that computers are fundamentally about 1s and 0s, but what the hell does that really mean? It took me a long time to figure it out--it has something to do with voltages and transistors. There are endless topics in computer science and endless terms that you won't understand. But if you stick with it, eventually almost everything will be demystified. So don't waste time or get stressed worrying about what you don't know. It will come, trust me. Remember, every great programmer at one time had NO IDEA what assembly was, or a compiler, or a pointer, or a class, or a closure, or a transistor. Many of them still dont! That's part of the fun of this subject--you'll always be learning.

3. Silicon Valley. Simply by moving to Silicon Valley, you have at least: 10x as many programmers to talk to, 10x as many programming job opportunities, 10x as many programming meetups, and so on. You don't have to do this, but it will make you move much faster. The first year of my programming career was in Boston. The second year was in San Francisco. I have learned at a much faster pace my second year.

4. Read books. In December of 2007 I spent a few hundred dollars on programming books. I bought like 20 of them because I had no idea where to begin. I felt guilty spending so much money on books back then. Looking back, it was worth it hundreds of times over. You will read and learn more from a good $30 paperback book than dozens of free blogs. I could probably explain why, but its not even worth it. The data is so very clear from my experience that trying to explain why it is that way is like trying to explain why pizza tastes better than broccoli: Im sure there are reasons but just try pizza and you'll agree with me.

5. Get mentors. I used to create websites for small businesses. Sometimes my clients would want something I didnt know how to do, simple things back then like forms. I used to search Google for the answers, and if I couldnt find them, I'd panic! Dont do that. When you get in over your head, ping mentors. They dont mind, trust me. Something that youll spend 5 hours panicking to learn will take them 2 minutes to explain to you. If you dont know any good coders, feel free to use me as your first mentor.

6. Object Oriented. This is the "language" the world codes in. Just as businessmen communicate primarily in English, coders communicate primarily in Object Oriented terms. Terms like classes and instances and inheritance. They were completely, completely, completely foreign and scary to me. Theyd make me sick to my stomach. Then I read a good book(Object Oriented PHP, Peter Lavin), and slowly practiced the techniques, and now I totally get it. Now I can communicate and work with other programmers.

7. Publish code. If you keep a private journal and write the sentence The car green is, you may keep writing that hundreds of times without realizing its bad grammar, until you happen to come upon the correct way of doing things. If you write that in an email, someone will instantly correctly you and you probably won't make the mistake again. You can speed up your learning 1-2 orders of magnitude by sharing your work with others. Its embarrassing to make mistakes, but the only way to become great is to trudge through foul smelling swamp of embarrassment.

8. Use github. The term version control used to scare the hell out of me. Heck, it still can be pretty cryptic. But version control is crucial to becoming a great programmer. Every other developer uses it, and you can't become a great programmer by coding alone, so you'll have to start using it. Luckily, you're learning during an ideal time. Github has made learning and using version control much easier. Also, Dropbox is a great tool that your mom could use and yet that has some of the powerful sharing and version control features of something like git.

9. Treat yourself. Build things you think are cool. Build stuff you want to use. Its more fun to work on something you are interested in. Programming is like cooking, you don't know if what you make is good until you taste it. If something you cook tastes like dog food, how will you know unless you taste it? Build things you are going to consume yourself and you'll be more interested in making it taste not like dog food.

10. Write English. Code is surprisingly more like English than like math. Great code is easy to read. In great code functions, files, classes and variables are named well. Comments, when needed, are concise and helpful. In great code the language and vocabulary is not elitist: it is easy for the layman to understand.

11. Be prolific. You dont paint the Mona Lisa by spending 5 years working on 1 piece. You create the Mona Lisa by painting 1000 different works, one of them eventually happens to be the Mona Lisa. Write web apps, iPhone apps, Javascript apps, desktop apps, command line tools: as many things as you want. Start a small new project every week or even every day. You eventually have to strike a balance between quantity and quality, but when you are young the goal should be quantity. Quality will come in time.

12. Learn Linux. The command line is not user friendly. It will take time and lots of repetition to learn it. But again, its what the world uses, you'll need at least a basic grasp of the command line to become a great programmer. When you get good at the command line, its actually pretty damn cool. Youll appreciate how much of what we depend on today was written over the course of a few decades. And youll be amazed at how much you can do from the command line. If you use Windows, get CYGWIN! I just found it a few months ago, and it is much easier and faster than running virtualized Linux instances.

That's it, go get started!

Actually, I'll give you one bonus tip:

1. Contact me. My email address is breck7 at Google's mail service. Feel free to ping me for personal help along your journey, and I'll do my best to lend a hand.

My Story, briefly

Two years ago, in December 2007, I decided to become a great programmer. Before then, I had probably spent under 1,000 hours "coding". From 1996 to 2007, age 12 to age 23, I spent around 1,000 hours "coding" simple things like websites, MSDOS bat scripts, simple php functions, and "hello world" type programs for an Introduction to Computer Science class. Despite the fact that I have always had an enormous fascination with computers, and spent a ton of time using them, I was completely clueless about how they worked and how to really program.

(If you're wondering why didn't I start coding seriously until I was 23 and out of college there's a simple and probably common reason: the whole time I was in school my goal was to be cool, and programming does not make you cool. Had I known I would never be cool anyway, I probably would have started coding sooner.)

Finally in December 2007 I decided to make programming my career and #1 hobby. Since then I estimate I've spent 20-50 hours per week either coding or practicing. By practicing I mean reading books about computers and code, thinking about coding, talking to others, and all other related activities that are not actually writing code.

That means I've spent between 2,000-5,000 hours developing my skills. Hopefully, by reading these tips, you can move much faster than I have over the past 2 years.

Links

• Github
• Dropbox
• Stackoverflow - when you need help, and eventually where you can give help
• Cygwin

Notes

1. The saying that it takes 10,000 hours to master something may or may not be true but is indisputably popular (which is often an attribute of true ideas).
2. I added the quotes around "coding" when describing my past experience because it was simple stuff, and it felt funny funny calling it coding just as it would sound funny calling a 5 year old's work "writing".
3. I still have a long way to go to become a "great programmer", 2-4 more years I'd say.

What would happen if instead of writing about subjects you understood, you wrote about subjects you didn't understand? Let's find out!

Today's topic is linear algebra. I know almost nothing about vectors, matrices, and linear algebra.

I did not take a Linear Algebra course in college. Multivariable calculus may have done a chapter on vectors, but I only remember the very basics: it's a size with a direction, or something like that.

I went to a Borders once specifically to find a good book to teach myself linear algebra with. I even bought one that I thought was the most entertaining of the bunch. Trust me, it's far from entertaining. Haven't made it much further than page 10.

I bet vectors, matrices, and linear algebra are important. In fact, I'm positive they are. But I don't know why. I don't know how to apply linear algreba in everyday life, or if that's something you even do with linear algebra.

I use lots of math throughout the day such as:

• Addition/subtraction when paying for things
• Multiplication when cooking for 6 roommates
• Probability when deciding whether to buy cell phone insurance
• Calculus when thinking about the distance needed to break fast while biking
• Exponents and logs when analyzing traffic graphs and programming

But I have no idea when I should be using vectors, matrices, and other linear algebra concepts throughout the day.

There are lots of books that teach how to do linear algebra. But are there any that explain why?

Would everyone benefit from linear algebra just as everyone would benefit from knowing probability theory? Would I benefit?

I don't know the answer to these questions. Fooled by Randomness revealed to me why probability is so incredibly important and inspired me to master it. Is there a similar book like that for linear algebra?

I guess when you write about what you don't know, you write mostly questions.

What books have changed your life? Seriously, pause for a few minutes and think about the question. I'll share my list in a moment, but first come up with yours.

Do you have your list yet? Writing it down may help. Try to write down 10 books that you think have most impacted your life.

Take all the time you need before moving on.

Are you done yet? Don't cheat. Write it down then continue reading.

Okay, at this point I'm assuming you've followed instructions and wrote down your list of 10 books.

Now you have one more step. To the right of each book title, write "fiction" or "nonfiction". You can use the abbreviations "F" and "NF" if you wish.

You should now have a list that looks something like mine:

• How to Read a Book - NF
• Never Eat Alone - NF
• Fooled by Randomness - NF
• How to Win Friends and Influence People - NF
• Snowball - NF
• Influence - NF
• Object Oriented PHP - NF
• Life of Pi - F
• Lord of the Flies - F
• The Illiad - F

Now, count the NF's. How many do you have? I have 7. So 7 out of the 10 books that I think have most impacted my life are non-fiction. Therefore, if I have to guess whether the next book I read that greatly impacts my life will be fiction or nonfiction, my guess is it will be nonfiction.

What's your list? Do you think the next book that will greatly impact your life will be fiction or non-fiction?

Share your results here.

Notes:

1. I read about equal amounts fiction and nonfiction. So on average, I get greater return from nonfiction reading.
2. Reading fiction is a more enjoyable form of entertainment.
3. This essay is in response to a comment I read a while back on HackerNews that got me thinking about the subject.

...when you don't get what you want.

How many times have you struggled towards a goal only to come up short? How many times have bad things happened to you that you wish hadn't happened? If you're like me, the answer to both of those is: a lot.

But luckily you always get something when you don't get what you want. You get experience. Experience is data. When accumulated and analyzed, it can be incredibly valuable.

To be successful in life you need to have good things happen to you. Some people call this "good luck". Luck is a confusing term. It was created by people who don't think clearly. Forget about the term "luck". There is not "good luck" and "bad luck". Instead, "good things happen", and "bad things happen". Your life is a constant bombardment of things happening, good and bad. Occasionally, despite making bad decisions steadily, some people have good things happen to them. But in most cases to have good things happen to you, you've got to make a steady stream of good decisions.

You've got to see patterns in the world and recognize cause and effect. You've got to think through your actions and foresee how each action you take will affect the chances of "good things happening" versus "bad things happening" down the line.

When you're fresh out of the gate, it's hard to make those predictions. You just don't have any data so you can't analyze cause and effect appropriately. But once you're out there attempting things, even if you screw up or don't get what you want, you get experience. You get data to use to make better decisions in the future.

Decided to blog again. I missed it. Writing publicly, even when you only get 3 readers, two of which are bots and the other is your relative, is to the mind what exercise is to the body. It's fun and feels good; especially when you haven't done it in a while.

Also decided to go old school. No Wordpress or Tumblr, Blogger or Posterous. Instead, I'm writing this on pen and paper. Later I'll type it into HTML using Notepad++, vim, or equivalent(EDIT: after writing this I coded my own, simple blogging software called brecksblog). It will just be text and links. Commenting works better on hackernews, digg, or reddit anyway.

Hopefully these steps will result in better content. Pen and paper make writing easier and more enjoyable, so hopefully I'll produce more. And the process of typing should serve as a filter. If something sucks, I won't take the time to type it.

I'm writing to get better at communicating, thinking, and just for fun. If anyone finds value in these posts, that's an added bonus.

Written 11/30/2009