Paul Graham is a great writer and has written many great essays. His most recent makes the argument that humans are "naturally" suited to not having bosses and not working in large companies (he talks about the difficulties of groups over 8 people). I agree that there are many downsides to working at companies and I could certainly write about the upsides and why I love what I'm doing at Google, but that wouldn't really be disagreeing with Paul. I don't take him to be saying that starting your own company is always better, just that you should be aware that organizations of greater than 8 people have a cost that should be taken into account. He talks about it as being a "restrictiveness" that takes toll on creativity and says that it is a particular problem for engineers. Which brings us to his dismissal of why others won't feel the pinch:"The restrictiveness of big company jobs is particularly hard on programmers, because the essence of programming is to build new things. Sales people make much the same pitches every day; support people answer much the same questions; but once you've written a piece of code you don't need to write it again. So a programmer working as programmers are meant to is always making new things. And when you're part of an organization whose structure gives each person freedom in inverse proportion to the size of the tree, you're going to face resistance when you do something new."I don't agree with this characterization of programmers as more creative than others. It is true that you never have to write the same code again (though how many times have you written authentication or a wrapper around an authentication class) but that doesn't mean that everything you write flows out of a brand new non-linear creative endeavour any more than a sales person's pitch is entirely new. Sales people sell services that have never existed (and then they get engineers to code this selling process into an online flow and move on to selling new stuff). Support folks get entirely new questions all the time (and then get engineers to code a system for responding to the easy stuff in an automated way). These folks that Paul singles out as being less restricted (or less "meant" to create) do all sorts of breathtaking new things too. I've seen support folks handle a very angry person with an issue with a brand new type of product by creating solution to the user's problem and explaining it in a way that is brilliant. I've seen sales folk come up with entirely new types of business arrangements or finding an elegant "in" to a relationship. It is certainly true that both of these groups do a bunch of work that is less creative, but so do engineers, even at startups (gasp!). These are the things that follow the creative move, things like debugging, unit testing, perfecting UI, etc. A good startup as well as a good big company, will value creation (and the stuff after the creation) in all of its people, not just the ones that are from Paul's chosen tribe.