There’s a lot of interesting takes out there, too many to address. But to folks who are thinking “That’s a waste, it’s not that complicated. I could build that app in a week with 3 people and have it be way smaller and more efficient”. I hope you go do that. I wish you success.
-
Show this thread
-
When your better app starts getting traction (because it’s simpler and more efficient), I hope people recognize that value and adopt it. I hope those people go tell their friends to download and that the market rewards you for doing something better.
1 reply 0 retweets 13 likesShow this thread -
But with market reward comes growth, if you’re really good (or really lucky) you might achieve hypergrowth. If you achieve hypergrowth you’re going to have to quickly hire people to help you. Because soon your simple app will start melting your servers.
1 reply 0 retweets 15 likesShow this thread -
Something critical might break during peak times, or worse you start running out of rack space in the data center. While that’s happening the popularity of your new great thing
will attract the attention of local regulators who will implement new laws to govern the market.1 reply 0 retweets 14 likesShow this thread -
Your product people will scramble because your software wasn’t built handle whatever arbitrary process or limit they enacted, and they gave some ridiculously short deadline for compliance. Product will go the server engineers and say we need a robust system to handle all these.
1 reply 0 retweets 12 likesShow this thread -
But the server engineers will rightly say, “it will take months to build the system, and the servers are melting which is a higher priority for us. We can’t hit your two week deadline. It will be way easier to do that as a one off on the client” after all it’s just a simple app.
1 reply 0 retweets 13 likesShow this thread -
After this scenario plays out a few hundred times, the simple app will no longer be simple. In the mean time the Big Tech
exec you hired to help with your server melting problem (after all they’ve dealt with this before) has instituted something called a Promotion Committee.2 replies 0 retweets 20 likesShow this thread -
Then some of your client engineers will come along and look at your large clunky app made of one-offs and say “this is getting too slow and difficult to operate, we should rewrite this to scale better. Also, lets use this new tool so we aren't always playing catch up"
1 reply 0 retweets 19 likesShow this thread -
When all that happens, look me up. I’ve got a bottle of strong whiskey I’d be more than happy to share with you. Cheers
[End]2 replies 0 retweets 63 likesShow this thread -
Replying to @StanTwinB
What about when you start sending json & protos over the wire with code generated from thrift specs over a combination rpc & http semantics depending on response headers from a backend written in node, python, & go & the node layer converts i64s into blobs of the high/low 32 bits
2 replies 0 retweets 3 likes
Whaaat, I never realized we did the 64/32 bit thing 
-
-
Replying to @thijsniks @StanTwinB
I avoided implementing Android support for it as long as possible but cash payments were what finally did it Even better: sometimes they'd come down as an 8 element bytearray & they wouldn't tell you which. You just had to peek the json & check if it was an array or an object
1 reply 0 retweets 1 like -
I always sent them back long values though and no one ever came looking so it either works fine, doesn't matter, or I've just given a data scientist a huge headache
0 replies 0 retweets 1 like
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
at
retweets