Paul Graham: Lessons from a company

Paul Graham has recently published an essay about start-ups. As usual there are a lots of goodies in there; but one paragraph I want to post here.

I spent a year working for a software company to pay off my college loans. It was the worst year of my adult life, but I learned, without realizing it at the time, a lot of valuable lessons about the software business. In this case they were mostly negative lessons:

1. don't have a lot of meetings
2. don't have chunks of code that multiple people own
3. don't have a sales guy running the company
4. don't make a high-end product
5. don't let your code get too big
6. don't leave finding bugs to QA people
7. don't go too long between releases
8. don't isolate developers from users
9. don't move from Cambridge to Route 128

But negative lessons are just as valuable as positive ones. Perhaps even more valuable: it's hard to repeat a brilliant performance, but it's straightforward to avoid errors.

I agree with most of them wholeheartedly... with a few exceptions. One of them is the code ownership. I feel like I'm in a chains if I can't correct mistakes or simply improve the code written by someone else. I also don't have any problems if someone does the same to my code. At least I think so because in the current project I can rememeber only one occasion when that happen: people are too busy churning out their own new code. The other lesson I'm not sure I agree with is the one about moving from Cambridge to Route 128. But that's because I'm not sure I get it. Does it mean: "stay close (physically) to areas with high densities of smart people"? If so, then I agree.