This is a comment I wrote a little while back, you can see the full context here, but the premise of the conversation was about how companies like Google and Facebook have a totally different set of requirements when hiring programmers than startups or smaller companies.
[...] Companies like FB, Google, and Amazon need to test programmers on data structures because certain structures work better in certain situations, and when their software engineers know which tools to use to optimize a process to run in 5μs instead of 10μs... well, let’s just say for a company running tens or hundreds of thousands of servers, every microsecond saved means less servers the company needs running. And less servers = more $$$.
But for most startups or mid sized companies it’s way more important that developers know how to get shit up and running, and less important the actual code they write to get there.
The problem is a lot of smaller tech companies look up to companies like Google and try to copy they’re interview process because hey, it’s Google. And these companies never consider that just maybe an app with billions of users has a slightly different set of requirements than their app with 500 users.
Read that last sentence again:
And these companies never consider that just maybe an app with billions of users has a slightly different set of requirements than their app with 500 users.
I think this is super important in todays landscape. A lot of MVP teams, startups or mid-sized companies try to copy companies like Google or Facebook, which makes sense on the surface...
I want my app to be the ${topTenApp} of ${industry}, so why wouldn't I use the same tools and processes as them?
Here's the difference.
Google used that tool or process to solve a very specific technical problem they faced as they grew, versus the copycat company that didn't actually solve anything by using the tool, but actually created more problems.
Kubernetes is a powerful tool for scaling services, but you won't ever need to use it if you don't actually have any users to scale for.
Using it to develop an MVP just adds unneccessary complexity, slows down development time, and makes hiring suitable developers harder down the road. Just stick with the Heroku hobby dyno and change it when you actually need to.
This same rule applies to dozens of tools and patterns. Microservices. Machine learning. React native. CDNs. Jenkins. GraphQL. Blockchain. ElasticSearch. The list goes on and on.
I'm not saying you shouldn't use any of these in your initial build. If the whole premise of your app is to build a smart contract based ledger for real estate then of course you'll need to use blockchain, but if you're building a social media site for equestrians you probably don't need to use machine learning for suggesting content in the beginning.
When you're starting out, you should use a tool for one of two reasons:
1) It's absolutely essential for your MVP.
2) It increases productivity.
That's it.
Everything else can be changed, fixed or added later on.
Don't be a perfectionist and don't solve problems you don't have.
Just make something good enough that users actually want to use it, and worry about scaling when you need to.
If you do this the other way around, you might just waste months building a perfectly useless app.
Top comments (22)
Tangential point: some of Google's practices have proved to be Bad Ideas™ in the long run anyway. Most of the practices of big companies did not usually contribute to their success; rather, they adopted those practices after their success, and sometimes because of their success.
Meanwhile, given some of the disastrous outcomes of various projects from Big Software, I tend to actually look more skeptically at any practice that Google, Facebook, Microsoft, Apple, Oracle, or the like follow.
So, don't solve problems you don't have, but if you do have or forsee them, don't assume that the solutions that mega-corporations use are necessarily smart to begin with.
I do have to add one other angle to the "don't be a perfectionist" topic. While one should definitely avoid "Imaginary Scaling Issues" (see image below), you should still structure your code to facilitate refactoring later!
Most of this is just loose coupling and DRY. For example, I may write a language parser that is dead simple, uses regex, and bumps along with dismal performance, but I design its API so I can easily swap it out for a better solution later if needed. I don't hardcode it.
I've lost track of how many times I blessed my past self for that practice.
Promised apropos image:
Yes, yes, and yes.
I've become rather scared to rely any of the google services and apis, because before you know it, they'll just deprecate things.
I'm use to building systems that should run for years and years without ever being touched, but since using google services, I have to revisit everything quite often.
I also see other comments about Go. I was the first one to get excited when Go was launched to the public. Yes, Go is fast, concurrency and channels are super good. But the rest of the ecosystem including the documentation is pretty bad.
Compared to Python, developing in Go feels like you're walking through glue, you'll get stronger, but it'll take longer.
Yes! Documentation is another huge problem with using the "latest and greatest." It might be the best language or tool out there but if you can't learn how to use it or figure out how to solve the basic errors it becomes almost unusable.
I agree 100%
I think that good documentation includes examples too. (for everything)
It just makes it so much easier if you can reference the docs, see straight away a piece of code that does what you need, and carry on with the job.
Go documentation is an exercise in figuring out what they meant and how to use the code. But there is hope.
As technologies mature, the documentation does seem get better.
So true, one of the project we had recently, a web app with lots of data processing.we wanted to do it with python and postgress. Client kept fixated on using go.when asked, he said "Google has created it and they are using it.so we should do it too."
Oh noooooo. How did that end?
I heard the same exact argument about Java years ago ("we must use Java because real enterprises use it, nobody uses Python"). Funny because at the time Google was one of the biggest fans of Python 😂
hehe,
We ended up doing in GO (what client asks they will get. after all they are paying 😂 ) but without python magic , project deadline was increased by several months.
What can you do when they are not listening to reason. right ?
I'm sorry to hear that.
Next time you need a real counter argument pro-Python for a client that is interested in knowing which big companies use wich technology, let me know and I'll send some of these arguments your way :D
Guido Van Rossum, Python's creator, used to work for Google (now he's at Dropbox, which uses Python a lot), like others of the core team. Google at some point even tried to rewrite Python to make it faster with a JIT (see Unladen Swallow). Instagram for the first few years was a Django app and AFAIK they still use it. This is from 2017:
thenewstack.io/instagram-makes-smo...
I don't think it should be the argument on which to build a decision as the OP say (or at least it shouldn't count as much), but if you have a client that values that primarily, it's nice to know you can at least suggest that Python is a real enterprise language ™ :P
Haha, you know, I've been using golang for a few years. It's concurrency and channels are amazing, but the documentation and many other things are actually sub-par.
Compared to Python, which I'm learning now, Python is much much nicer to work with. Syntax is cleaner, docs are better, ecosystem is better. So now, I'll only use golang if I need to build a super fast api server for thousands/sec.
Go performance is better yes, but if you don't need ultimate performance, save yourself the trouble.
And I was the first one who got excited years ago when google announced Go
Keep that in mind
I agree with this, I ten to think in orders of magnitude in terms of scaling.
The issue I try to think of is would this scale to one order of magnitude more users than today.
So if I write something for personal use it has to be OK for 10 people. Consequences might be, i use text files not databases, i use command line parameters rather than environmental vars.
I was working on a 20k users system and people kept thinking at the million users level, so everything was over engineered, growth rates of 1000% just don't occur in normal everyday life, yes aspire, but keep it realistic.
Absolutely true. I have seen this many times.
Yes, the "one way to do things" in Go is nice and it does make the approach to new programs easier. I also find writing very complex programs easier in Go.
I haven't had to support Python code bases before, so thanks for the heads up.
In Go I'd want to go without a framework vs Python I'd probably go with a framework.
one thing I have to add that even though I agree with most of your examples and comments, I would say cdn is a good practice as long as you are using something that's already built.
Building your own cdn is not a good idea but even in small projects the speed is a strong factor for new product based companies and CDN and caching can dramatically increase the page speed etc. which in turn result in better user growth.
Even a simple website should have CDN as page speed is a factor in SEO. And if it is a saas then your frontend files if delivered faster can have a better user experience.
Yes, it doesn't make sense when you are the only user but even if you go for 100 users I highly recommend caching and CDN and ssl( just for visual purposes)
100% accurate, hard to keep sight of when you are a perfectionist for sure!
So true! I learned this lesson the hard way. I'm a bit of a perfectionist myself and realized after years of starting and abandoning dozens of personal projects that "perfection" means roughly the same thing as "nonexistent."
u mean learning the docker+kubernetes with springboot stack wont make me a 10x dev??? ( .__.) (good article)