3 ms·

I acknowledge the fact that a product is more likely to be successful if it is made simpler. And I face the difficulty of trying to create a complex product eve

by Aegean 17y ago

I acknowledge the fact that a product is more likely to be successful if it is made simpler. And I face the difficulty of trying to create a complex product every day. Hence his advice: "Are you considering starting up a business because you wish to work on wonderfully interesting technical problems all of the time? Stop now — Google is hiring, go get a job with them. 90% of the results of your business, and somewhere around 90% of the effort, are caused by non-coding activities" But... then who is eligible to build a complex product? Like writing a database from scratch, or some other complex piece of work. I think a startup should also be able to do it somehow.

tptacek 17y ago
What's your point? He's not saying every company should work this way. He's saying "this is a way to do it that works when you have other time constraints". In Patrick's case, doing it this way got him from full-time job to full-time startup entrepreneur without taking a dime of money from anybody but his customers. We'll see what he comes up with after a few years of doing it full time. Finally, writing a database from scratch? Crappy business to get in to even if you're full time!
nostrademons 17y ago
I thought that was the best line in the piece, because it's so true. Probably 90% of the engineers at Google are there because they want to work on wonderfully interesting technical problems all the time, and don't want to deal with all the other bullshit that comes from running a company. And I suspect that a major part of the reason my startup failed was because I wanted to work on wonderfully interesting technical problems yet also wanted to get rich. There're a limited number of problems that people will pay you to solve, and most of them are boring. As for who is eligible to build a complex product? Nobody. If you set out to build a complex system from the start, it invariably won't work at the end. Remember Gall's Law: http://en.wikipedia.org/wiki/Galls_law http://en.wikipedia.org/wiki/Galls_law Before you cite counterexamples like Linux or Google, it's worth considering what they looked like when they started. Linux started as a terminal emulator that would spit back "ababa" when you turned on the computer. Google's early webserver was a dozen or so source files that looked vaguely like Tornado, except that instead of having all those webframeworkey goodness like regexp-based dispatch rules and templates, it would just issue "prints" on the file descriptor for the user's connection. If you want to write a database from scratch, you should start with some sort of basic persistent key/value store. Then give your values a column-like substructure. Then figure out how to index it. Then figure out how to index it based on multiple columns. Then figure out how to handle joins and sorts. Then slap an SQL parser on top of it, and you'll have something similar to MySQL c. late 1990s. Then endure all the laughs as people say you're not a "real" database, and put in 10 years of incremental improvements while you add transactions, and better SQL compliance, and query optimizers, and wire protocols, and replication, and clustering, and all that stuff.

by Aegean 17y ago

tptacek 17y ago

What's your point? He's not saying every company should work this way. He's saying "this is a way to do it that works when you have other time constraints". In Patrick's case, doing it this way got him from full-time job to full-time startup entrepreneur without taking a dime of money from anybody but his customers. We'll see what he comes up with after a few years of doing it full time. Finally, writing a database from scratch? Crappy business to get in to even if you're full time!

nostrademons 17y ago

I thought that was the best line in the piece, because it's so true. Probably 90% of the engineers at Google are there because they want to work on wonderfully interesting technical problems all the time, and don't want to deal with all the other bullshit that comes from running a company. And I suspect that a major part of the reason my startup failed was because I wanted to work on wonderfully interesting technical problems yet also wanted to get rich. There're a limited number of problems that people will pay you to solve, and most of them are boring. As for who is eligible to build a complex product? Nobody. If you set out to build a complex system from the start, it invariably won't work at the end. Remember Gall's Law: http://en.wikipedia.org/wiki/Galls_law http://en.wikipedia.org/wiki/Galls_law Before you cite counterexamples like Linux or Google, it's worth considering what they looked like when they started. Linux started as a terminal emulator that would spit back "ababa" when you turned on the computer. Google's early webserver was a dozen or so source files that looked vaguely like Tornado, except that instead of having all those webframeworkey goodness like regexp-based dispatch rules and templates, it would just issue "prints" on the file descriptor for the user's connection. If you want to write a database from scratch, you should start with some sort of basic persistent key/value store. Then give your values a column-like substructure. Then figure out how to index it. Then figure out how to index it based on multiple columns. Then figure out how to handle joins and sorts. Then slap an SQL parser on top of it, and you'll have something similar to MySQL c. late 1990s. Then endure all the laughs as people say you're not a "real" database, and put in 10 years of incremental improvements while you add transactions, and better SQL compliance, and query optimizers, and wire protocols, and replication, and clustering, and all that stuff.