I Could Do That in a Weekend

- source :: https://danluu.com/sounds-easy/

Notes

Building Google is not trivial

#+BEGIN_QUOTE

Considering how much of Google's $500B market cap comes from search, and how much money has been spent by tens (hundreds?) of competitors in an attempt to capture some of that value, *it seems plausible to me that search isn't a trivial problem.*

#+END_QUOTE

Increasing performance reduces cost

#+BEGIN_QUOTE

There's also a wide body of research that's found that decreasing latency has a roughly linear effect on revenue over a pretty wide range of latencies for some businesses. *Increasing performance also has the benefit of reducing costs.* Businesses should keep adding engineers to work on optimization until the cost of adding an engineer equals the revenue gain plus the cost savings at the margin. This is often many more engineers than people realize.

#+END_QUOTE

Not impossible to build or improve with small team

#+BEGIN_QUOTE

If you talk to people in almost any field, you'll hear stories about how people wildly underestimate the complexity of the problems in the field. *The point here isn't that it would be impossible for a small team to build something better than Google search.* It's entirely plausible that someone will have an innovation as great as PageRank, and that a small team could turn that into a viable company.

#+END_QUOTE

As long as adding a person increases revenue more than the cost, keep adding

#+BEGIN_QUOTE

That fifty person billing team is totally worth it, beyond a certain size. And then there's sales, which most engineers don't even think of2; the exact same line of reasoning that applies to optimization also applies to sales -- *as long as marginal benefit of adding another salesperson exceeds the cost, you should expect the company to keep adding salespeople*, which can often result in a sales force that's larger than the engineering team

#+END_QUOTE

Fallacy of the Happy Path - [[id:995d2183-ebcb-4c45-8f00-1b7aea20854a][Postmortem Lessons]]

#+BEGIN_QUOTE

This reminds me of a common fallacy we see in unreliable systems, where people build the happy path with the idea that the happy path is the “real” work, and that error handling can be tacked on later.

#+END_QUOTE