Org Web Adapter

Editing pages/i_could_do_that_in_a_weekend.org

:PROPERTIES:
:ID:       09759378-7d9c-4120-aa94-8caa206e5016
:END:
#+TITLE: I Could Do That in a Weekend

- source :: https://danluu.com/sounds-easy/
- tags :: [[id:c318da5d-84db-460f-807a-597a48cbab02][Hacker News]]

* 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