Well its easier to say what not to do than what to do, so here's some of that: - cargo-cult buzzphrase/keyword engineering: saying "we should use <thing>, <coo

Well its easier to say what not to do than what to do, so here's some of that: - cargo-cult buzzphrase/keyword engineering: saying "we should use <thing>, <cool_company_a> and <cool_company_b> use <thing>". If you find yourself debating technology where entire paragraphs go by without real metrics, then you're really social-signaling not engineering. - scaling for the sake of scaling: there is a vast grab bag of available tools and techniques to scale, but for any given business the right answer is to take a pass on most of it. the overwhelming majority will either be unnecessary or even flat out counter-productive. the easiest way to separate what to scale vs. what to hack/ignore is asking yourself "is this what my users/customers love/pay me for, or something a grad student would love to spend a semester on". - timing context matters, a lot: whats "right" for scaling a young company with very few engineers (and probably zero ops pros) will be a different answer than whats "right" for scaling a millions-of-users/millions-in-revenue company. whats right for twitter is wrong for a young company, almost by definition. - "throw hardware at it" (the wrong way): throwing hardware at a problem is the best way to solve scaling problems, but only if you do it right. stateless request-response across large pools of identical servers scales better than anything else. however "give it a dedicated server" leaves you with a mine field of one and two-off setups that only scales into the dozens-of-servers before it starts to choke your business.