rmenke

Think of it less as "Object-Oriented" and more as "Message-Oriented" and things become clear. Every object has a vocabulary of messages it can respond to. The only contract you have with the object is what it can do, not how it does it; therefore, the supplier of the object is free to implement algorithms as he sees fit. (60 words)

Bonus analogy:

The web itself is object-oriented. You ask a server to return a resource for a given URL; what server it is (Apache; IIS) and how the content is generated (static page; CGI; PHP) is unnecessary for the conversation.

Depends on your expected rate of growth, and how much time you expect each developer to waste in bootstrapping and mentoring. When you consider getting your third developer, then is the time to start thinking about documentation processes (as in managed and computer-accessible, not Z or UML).

Having been the second in a few startups, I can tell you that not having any sort of documentation is annoying. Do not expect anyone to read your code and understand how your mind works: if you don't document, you will have to sacrifice a significant amount of time training the new employee. You'll have to hire during a lull, and in a startup there's never a lull. As usual, Fred Brooks said it first.

Finally, Twitter is a good example of what acting first then designing second can achieve: unfixable scaling issues. Don't do that.

It really depends on the language you plan to learn. If the language has a de facto IDE, you would be best served by that. Otherwise, Emacs offers a number of language-directed enhancements that help a lot with boilerplate work.

(And c'mon, MacVim and Emacs.app? Just open Terminal.app and run Emacs or vim directly! Both are pre-installed on OS X.)