1. Continuous Integration, use it.
2. All code must have tests. Lower coverage == CI fail
3. Tests must run fast. Slower average test speed == CI fail
4. Code quality regression == CI fail.
5. Vagrant and Chef for your development environment. A new dev machine is a “git clone” and “vagrant up” away. (this means good seed data!)
6. Any and All strings that a user could ever see must be internationalized, resource file in {native language} first, of course.
7. Github is the hub: pull requests for code review. One other person signs off on code before it goes to staging
8. Deployment, Rollback, and Scaling are all one command away.
9. Build for horizontal scaling.  Start with multiple instances of every server/database/application/service type. Plan on your servers/apps/services being fungible, unreliable, and innumerable. Discovery over configuration. (etcd, zookeeper, ironfan, doozerd)
10. Faster response to the user is always better. Anything that doesn’t need an immediate response, queue it up and do it  in the background. Cache and pre-compute as much as possible.
11. If someone else has made a library that does most of what you want, use it. (Submit patches so it does all of what you want)
12. If you can abstract the solution out of the app into a standalone library, do so and make it open source. Open source is the great code review in the sky. More eyes means better code.
13. A service is better than a solution. A solution is better than a hack. A hack is better than nothing at all.
14. Done is the engine of more.
15. Perfect is the enemy of the good.

“Men wanted for hazardous journey. Small wages. Bitter Cold. Long months of complete darkness. Constant danger. Safe return doubtful. Honour and recognition in case of success.”

— Ernest Shackleton.

This is the perhaps most accurate description of a job at an actual startup. If this sounds like something you’d be interested in, read on.

Remember, Most startups fail. Failing, however, is a crucial step towards not failing.

General advice: read as many of Paul Graham‘s essays as you possibly can. from the top down. Paul Graham has literally helped several hundred startups get off the ground. Some essays will not really be useful right now, but the ideas in there are generally very very good. Check out news.ycombinator.com on a fairly regular basis. Read the comments, lookup every word and acronym you don’t know. Watch these videos

Try to answer these questions as quickly and cheaply as possible:

1. what is the addressable market size? meaning, in the world, right now, how many people would pay for this? How many people would be interested to the point of being regular visitors?
   this is intended to give some sort of idea about how big the opportunity is.Use tools like quantcast.com to help evaluate how big the audience is that your product might reach. Imagine if you are making a management tool for independant contractors: How many people visit http://www.contractortalk.com/ on a monthly basis? that’s about your addressable market.
2. figure out the minimum viable product. Try to get your product down to one sentence. Perhaps even one or two pages. (not counting boilerplate, like “about us”, “FAQ” etc.)Don’t get caught up in vision of the final product. No plan ever survives first contact with the customer. Try to get to the very essence of what it is that your idea does. It should literally be one sentence, or possibly less than a sentence. The minimum viable product for google was literally a place to type in text, hit enter, and get search results from a database of websites.When people think of ideas, they go from version 0 to version infinity almost immediately. You should never stop thinking about version infinity, the absolute pinacle of what it is that your idea could be, but, you should laser focus on version 0.1, the absolute minimum of what it is that your idea does. Literally, the one thing, that without it, your idea doesn’t exist, it’s still an idea. It really should be one thing. sometimes you can get away with two. sometimes.Then, you make the one thing and you show it to as many people as possible. Maybe you don’t even make it, you tell people online that you are going to make it, you setup a website where people can give you their emails so that you can tell them when you make it, and then, when you have their emails, you ask them about it, you get them involved, you show them mockups, get them to beta test, ask them to pay you for it upfront. the works. Your customers are your partners.
3. Fail often, fail fast, and fail cheaply.
   failure is the process of stumbling towards success. This means relentlessly testing assumptions that you have as quickly as possible, with as little downside as possible. the difficulty is figuring out how to test accurately yet also as cheaply as possible. thus, use what is already there to try to invalidate your assumptions. Think of it like science: you’ve got strong hunches that you want to prove correct, but you can’t be sure of them, and aren’t going to bet the farm until you’ve got a sure thing. The only way to be sure is to test it and be honest with yourself about the results.

