Rishabh

This is the the quote I've been citing a lot recently.

“we got gta bangalore before…”

We spent millions building a wildly capable, human-like non-deterministic AI, and are now spending millions more trying to wrap it in guardrails and making it predictable and deterministic. Absolute cinema.

commuting an hour to work just to use a laptop that was already at home

@arpit_bhayani ClickHouse is amazing! we’re migrating from a ~1200-1400 node HIVE cluster to a fractional sized ClickHouse cluster (80-120 nodes), amazed by the performance and results we’re seeing internally with ClickHouse (and new architecture) for one of our projects.

Met Alexey Milovidov, CTO of ClickHouse - and of course, all we could talk about was databases. Databases help ape meet good people :)

Claude limit reached before lunch. It's not even half day. Ape sad. Ape confused. Ape understand nothing. Ape consider touching grass. Ape stay inside.

Let that sink in... a platform built from the ground up just streamed over 72.5MN fans at the same time. With personalized ads, real‑time commentary, rich match analytics and a tidal wave of emotions all holding steady. A double win for the @JioHotstar engineering and product teams... we broke global streaming records and then stayed on to celebrate India lifting the T20 World Cup trophy together.

Been saying this for a year. Agentic AI is backend engineering far more than it is AI. This stands true for any technology, once you scale and abstract it enough, you’re only left with engineering problems. Learn > Event driven systems > Data pipelines > Distributed systems > API Design > Observability / monitoring

Reliance and Google to offer Google AI Pro -- which includes Gemini Pro and 2TB of storage -- to Jio users for free for 18 months.

When ramping up the Dropbox storage system we were growing so fast we completely ran out of disk space in one 30PB storage cell. 0% disk space is a pretty tricky situation - a lot of software needs to write to the disk to run and you can't compact without writing first. Fortunately there was a separate root disk for each 100-disk storage node. I wrote a script to move a small amount of data to the root disk, mount it via a symlink, run compaction, move it back then on to the next one. The system evolved a lot since then and eventually didn't even use a filesystem but for a while the fix was to leave a large dummy file on each disk taking up space we could delete in an emergency. Inside every major tech company is someone figuring out a creative way to recover from something clowny like running out of disk space. (Dropbox's storage is incredibly bulletproof these days and afaik has never lost user data.)

Today's to-do list: - Fly the plane while building it - Run it up the flagpole - Boil the ocean - Thread the needle - Touch grass - Double-click into that - Get the view from 30,000 feet

Thank you android.permission.INTERNET

For everyone sad with what they have…

@Salm9n @PR0GRAMMERHUM0R 😭

@PR0GRAMMERHUM0R Yall got QA and DevOps?

thePipelineOfPanic redd.it/1m77qp2

Pushing to prod every single friday atp 🤗

Twitter and Square gave the world some immensely high quality mobile engineering gifts. The mobile engineering world would be 5 years behind without the absolutely insane level of open source work these teams did Kinda sad that CashApp/Square didn’t do better in last few years

When I was writing code for my own startup - without any prior experience, most things were structured fairly simply. The initial few people I had hired were also people I mentored and taught a lot of programming, and they, like me, had no prior experience at "enterprise" places, so they also wrote code fairly simply. Then I moved to Zomato, worked on the mobile app, (which was by then itself, already fairly big - 2M+ SLoC, 30+ modules, 3 different apps built from the same major repo). One of the things lot of people lamented there was that there wasn't a lot of 'structure' to the code, avant garde architecture principles like Clean Architecture was not being followed, and a only the most recently written code was MVVM, but most of the rest wasn't. We didn't even have any dependency injection framework setup. Then I went to work for a while at Target. An absolutely dogmatic 'enterprise' codebase. Every new feature, evern before any significant line of code was written, would first spawn 3 modules. 1 for the 'domain' code, that used to just be a bunch of interfaces, written in pure non-Android-dependent Java, 1 for the Android specifics and would implement the first module, and then a third module for all the testing code. If it required local data storage, a fourth module would get created. There were a bunch of people who would absolutely get off on writing bunch of 'adapters', 'strategies', 'factories', 'builders', and even adding a new button would generate 200 new lines of code. Looking back at it now, Zomato used to respond to a tweet on Monday saying 'please make this', and ship it as a feature by next Wednesday release. People new to the codebase could ship code within their first 2-3 days. And despite a lot of issues (like some performance problems, memory leaks, extremely large classes that did too many things over many years), almost none were actually because it wasn't trying to make the architecture what essentially looked like peeling off layers of an onion. At Target, new engineers would not be able to do much more than write tests, and not create new features, for as long as 2-3 months into the codebase. Features would take eons to ship. Even things which had just one possible implementation (with no possible future alternative implementations) still would have to be split up into a generic interface with a separate concrete implementations. Debugging would be a extremely painful because nothing was coupled. Clicking "see definition" or "see usages" in the IDE was mostly pointless because everything would lead to one more layer of 'indirection', and despite way more number of anal 'senior' engineers who forced everyone to write code with 5 layers of indirection, it was worse off than Zomato in every possible metric. (crash rates, memory footprint, performance, app startup, turn around time for new features, app size.... every metric) This is not to say Zomato's codebase was a shining beacon of what large codebases should be like (it very much was not, and had its own set of reasons for being hard to deal with), it was a great lesson for me that, at least whatever was wrong, was definitely not because we were not following Clean Architecture, and not making every feature into 4 separate modules, and because we didn't have dependency injection setup. And that's the first time I started getting convinced that 'Clean Architecture' is 100% an anti-pattern. I actually read the book end to end first time at that time (till then I only had read blogs about how Clean Architecture was implented, but not read the original Clean Code book). Having had worked enough on production codebased, hiring and managing teams who have to work on production codebases, and seeing the real world impact of different architecture patterns, I honestly couldn't get to understand what made everyone follow Uncle Bob and his horrible book so much. Every chapter I read felt like garbage. Every 'prescription' of how to write code I saw in the book made me wonder if this famous person writing this book has every actually written code for a real production system, and worked with a real team of software engineers or not. The truth is, most of the people who read Uncle Bob's books have written far more production code in their lives than he ever has. Most of the readers of his book have far more practical experience of working in a large modern software engineering team than he has. He has been just writing sermon after sermon on how to write more succinct classes in Java from 1995, without ever having written any real code in production. He is the classical example of college professors who have never worked in the industry. He is a senile grandpa, crying hoarse about "in my time we wrote code like this, and you kids don't know better", while the world has gone far far ahead. It has now come to point that I use this as a litmus test for who understands good software architecture and who doesn't. And people who dogmatically try to follow any of Clean, Onion, Hexagon and all that crap, are people I absolutely steer clear of, and never discuss software engineering with ever in future. I have never had the energy to write about how stupid Clean Code is, but someone I respect a lot has done that, and I keep just sharing the link to his article, everytime I hear any faint whispers about 'Clean Code' in any team. Sam Hughes, more famously known as the author of the SCP Foundation and Antimemetics Division, is also a programmer, and has taken out the time and effort to lay out clearly how useless most of the advise in Clean Code book is. qntm.org/clean