Dhruv Sharma

My dad is an economist. On the highway he will never change lanes no matter how much faster the other lane is moving, insisting that the drivers in front of him have already exploited any possible speed arbitrage opportunities.

I'm going to be vulnerable for a moment and admit that working on your own project is hard. Unless you have an extreme belief in your vision, fighting self-confidence issues takes a Sisyphus toll on you. It's not imposter syndrome, "Am I good enough?" It's more like, "Does the world really need this?" Only if you're an oracle or have a ton of experience can you predict what will be a banger. Most of the time, it's just dumb luck. Or right timing. Or leveraging hype waves. Or recycling past success when everyone has already forgotten about it. But great execution could also be devastated by misfortune equally well. When you work with someone else, and everyone believes in a project, at least you have some indication that more than one person might actually like it. When you're alone, you might as well be the only person who cares about what you do.

Build a graph schema in Postgres and switch to a graph database when you really need to. (You never will)

why i avoid graph databases the question: "is knowledge graph rag production ready? should we use it?" the answer: after 10 years in ml, i stay away from graph databases. every company i've seen go into the graph world moves back to sql within 4-5 years. the issues are real: hard to hire talent (easier to find postgresql experts) schema definition creates endless debates without clear best practices most use cases need only 1-2 traversals, not complex graph operations even facebook's "graph" was actually a large mysql database. the only company that truly needs graph databases is linkedin for 3-5 degree friendship calculations. even for microsoft's document graph approach - i'd rather use fine-tuned embeddings. a graph is just an adjacency matrix, and fine-tuning can get you close to that similarity definition without the operational complexity. start with your data: let specific use cases justify graph complexity rather than choosing technology first. graph might be 2% better, but traditional approaches working well means that 2% rarely justifies the maintenance cost.

we are interviewing around 15 people a day. most people are just... not good. so many cs graduates with 0 career experience, 0 side projects. i've never seen anything like it.

Et qui décide ce qu'est une "industrie d'avenir" dans lesquelles on va forcer les français à investir leur argent plutôt que le "passéisme", exactement ?