How are you going to fail as fast as possible? Remove as many people, steps, and processes as possible from getting your idea in front of someone who doesn’t care about you. (Your family and friends are useless in this regard, insofar as they will not tell you that your idea is a stinker)

Crucially, if your idea happens to be related to computer and software in any way shape or form, learn how to program your computer. There are a ton of awesome resources out there to learn how to write software and for starting a business, but it can be daunting to try to separate the wheat from the chaff.

The two best languages at the moment are, in my humble opinion: ruby and javascript. Ruby because it is easy and understandable, yet also powerful, javascript because it is ubiquitous, interesting, and easy to play with: if you’ve got a browser, you can mess around with javascript. I’d look through each one below and see what seems like it’s your thing. Also, remember: it’s not that hard and more importantly there is no speed limit.

Free ruby stuff:

• tryruby.org
• awesome interactive web tutorial
• Ruby and Ruby on Rails ( ruby on rails is a framework used to make web applications with the ruby programming language)
• Excellent, not actually all that hard: Learn Ruby the Hard Way
• Silly, alot less hard. Why’s Poignant Guide to Ruby

Free javascript

• play with javascript online easily: jsfiddle.net/ (truly excellent resource to learn)
• Google Code Edu (probably a good place to start if you want to do javascript, as it covers HTML and CSS too)
• the standard javascript: Mozilla Javascript Guide
• also excellent, but not interactive: eloquentjavascript.net
• very nerdy,but damn, it’s good: Opera’s Introduction to Web Standards
• Node.js, it’s really awesome, basically, the same language for both the server and browser? amazing. nodebeginner.org
• Now, in terms of paid classes, I’d suggest Lynda.com, as I’ve used it in the past and it’s excellent.

At this point, you should be ready to start failing. Go forth, claim your destiny.

Stay tuned for the next installment of this multi-part series.

Empty space, often realized as indentation, is a common method to signifying meaning in programming languages. Python is famous for this, Haml uses indentation to represent the structure of HTML. I, for one, am not a fan.

In human language, information and meaning, codified, take the shape of syntax and semantics. Syntax being the framework within which the semantics can be parsed. I like to think of syntax as a protocol, the agreement we make to enable the exchange of meaning. English syntax enforces word order, whereas Latin requires declension and conjugation to provide a framework within which we can communicate. Syntax itself informs and modifies Semantics, subtle shifts in word order and conjugation change the meaning of a sentence. A set of words that violate the syntax of english are in essence almost meaningless aside from them self. If I were to take all the words in this paragraph, sort them  randomly, remove the spaces and all punctuation, the result would be gibberish. Additionally, syntactic elements, separated from the words they encompass are without meaning as well.  All of the spaces, punctuation and the order of the parts of speech of the words in the paragraph would also contain very little information at all.

With programming languages, so much of the same holds true: the syntax provides the framework through which the meaning of a program can be understood. My problem with considering whitespace as meaningful with regards to syntax and semantics is that for almost every language, including human language, whitespace has one purpose: token separation. It is only important because of what it is not. Let me try to provide a concrete example.

Above this line there are four spaces. This sentence on the other hand, has eight spaces. The spaces above are meaningless, because empty space itself is almost a purely syntactic element. It has absolutely no semantic value. Beyond that, it’s almost impossible for you to visual discern exactly how many spaces there are because typically the syntactic element we use to separate tokens is the very token you are trying to count.

Haml has many graces: it makes it very easy to whip up totally valid html in a flash and templating is a joy, however, it’s use of whitespace indentation to indicate html element nesting levels is maddening, precisely because it has radically overloaded the concept of emptiness and indentation. To give you an example of this degree of exactly how maddening it is, in one of the sentences above, between two words, there is a double space. Where is it? Can you see it by quickly scanning the document?

I’ve never been able to tinker in python, at least not in the same way that ruby lets me throw together things that just work anywhere I’ve got a text editor (that I can clean up later, naturally). I literally find myself cursing the emptiness. If programming is about expressiveness and power, I for one would not like to wield that ability with a void.