You are not Google. You are not Netflix

I worked on the floor with two teams. One (ours) built our apps and infrastructure the correct way. JIT. Get it working, get it working correct, get it working fast. And given the scale, it did wonders.<p>The other team talked big and gave demos to higher ups and their higher ups and their higher ups. Web scale baby. And with that came the galactic infrastructure and all the buzzword needed in order to run it.<p>About 6 months later, they quit. They had spent their whole budget on astronaut architecture, that the didn&#x27;t have any money or time left to build the apps that were supposed to run on said infrastructure.<p>&quot;You are not FANG&quot;. But even if you are, JIT development.

I don’t think one needs to plan on being Facebook scale from the beginning, but I do think there is some consideration of scalability that needs to be considered from the start. Maybe you don’t need to think 10 steps ahead but you should at least have plans for 3 or 4 steps ahead of you don’t want to have to rearchitect everything from scratch in a year.<p>It might not be strictly necessary to containerize your app, for example, if you’re just running it on a single ec2 instance behind a load balancer, but it’s not a huge amount of work up front and there are some benefits and it means it’ll make it easier to move to ecs or k8s later if you need to.

A related issue is also focusing so much on the tech (and often how well the product&#x2F;service can scale) that you forget to do much marketing and end up delaying the product&#x2F;service for months as a result. Or worse still, never actually finish building it at all.<p>Definitely follow the old get it working, then correct, then fast methodology, at least for projects without many billions of dollars in resources.

I think this article is basically right, but I want to provide a personal perspective on this:<p>This is why I have found that I prefer working on a widely used product at one of these big companies. I find the most enjoyment in thinking through how to make products work acceptably for huge numbers of users, or how to pick the needles I need out of enormous data sets, or how to structure a codebase such that hundreds of people can contribute to it every day. I have found it very demoralizing in my career when I&#x27;ve been told not to think of user or data or codebase scaling considerations because YAGNI. I&#x27;ve lost a number of debates against just-get-it-done ethos, and mostly I think I was right to lose; I was wrong, YAGNI was right. But the rightness of YAGNI for those products didn&#x27;t make me enjoy the work any more.<p>So I think the article is right that most companies don&#x27;t have these scaling problems, but for me, I want to work for the ones that do. I think this is probably a common sentiment.

Two articles on this topic:<p>You are Not Google (my favorite): <a href="https:&#x2F;&#x2F;blog.bradfieldcs.com&#x2F;you-are-not-google-84912cf44afb" rel="nofollow">https:&#x2F;&#x2F;blog.bradfieldcs.com&#x2F;you-are-not-google-84912cf44afb</a><p>A piece from my Notes to a Young Software Engineer that likens engineering media to a bazaar, not a mirror of the industry:<p>Beware Engineering Media:<p><a href="https:&#x2F;&#x2F;www.nemil.com&#x2F;on-software-engineering&#x2F;beware-engineering-media.html" rel="nofollow">https:&#x2F;&#x2F;www.nemil.com&#x2F;on-software-engineering&#x2F;beware-enginee...</a><p>(Martin Fowler&#x27;s YAGNI article is also great)

&gt; A developer’s skill is measured in one parameter: how well he writes code.<p>While this could be a valid viewpoint, one thing I’d caution against is that this type of measurement inevitably leads to the commoditization of developers. Rating skill on a single point will lead to “you’re only worth what this metric says you are worth” and eventually to constant competition between developers instead of cooperation. At least that’s the experience I had in such positions during my younger years.

There&#x27;s a lot to be said about org design. Org design has to be right for the size of the company and the velocity you need to succeed. For example, when a start-up that is about to take off like a rocket ship, it needs to make a conscious change in org design to facilitate both strong foundation building as well as fast feature building with a layer of domain-specific platform&#x2F;frameworks being curated to keep the leverage high and hence velocity high without blowing the headcount budget.<p>Ideally orgs should sow the seeds of this 3-layer org (and corresponding tech architecture) design from the beginning and consciously choose to scale the investments in those layers as needed in each growth spurt.<p>Usually people tend to shortchange this advice by thinking they can make the same 10 people do the work in all the layers. And that may be ok when you are small. But specialization in systems vs app-frameworks vs app feature development is highly important for velocity. Also your hiring loops and the &quot;hiring bar&quot; has to be different for these roles. And usually the hiring pipeline depth and churn rate is different for these roles. So, creating a structure where impedances are matched correctly between input and output, so to speak, is immensely helpful for achieving high productivity and cost efficiency.

Its all about execution and delivery. I&#x27;m pretty happy to have left the old days of corporate committee projects behind to do my own stuff. I&#x27;m also financially better off.

Kubernetes, Machine Learning, Microservices, Service-Mesh, are the things that immediately come to (my) mind from such discussions with start-up dev-teams.<p>But somehow all of these are at least a few years old meanwhile. Could it be that the buzzword bingo we experienced in the last years has already peaked or why haven&#x27;t we seen any new nonsense[1] (at least nothing that I&#x27;m aware that is not at least 24 months old)?<p>[1] it doesn&#x27;t have to be nonsense but as the article suggests, not everyone is FAANG.

Having seen the inside of both good and bad product organizations, culture beats process any day of the week. Get the core values right, hire smart people and everything will fall into place.<p>A corollary is that cargo-culting well-developed processes generally means you’re copying from a company with a culture that couldn’t address those functions organically. So you may actually just be lifting an over-engineered process designed to address a cultural weakness at the original company.

Because we’ve railed on “programmers” for so long everyone wants to be a “software engineer” which more often than not leads to equally insane architectures. No you don’t need multi-region availability. No you don’t need to rewrite this in rust. No you don’t need a multi-master db setup. No you don’t need graphql.

One impression that occurred to me from reading this article, is this excerpt:<p>&quot;Why try to be like others if you are condemned to being yourself&quot; Link: <a href="https:&#x2F;&#x2F;mutterichbindumm.tumblr.com&#x2F;post&#x2F;92142897112&#x2F;funeral-march-for-ludwig-ii-king-of-bavaria" rel="nofollow">https:&#x2F;&#x2F;mutterichbindumm.tumblr.com&#x2F;post&#x2F;92142897112&#x2F;funeral...</a>

What&#x27;s up with the title?