[{"data":1,"prerenderedAt":392},["ShallowReactive",2],{"youtube-videos-v7":3,"posts-v2":261},[4,15,24,34,44,53,61,69,77,84,93,102,109,116,123,130,138,145,150,157,164,171,178,187,194,201,208,215,222,229,238,245,254],{"id":5,"title":6,"description":7,"url":8,"thumbnail":9,"date":10,"dateLabel":11,"views":12,"viewsLabel":13,"category":14},"dpje3HwSH3s","My Life at 25: No Filters, No Edits","","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=dpje3HwSH3s","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002Fdpje3HwSH3s\u002Fhqdefault.jpg","2025-11-29T13:46:31+00:00","9 months ago",580,"580 views","life",{"id":16,"title":17,"description":7,"url":18,"thumbnail":19,"date":20,"dateLabel":21,"views":22,"viewsLabel":23,"category":14},"xNa8kAEIaQg","We are made of the same light. 🧿❤️🫂","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=xNa8kAEIaQg","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FxNa8kAEIaQg\u002Fhqdefault.jpg","2026-08-29T17:53:05+00:00","2 weeks ago",414,"414 views",{"id":25,"title":26,"description":7,"url":27,"thumbnail":28,"date":29,"dateLabel":30,"views":31,"viewsLabel":32,"category":33},"XWD_T0op2vA","Mumbai: Where Some Live Dreams & Some Just Survive","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=XWD_T0op2vA","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FXWD_T0op2vA\u002Fhqdefault.jpg","2026-03-21T11:37:51+00:00","5 months ago",81,"81 views","mumbai",{"id":35,"title":36,"description":7,"url":37,"thumbnail":38,"date":39,"dateLabel":40,"views":41,"viewsLabel":42,"category":43},"nfn5S4Y7oQA","ChessTV #06: Can I Reclaim My Chess Rating?","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=nfn5S4Y7oQA","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002Fnfn5S4Y7oQA\u002Fhqdefault.jpg","2026-03-09T13:14:06+00:00","6 months ago",111,"111 views","chess",{"id":45,"title":46,"description":7,"url":47,"thumbnail":48,"date":49,"dateLabel":50,"views":51,"viewsLabel":52,"category":14},"FU1buhuKZZQ","Throwback to endless giggles! 🫶🥹","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=FU1buhuKZZQ","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FFU1buhuKZZQ\u002Fhqdefault.jpg","2025-03-12T11:49:30+00:00","1 year ago",71,"71 views",{"id":54,"title":55,"description":7,"url":56,"thumbnail":57,"date":58,"dateLabel":50,"views":59,"viewsLabel":60,"category":14},"Mbd2e-eYJBs","Reel dedicated to my sister \u002F best friend. ❤️🥹 #sister #behan #happy #family","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=Mbd2e-eYJBs","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FMbd2e-eYJBs\u002Fhqdefault.jpg","2025-02-09T14:36:49+00:00",665,"665 views",{"id":62,"title":63,"description":7,"url":64,"thumbnail":65,"date":66,"dateLabel":50,"views":67,"viewsLabel":68,"category":14},"_4pxYBVN4N8","A Sky Full of Stars in Ahmedabad 🌌 | Coldplay Live Magic ✨🎶 #coldplay #ahmedabad","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=_4pxYBVN4N8","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002F_4pxYBVN4N8\u002Fhqdefault.jpg","2025-01-28T16:05:02+00:00",667,"667 views",{"id":70,"title":71,"description":7,"url":72,"thumbnail":73,"date":74,"dateLabel":50,"views":75,"viewsLabel":76,"category":14},"zZNj0-CQFQk","Paradise in Ahmedabad 🌏🎤 | Coldplay Concert Highlights 🎶 #coldplay","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=zZNj0-CQFQk","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FzZNj0-CQFQk\u002Fhqdefault.jpg","2025-01-28T15:44:50+00:00",801,"801 views",{"id":78,"title":63,"description":7,"url":79,"thumbnail":80,"date":81,"dateLabel":50,"views":82,"viewsLabel":83,"category":14},"OWgRAR373kA","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=OWgRAR373kA","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FOWgRAR373kA\u002Fhqdefault.jpg","2025-01-28T15:44:41+00:00",654,"654 views",{"id":85,"title":86,"description":7,"url":87,"thumbnail":88,"date":89,"dateLabel":90,"views":91,"viewsLabel":92,"category":43},"pMoZ6rTfsSc","ChessTV, Game 05: Restarting My Journey","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=pMoZ6rTfsSc","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FpMoZ6rTfsSc\u002Fhqdefault.jpg","2024-12-24T17:38:23+00:00","Streamed 1 year ago",5,"5 views",{"id":94,"title":95,"description":7,"url":96,"thumbnail":97,"date":98,"dateLabel":50,"views":99,"viewsLabel":100,"category":101},"yFj3vPW4_fo","LeetCode, 01: Two Sum","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=yFj3vPW4_fo","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FyFj3vPW4_fo\u002Fhqdefault.jpg","2025-09-17T12:27:06.615Z",62,"62 views","coding",{"id":103,"title":104,"description":7,"url":105,"thumbnail":106,"date":98,"dateLabel":90,"views":107,"viewsLabel":108,"category":43},"WQ9DCLKUaJk","ChessTV, Game 04: Playing Chess so people find me cool and intelligent","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=WQ9DCLKUaJk","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FWQ9DCLKUaJk\u002Fhqdefault.jpg",12,"12 views",{"id":110,"title":111,"description":7,"url":112,"thumbnail":113,"date":98,"dateLabel":50,"views":114,"viewsLabel":115,"category":33},"CxP-GcyTS4M","POV: You are in Bombai Nagariyan. 🏙️🫣","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=CxP-GcyTS4M","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FCxP-GcyTS4M\u002Fhqdefault.jpg",61,"61 views",{"id":117,"title":118,"description":7,"url":119,"thumbnail":120,"date":98,"dateLabel":50,"views":121,"viewsLabel":122,"category":14},"bg30SKkF8jk","if you ever feel like something is missing in your life, come to Udaipur. 💕🕊️🥹 #Udaipur #LakeCity","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=bg30SKkF8jk","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002Fbg30SKkF8jk\u002Fhqdefault.jpg",91,"91 views",{"id":124,"title":125,"description":7,"url":126,"thumbnail":127,"date":128,"dateLabel":129,"views":91,"viewsLabel":92,"category":43},"o1Q06dtoteI","ChessTV, Game 03: How Not To play Chess","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=o1Q06dtoteI","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002Fo1Q06dtoteI\u002Fhqdefault.jpg","2024-09-17T12:27:06.615Z","Streamed 2 years ago",{"id":131,"title":132,"description":7,"url":133,"thumbnail":134,"date":128,"dateLabel":135,"views":136,"viewsLabel":137,"category":14},"KtXXc8Jdbho","Grah Pravesh Invitation Video","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=KtXXc8Jdbho","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FKtXXc8Jdbho\u002Fhqdefault.jpg","2 years ago",136,"136 views",{"id":139,"title":140,"description":7,"url":141,"thumbnail":142,"date":128,"dateLabel":135,"views":143,"viewsLabel":144,"category":33},"AeykAteZvR0","Juhu Beach, Mumbai","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=AeykAteZvR0","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FAeykAteZvR0\u002Fhqdefault.jpg",30,"30 views",{"id":146,"title":147,"description":7,"url":148,"thumbnail":149,"date":128,"dateLabel":135,"views":136,"viewsLabel":137,"category":14},"KH2B1xgU9x0","Trek 02, Kareri Lake Trek: Trekking Paradise in Himachal","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=KH2B1xgU9x0","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FKH2B1xgU9x0\u002Fhqdefault.jpg",{"id":151,"title":152,"description":7,"url":153,"thumbnail":154,"date":128,"dateLabel":135,"views":155,"viewsLabel":156,"category":33},"jV2LaDJj7yU","POV: You are in Mumbai. ❤️ #mumbai #reels #shorts #shortvideo #rain #mumbaidiaries","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=jV2LaDJj7yU","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FjV2LaDJj7yU\u002Fhqdefault.jpg",442,"442 views",{"id":158,"title":159,"description":7,"url":160,"thumbnail":161,"date":128,"dateLabel":135,"views":162,"viewsLabel":163,"category":33},"Q7ebDJYp-1k","Trek to Garbett Point #trekking #trek #mumbai #weekend #selfcare","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=Q7ebDJYp-1k","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FQ7ebDJYp-1k\u002Fhqdefault.jpg",368,"368 views",{"id":165,"title":166,"description":7,"url":167,"thumbnail":168,"date":128,"dateLabel":135,"views":169,"viewsLabel":170,"category":33},"RcGUP2SkWzg","Into the woods! #trekking #trek #mumbai #Garbett","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=RcGUP2SkWzg","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FRcGUP2SkWzg\u002Fhqdefault.jpg",56,"56 views",{"id":172,"title":173,"description":7,"url":174,"thumbnail":175,"date":128,"dateLabel":135,"views":176,"viewsLabel":177,"category":33},"0R_9eH4svlM","Trek 01, Garbett Point Trek: A Day Hike With Amazing Views Near Mumbai","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=0R_9eH4svlM","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002F0R_9eH4svlM\u002Fhqdefault.jpg",49,"49 views",{"id":179,"title":180,"description":7,"url":181,"thumbnail":182,"date":183,"dateLabel":184,"views":185,"viewsLabel":186,"category":33},"kd2MJid5T2w","Bombay Monsoons are to live for!! ❤️🫶⛈️ #mumbai #monsoon #mumbaidiaries #marinedrive","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=kd2MJid5T2w","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002Fkd2MJid5T2w\u002Fhqdefault.jpg","2023-09-18T12:27:06.615Z","3 years ago",567,"567 views",{"id":188,"title":189,"description":7,"url":190,"thumbnail":191,"date":183,"dateLabel":184,"views":192,"viewsLabel":193,"category":33},"QvxC-l3IF3k","Magical Mornings at Marine Drive: Embrace the Tranquility #mumbai #marinedrive #trending #video","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=QvxC-l3IF3k","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FQvxC-l3IF3k\u002Fhqdefault.jpg",270,"270 views",{"id":195,"title":196,"description":7,"url":197,"thumbnail":198,"date":183,"dateLabel":184,"views":199,"viewsLabel":200,"category":33},"w6qxD5RVsgI","Mesmerizing #mumbai : Witness the Breathtaking Sunset at #marinedrive !","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=w6qxD5RVsgI","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002Fw6qxD5RVsgI\u002Fhqdefault.jpg",121,"121 views",{"id":202,"title":203,"description":7,"url":204,"thumbnail":205,"date":183,"dateLabel":184,"views":206,"viewsLabel":207,"category":43},"jM6eAwY2cF4","ChessTV, Game 02: Checkmate! Opponent quits as I dominate the Chessboard","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=jM6eAwY2cF4","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FjM6eAwY2cF4\u002Fhqdefault.jpg",51,"51 views",{"id":209,"title":210,"description":7,"url":211,"thumbnail":212,"date":183,"dateLabel":184,"views":213,"viewsLabel":214,"category":43},"jDoFBjzndmI","ChessTV, Game 01: The Agony of Defeat and Lessons Learned","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=jDoFBjzndmI","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FjDoFBjzndmI\u002Fhqdefault.jpg",29,"29 views",{"id":216,"title":217,"description":7,"url":218,"thumbnail":219,"date":183,"dateLabel":184,"views":220,"viewsLabel":221,"category":14},"fZtxvCBGuIo","The Philosophy of Cause and its Effect","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=fZtxvCBGuIo","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FfZtxvCBGuIo\u002Fhqdefault.jpg",45,"45 views",{"id":223,"title":224,"description":7,"url":225,"thumbnail":226,"date":183,"dateLabel":184,"views":227,"viewsLabel":228,"category":14},"8w9e1_gbyPE","Lady Sangeet Dance Video || Mom - Dad Duo || Cousin Wedding 2022","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=8w9e1_gbyPE","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002F8w9e1_gbyPE\u002Fhqdefault.jpg",3900,"3.9K views",{"id":230,"title":231,"description":7,"url":232,"thumbnail":233,"date":234,"dateLabel":235,"views":236,"viewsLabel":237,"category":101},"-ivhSFGyGuI","Video Resume | HighRadius | Winter Internship 2021","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=-ivhSFGyGuI","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002F-ivhSFGyGuI\u002Fhqdefault.jpg","2022-09-18T12:27:06.615Z","4 years ago",2900,"2.9K views",{"id":239,"title":240,"description":7,"url":241,"thumbnail":242,"date":234,"dateLabel":235,"views":243,"viewsLabel":244,"category":101},"CZXqEZX_V94","Campus Placement | A Data Mining Solution to Predict Campus Placement | GUCON 2021 | Research Paper","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=CZXqEZX_V94","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FCZXqEZX_V94\u002Fhqdefault.jpg",92,"92 views",{"id":246,"title":247,"description":7,"url":248,"thumbnail":249,"date":250,"dateLabel":251,"views":252,"viewsLabel":253,"category":101},"jPMxuAxcpAY","CodeChef || December Challenge 2020 Division 2 - DEC20B || Even Pair Sum-EVENPSUM","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=jPMxuAxcpAY","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FjPMxuAxcpAY\u002Fhqdefault.jpg","2021-09-18T12:27:06.615Z","5 years ago",357,"357 views",{"id":255,"title":256,"description":7,"url":257,"thumbnail":258,"date":250,"dateLabel":251,"views":259,"viewsLabel":260,"category":101},"PY-jAABcgbU","Codechef || December Challenge 2020 Division 2 - DEC20B || Vaccine Production-VACCINE1","https:\u002F\u002Fwww.youtube.com\u002Fwatch?v=PY-jAABcgbU","https:\u002F\u002Fi.ytimg.com\u002Fvi\u002FPY-jAABcgbU\u002Fhqdefault.jpg",279,"279 views",[262,277,290,294,304,313,324,332,341,349,358,368,377,385],{"slug":263,"title":264,"excerpt":265,"topic":266,"platform":267,"url":268,"xUrl":269,"substackUrl":269,"date":270,"dateLabel":271,"year":272,"readTime":273,"cover":274,"content":275,"full":276},"everything-you-need-to-know-about-x-monetisation","Everything You Need to Know About X Monetisation","Most people aren’t confused about X monetisation. They’re scared of looking late. Continue reading on ILLUMINATION »","investing","Medium","https:\u002F\u002Fmedium.com\u002Fillumination\u002Feverything-you-need-to-know-about-x-monetisation-f51cf0c24e33",null,"2026-09-11T05:01:34.000Z","Sep 11, 2026",2026,"1 min","https:\u002F\u002Fcdn-images-1.medium.com\u002Fmax\u002F1500\u002F1*9ZfiE5mNKgeMjCHOBX07tw.png","\u003Cdiv class=\"medium-feed-item\">\u003Cp class=\"medium-feed-image\">\u003Ca href=\"https:\u002F\u002Fmedium.com\u002Fillumination\u002Feverything-you-need-to-know-about-x-monetisation-f51cf0c24e33?source=rss-5795ce0c67d5------2\">\u003Cimg src=\"https:\u002F\u002Fcdn-images-1.medium.com\u002Fmax\u002F1500\u002F1*9ZfiE5mNKgeMjCHOBX07tw.png\" width=\"1500\">\u003C\u002Fa>\u003C\u002Fp>\u003Cp class=\"medium-feed-snippet\">Most people aren’t confused about X monetisation. They’re scared of looking late.\u003C\u002Fp>\u003Cp class=\"medium-feed-link\">\u003Ca href=\"https:\u002F\u002Fmedium.com\u002Fillumination\u002Feverything-you-need-to-know-about-x-monetisation-f51cf0c24e33?source=rss-5795ce0c67d5------2\">Continue reading on ILLUMINATION »\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fdiv>",false,{"slug":278,"title":279,"excerpt":280,"topic":14,"platform":267,"url":281,"xUrl":282,"substackUrl":283,"date":284,"dateLabel":285,"year":272,"readTime":286,"cover":287,"content":288,"full":289},"shame-is-the-tax-you-pay-for-staying-small","Shame Is the Tax You Pay for Staying Small","Most people never build anything, not because they lack ideas or time, but because somewhere along the way they decided that looking foolish was worse than staying invisible. That decision quietly puts a ceiling on your…","https:\u002F\u002Fjainprayush9.medium.com\u002Fshame-is-the-tax-you-pay-for-staying-small-ae1701e9fc4e","https:\u002F\u002Fx.com\u002Fjainprayush9\u002Fstatus\u002F2087982767221223863","https:\u002F\u002Fjainprayush9.substack.com\u002Fp\u002Fshame-is-the-tax-you-pay-for-staying","2026-08-13T19:32:42.000Z","Aug 13, 2026","3 min","\u002Fimages\u002Fessays\u002Fshame-tax\u002Fcover.jpg","\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Fshame-tax\u002Fcover.jpg\" alt=\"Shame is the tax you pay for staying small\" loading=\"lazy\" \u002F>\u003Cfigcaption>Shame is the tax you pay for staying small\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Cp>Most people never build anything, not because they lack ideas or time, but because somewhere along the way they decided that looking foolish was worse than staying invisible. That decision quietly puts a ceiling on your life.\u003C\u002Fp>\n\u003Cp>Think about everything you've wanted to try but didn't: posting your first video, writing online, starting a business, learning to code, building a product, sharing an opinion that isn't perfectly formed yet. The fear underneath usually isn't failure. It's being seen failing. You can get something wrong in private. The moment other people can watch you struggle, the stakes feel enormous; i.e, friends might laugh, colleagues might think you're trying too hard, family might wonder why you're doing something so different. So you don't do it. Nobody laughs. It feels like a win.\u003C\u002Fp>\n\u003Cp>Until a few years pass and you realize you protected yourself from embarrassment at the cost of becoming someone you never wanted to be.\u003C\u002Fp>\n\u003Cp>This is why being shameless matters. Not arrogant or careless, but willing to look stupid while you're still learning. Almost everything worth getting good at requires a stretch where you're bad at it. Your first videos will be awkward, your first writing mediocre, your first product might completely fail. That's not a warning sign. That's what the beginning looks like.\u003C\u002Fp>\n\u003Cp>The mistake is believing you need to become good before you let yourself be seen. You don't. You become good by letting yourself be seen while you're still bad, and this is where being young helps more than people admit. You have room to experiment, change your mind, start something unrelated to what you studied, embarrass yourself, and recover with time to spare.\u003C\u002Fp>\n\u003Cp>So try everything. Especially the things you're slightly embarrassed to try. Write the blog even if your English isn't perfect. Build the product even if you don't fully know what you're doing. Post the video even if you hate the sound of your own voice. You don't need to know in advance which one will work. You're collecting reps, and every rep teaches you something: what people respond to, what you're actually good at, what you enjoy enough to keep doing when nobody's watching yet.\u003C\u002Fp>\n\u003Cp>Even the failures pay you back. The video that gets twenty views teaches you something. The product nobody buys teaches you something. The article nobody reads teaches you something. None of that is wasted effort; it's tuition for skills that eventually compound.\u003C\u002Fp>\n\u003Cp>There's a second trap that keeps people small: treating the opinions around you like facts. Your friends might not understand what you're building. Your family might push you toward something safer. That doesn't mean you're wrong; it might just mean you're doing something they wouldn't do. You don't have to shrink your ambitions until they're comfortable for everyone around you. You don't need everyone to believe in you. You need enough conviction to keep going when they don't.\u003C\u002Fp>\n\u003Cp>And the honest part: this might not work. The video might flop. The blog might get four views. The product might quietly die in three months. The idea you've been obsessing over might turn out to be terrible. That's fine. The goal was never to make every attempt succeed. The goal is to become someone who can keep attempting because eventually something does work. One post reaches the right person. One idea gets shared. One product finds its first real customer. You can't manufacture that moment, but you can multiply the chances you give yourself to find it. Luck finds the people willing to be seen trying.\u003C\u002Fp>\n\u003Cp>So stop optimizing your life around avoiding embarrassment. There's no version of your future where everyone understands you, approves of you, and you still do something remarkable. At some point you choose: spend your years looking competent, or spend them becoming competent. The second path is more uncomfortable, and it's where almost everything worth having actually happens.\u003C\u002Fp>\n\u003Cp>Post the cringe video. Write the imperfect article. Build the ugly product. Learn the skill you're terrible at. Let people laugh.\u003C\u002Fp>\n\u003Cp>Shame is not the price of failure. It's the tax you pay for refusing to stay small.\u003C\u002Fp>\n\u003Cp>Pay it. Then keep going.\u003C\u002Fp>",true,{"slug":278,"title":279,"excerpt":291,"topic":292,"platform":267,"url":281,"xUrl":282,"substackUrl":283,"date":293,"dateLabel":285,"year":272,"readTime":286,"cover":287,"content":288,"full":289},"Most people never build anything, not because they lack ideas or time, but because somewhere along the way they decided that looking… Continue reading on Thought Thinkers »","career","2026-08-13T19:19:41.000Z",{"slug":295,"title":296,"excerpt":297,"topic":298,"platform":267,"url":299,"xUrl":269,"substackUrl":269,"date":300,"dateLabel":301,"year":272,"readTime":302,"cover":269,"content":303,"full":289},"shipping-got-easy-keeping-systems-honest-got-hard","Shipping Got Easy — Keeping Systems Honest Got Hard","A few years ago, the bottleneck on most engineering teams was obvious: building the thing. Continue reading on JavaScript in Plain English »","engineering","https:\u002F\u002Fjavascript.plainenglish.io\u002Fshipping-got-easy-keeping-systems-honest-got-hard-baed53ff04ca","2026-07-28T19:52:26.000Z","Jul 28, 2026","9 min","\u003Cp>A few years ago, the bottleneck on most engineering teams was obvious: building the thing.\u003C\u002Fp>\n\u003Cp>That is less true now. Frameworks, platforms, templates, and AI coding tools made it dramatically cheaper to stand up a feature, a service, a dashboard, or an alert rule. You can go from idea to merged PR faster than most organizations can schedule a design review.\u003C\u002Fp>\n\u003Cp>So the constraint moved. The hard part is no longer “can we ship this?” The hard part is “who keeps this true after we ship it?”\u003C\u002Fp>\n\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Fshipping-got-easy\u002Fhero.jpg\" alt=\"The constraint moved from shipping to ownership\" loading=\"lazy\" \u002F>\u003Cfigcaption>The constraint moved from shipping to ownership\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Cp>If you own a service, an on-call rotation, or the dashboards people open at 2 a.m., this is for you.\u003C\u002Fp>\n\u003Cp>Call it the \u003Cstrong>creation-to-ownership gap\u003C\u002Fstrong>: the widening distance between how easy it is to create something and how little capacity anyone budgets to keep it honest afterward.\u003C\u002Fp>\n\u003Cp>It shows up everywhere creation got cheap, and ownership stayed optional:\u003C\u002Fp>\n\u003Cul>\u003Cli>Feature flags that ship in an afternoon and linger for years\u003C\u002Fli>\u003Cli>Dashboards built during an incident and abandoned afterward\u003C\u002Fli>\u003Cli>Dependencies added in one PR and audited never, until a CVE forces the conversation\u003C\u002Fli>\u003Cli>Alerts added “just in case,” then muted forever\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Alerting is the sharpest case study, because bad signal does not just waste time. It trains people to stop listening.\u003C\u002Fp>\n\u003Ch2>Why alerts stop meaning anything\u003C\u002Fh2>\n\u003Cp>Every engineering team eventually builds the same thing without meaning to: a monitoring setup that pages people constantly and helps nobody.\u003C\u002Fp>\n\u003Cp>It does not happen on purpose. It happens one well-intentioned alert at a time. A threshold after an incident. A Slack notification “just in case.” A dashboard metric promoted to a page. Each addition feels responsible in isolation. Together, they train your own engineers to stop trusting the alarm.\u003C\u002Fp>\n\u003Cp>That is the real failure mode. Not that alerting is too quiet. That it is too loud, too often, about things that do not matter, until the one time it is loud about something that does, and nobody is listening anymore.\u003C\u002Fp>\n\u003Ch2>The fable everyone knows and nobody applies\u003C\u002Fh2>\n\u003Cp>The boy who cried wolf is not a story about lying. It is a story about \u003Cstrong>signal decay\u003C\u002Fstrong>. Every false alarm does not just fail to help. It actively degrades the value of every future alarm. By the time the real wolf shows up, the villagers have already learned, correctly, that responding costs more than it is worth.\u003C\u002Fp>\n\u003Cp>Most alerting systems run exactly this experiment on their own engineers, every week, without noticing.\u003C\u002Fp>\n\u003Ch2>The two costs nobody puts on a dashboard\u003C\u002Fh2>\n\u003Ch3>1. The direct cost — on-call burnout\u003C\u002Fh3>\n\u003Cp>An engineer who gets paged four times a night, three of which turn out to be nothing, does not sleep less on paper. They sleep less in practice, because the anxiety of an unpredictable pager is its own tax, independent of whether anything was actually wrong. Teams do not usually connect rising attrition or declining on-call morale to alert volume, but it is one of the most direct lines between infrastructure decisions and people decisions in engineering.\u003C\u002Fp>\n\u003Ch3>2. The invisible cost — trust decay\u003C\u002Fh3>\n\u003Cp>This is the more expensive one, and it compounds silently. Once an engineer learns that a specific alert is “usually nothing,” they stop treating it as an event that requires full attention. They glance, dismiss, move on. This is a rational adaptation to a noisy environment. Still, it means that when that same alert fires because something is actually wrong, the response time is identical to when it was nothing. The alert has not failed technically. It has failed as communication, which is all an alert ever really is.\u003C\u002Fp>\n\u003Ch2>Why this gets worse as systems grow\u003C\u002Fh2>\n\u003Cp>A five-service system can afford a slightly noisy alerting setup because a human can hold the whole picture in their head. That stops being true almost immediately as systems scale:\u003C\u002Fp>\n\u003Cul>\u003Cli>More services means more places for thresholds to be set without coordination\u003C\u002Fli>\u003Cli>More integrations mean more third-party status changes get treated as “alerts” by default\u003C\u002Fli>\u003Cli>More dashboards mean more temptation to wire every visible metric to a notification\u003C\u002Fli>\u003Cli>More on-call rotations mean less institutional memory about why a given alert exists at all\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Nobody sits down and designs a bad alerting system. It accretes, one reasonable-sounding addition at a time, with no equivalent process for subtraction. Nobody’s job is to remove alerts. Everybody’s job, implicitly, is to add them.\u003C\u002Fp>\n\u003Cp>That is the creation-to-ownership gap in miniature. Creation is easy. Subtraction has no owner.\u003C\u002Fp>\n\u003Cp>AI coding tools widen it further. They make it even easier to scaffold another service, another monitor, another “temporary” flag, without anyone adding matching capacity to maintain what just got created. Speed of generation is not the same as capacity to own.\u003C\u002Fp>\n\u003Cp>There is a second trap that looks sophisticated: the \u003Cstrong>passive monitoring trap\u003C\u002Fstrong>. Teams build beautiful dashboards, then assume someone is watching. Nobody is watching on a reliable schedule. Dashboards are opt-in. Pages are interruptive. If critical change only exists on a panel, you have reporting, not response.\u003C\u002Fp>\n\u003Chr \u002F>\n\u003Ch2>What to do instead\u003C\u002Fh2>\n\u003Cp>This is where most “how to set up Grafana\u002FLast9” posts stop at screenshots. The missing half is design that survives a real on-call rotation.\u003C\u002Fp>\n\u003Ch3>The only alert filter that matters\u003C\u002Fh3>\n\u003Cp>Not every signal deserves to interrupt a human.\u003C\u002Fp>\n\u003Cblockquote>\u003Cp>An alert should exist only if a human needs to take a specific action right now, and that action is not already automated.\u003C\u002Fp>\u003C\u002Fblockquote>\n\u003Cp>Run every candidate alert through that test:\u003C\u002Fp>\n\u003Cul>\u003Cli>Informational state changes belong on a dashboard, not a page\u003C\u002Fli>\u003Cli>Scripted responses should be automated, not routed to a person\u003C\u002Fli>\u003Cli>“Useful context” belongs in a log or thread, not a notification\u003C\u002Fli>\u003Cli>Duplicate symptoms of one failure should be one alert, not five\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>The test is not “is this true and worth knowing.” Almost everything is. The test is whether someone must act now, urgently enough to interrupt whatever they were doing.\u003C\u002Fp>\n\u003Cp>If you only take one practical rule from this article, take that filter.\u003C\u002Fp>\n\u003Ch3>Make the alert itself actionable\u003C\u002Fh3>\n\u003Cp>A good alert is a work order, not a riddle. When it fires, the person receiving it should not need to reverse-engineer your intentions at 2 a.m.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Bad:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode>ALERT: cpu_usage_percent{service=checkout} > 80 for 5m\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>Better:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode>Checkout p95 latency is above SLO (currently 1.8s, budget burn high).\nUsers are seeing slow payments.\nOpen the Checkout first-five-minutes dashboard → Latency panel.\nRunbook: https:\u002F\u002F...\u002Fcheckout-latency.\nIf not recovering in 10 minutes, page Payments on-call.\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Every page-worthy alert should include:\u003C\u002Fp>\n\u003Cul>\u003Cli>What broke in plain language (not only a metric name)\u003C\u002Fli>\u003Cli>Why it matters (user impact, SLO risk, blast radius)\u003C\u002Fli>\u003Cli>Where to look first (link to the right dashboard panel, not the homepage)\u003C\u002Fli>\u003Cli>What to do next (runbook \u002F SOP steps)\u003C\u002Fli>\u003Cli>Who else to involve if mitigation stalls (escalation)\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>If your tool supports advanced fields (investigation guide, false-positive notes, severity, references), fill them. Empty rule metadata is how “create alert” becomes creation without ownership.\u003C\u002Fp>\n\u003Cp>Also prefer smarter thresholds where you can. Static lines like CPU > 80 are easy to ship and easy to cry wolf. Prefer symptoms users feel (error rate, latency, freshness, availability) and thresholds tied to history or SLO burn when possible. Threshold alerts, anomaly-style alerts, and trend-change alerts all have a place. Vanity metrics do not.\u003C\u002Fp>\n\u003Ch3>Route to people who can act\u003C\u002Fh3>\n\u003Cp>Alert fatigue is often a routing problem disguised as a volume problem.\u003C\u002Fp>\n\u003Cul>\u003Cli>Send pages only to people empowered to act\u003C\u002Fli>\u003Cli>Keep FYI \u002F deploy \u002F minor blips out of the must-act channel\u003C\u002Fli>\u003Cli>Prefer team-owned routes over “everyone engineering”\u003C\u002Fli>\u003Cli>Deduplicate and thread: one incident, one conversation, updates instead of five identical pings\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Slack made alerting feel cheap. A noisy Slack channel is still a trust failure. It is just quieter about it. Separate must-act from awareness. Thread instead of repeating. Attach the runbook every time.\u003C\u002Fp>\n\u003Ch3>Build a “first five minutes” dashboard, not a museum\u003C\u002Fh3>\n\u003Cp>Dashboards and alerts get treated as interchangeable, and they are not.\u003C\u002Fp>\n\u003Cul>\u003Cli>\u003Cstrong>Dashboards\u003C\u002Fstrong> answer: how are we doing, on a human schedule?\u003C\u002Fli>\u003Cli>\u003Cstrong>Alerts\u003C\u002Fstrong> answer: does someone need to act right now?\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>A useful service dashboard for on-call usually covers a small, opinionated set of views. Steal this shape even if your tool is Grafana, Kibana, Datadog, or something else:\u003C\u002Fp>\n\u003Cul>\u003Cli>Variables people can change without editing the dashboard (env, service, percentile, time resolution)\u003C\u002Fli>\u003Cli>SLOs \u002F user symptoms (availability, latency, error rate)\u003C\u002Fli>\u003Cli>Server \u002F API view (traffic, errors, hot endpoints)\u003C\u002Fli>\u003Cli>Async\u002Fbackground work if you have queues or cron\u003C\u002Fli>\u003Cli>Client view when you have client-side telemetry\u003C\u002Fli>\u003Cli>System resources (CPU, memory, runtime-specific stats)\u003C\u002Fli>\u003Cli>Dependency health (the thing that usually breaks you at 3 a.m.)\u003C\u002Fli>\u003Cli>Alerts section with only the graphs that actually page, plus links to SOPs\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>Two rules that keep dashboards honest:\u003C\u002Fp>\n\u003Col>\u003Cli>Do not wire every panel into an alert. Pick essential graphs only.\u003C\u002Fli>\u003Cli>Alert configuration should not depend on casual dashboard variables. Alerts need fixed evaluation windows and explicit thresholds.\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>If a panel does not help in the first five minutes of an incident, it probably does not belong on the primary on-call view. Put archaeology elsewhere.\u003C\u002Fp>\n\u003Ch3>Connect alert → investigation → incident → learning\u003C\u002Fh3>\n\u003Cp>Mature setups do one more thing tutorials often skip: close the loop.\u003C\u002Fp>\n\u003Cp>When a real alert fires, the path should be obvious:\u003C\u002Fp>\n\u003Col>\u003Cli>Alert fires with context and runbook\u003C\u002Fli>\u003Cli>On-call lands on the first-five-minutes dashboard\u003C\u002Fli>\u003Cli>If it is a real incident, declare\u002Fopen an incident channel\u003C\u002Fli>\u003Cli>Capture timeline and owners\u003C\u002Fli>\u003Cli>Afterward, look at detection and response quality (MTTD, MTTR, noisy rules, missing signals)\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>If alerts never produce learning, the creation-to-ownership gap reopens. You will keep adding rules and never retire the ones that trained people to mute the channel.\u003C\u002Fp>\n\u003Ch2>What to do this week\u003C\u002Fh2>\n\u003Cp>Most teams do not need a new alerting platform. They need an audit.\u003C\u002Fp>\n\u003Cp>For each noisy alert, ask: when this last fired, did a human take a specific action because of it? If the answer is usually no, that is not a tooling problem. It is an unmaintained list of things somebody once thought were important.\u003C\u002Fp>\n\u003Cp>Buying another tool before this audit usually just moves the noise somewhere more expensive.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Practical pass:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Col>\u003Cli>List your top 20 noisiest alerts by fire count\u003C\u002Fli>\u003Cli>For each, check the last three fires: what action was taken?\u003C\u002Fli>\u003Cli>Delete, demote to dashboard-only, or fix the ones with no action\u003C\u002Fli>\u003Cli>Rewrite survivors so they include impact, dashboard link, and runbook\u003C\u002Fli>\u003Cli>Rebuild one service dashboard around the first-five-minutes template above\u003C\u002Fli>\u003Cli>Put a name next to alert + dashboard hygiene for that service for the next quarter\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>That is more valuable than another panel.\u003C\u002Fp>\n\u003Ch2>This is not only about alerts\u003C\u002Fh2>\n\u003Cp>Alerting is the sharpest example of the creation-to-ownership gap, not the only one. The same pattern shows up in flags nobody removes, dashboards nobody owns, and dependencies nobody audits until something breaks. AI tools accelerate creation without budgeting ownership. If your organization only celebrates shipping, you will keep optimizing the easy side of the ledger.\u003C\u002Fp>\n\u003Cp>The teams that age well treat ownership as first-class work: code, alerts, dashboards, flags, dependencies, runbooks. Not as cleanup for when the roadmap has spare room, because it never does.\u003C\u002Fp>\n\u003Ch2>The real question\u003C\u002Fh2>\n\u003Cp>Every team believes their alerting system tells the truth until they actually check. The uncomfortable audit is not “do we have enough monitoring.” Almost everyone has plenty. It is “when this last fired, did anyone actually do anything about it, or did they just make it stop.”\u003C\u002Fp>\n\u003Cp>If the honest answer is the second one more often than the first, the alerting system is not protecting anyone. It is just training your best engineers to stop listening.\u003C\u002Fp>\n\u003Cp>And the broader question behind that one is the title of this piece: now that shipping is easy, who is responsible for keeping what you shipped honest?\u003C\u002Fp>\n\u003Cblockquote>\u003Cp>How much of your alert volume right now would survive the test: did a human take a specific action because of this?\u003C\u002Fp>\u003C\u002Fblockquote>",{"slug":305,"title":306,"excerpt":307,"topic":298,"platform":267,"url":308,"xUrl":269,"substackUrl":269,"date":309,"dateLabel":310,"year":272,"readTime":311,"cover":269,"content":312,"full":289},"the-hidden-tax-every-engineering-team-is-paying-and-doesnt-talk-about","The Hidden Tax Every Engineering Team Is Paying (And Doesn’t Talk About)","There’s a number almost no engineering org tracks: how many collective hours their developers spend staring at a build progress bar every… Continue reading on JavaScript in Plain English »","https:\u002F\u002Fjavascript.plainenglish.io\u002Fthe-hidden-tax-every-engineering-team-is-paying-and-doesnt-talk-about-f58fce33d365","2026-07-27T18:27:21.000Z","Jul 27, 2026","8 min","\u003Cp>There’s a number almost no engineering org tracks: how many collective hours their developers spend staring at a build progress bar every week.\u003C\u002Fp>\n\u003Cp>Not writing code. Not designing systems. Not shipping features. Just… waiting.\u003C\u002Fp>\n\u003Cp>If your team runs 30–40 builds a day, and each one takes 50 minutes instead of 15, you’re not losing 35 minutes. You’re losing 35 minutes multiplied by every engineer, every build, every day, compounding into months of lost engineering time a year. And unlike a production outage, nobody files an incident report for a slow build. It just quietly taxes your velocity forever, until someone decides to fix it.\u003C\u002Fp>\n\u003Cp>Build optimization doesn’t get the attention it deserves because it doesn’t look like a “real” engineering problem. It’s not a new feature. It’s not a scaling milestone. It’s plumbing. But plumbing determines how fast everything else in the house works.\u003C\u002Fp>\n\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Fhidden-tax\u002Fci-cd-loop.jpg\" alt=\"CI\u002FCD is a loop — every slow stage compounds forever\" loading=\"lazy\" \u002F>\u003Cfigcaption>CI\u002FCD is a loop — every slow stage compounds forever\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Ch2>The Two Costs Nobody Puts on a Slide\u003C\u002Fh2>\n\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Fhidden-tax\u002Fcompute.png\" alt=\"Compute is the visible bill — context switching is the invisible one\" loading=\"lazy\" \u002F>\u003Cfigcaption>Compute is the visible bill — context switching is the invisible one\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Ch3>1. The direct cost — compute\u003C\u002Fh3>\n\u003Cp>Every build consumes CPU, memory, and often paid CI minutes. A bloated pipeline running redundant steps, rebuilding unchanged modules, or spinning up oversized runners is literally burning money on infrastructure that produces nothing. At scale (hundreds of builds a day across a growing team), this adds up to a real, visible line item. Companies routinely discover they’re paying for 3–4x more compute than the actual work requires, simply because nobody audited the pipeline since it was first written.\u003C\u002Fp>\n\u003Ch3>2. The invisible cost — context switching\u003C\u002Fh3>\n\u003Cp>This one is more expensive, and almost nobody measures it. When a build takes 40–50+ minutes, developers don’t sit and watch it. They switch tasks, check Slack, open a different ticket, and then pay a “resumption tax” when they come back to reload the mental model of what they were doing. Research on developer flow state consistently shows that switching costs far exceed the wait time itself. A 50-minute build isn’t a 50-minute cost. It’s often far more once you account for how long it takes to get back into deep focus, and how many times that interruption happens in a day.\u003C\u002Fp>\n\u003Cp>Multiply that across a team, across a year, and slow builds become one of the largest hidden drains on engineering productivity, bigger than most teams’ entire “developer experience” budget.\u003C\u002Fp>\n\u003Ch2>Why This Gets Worse as You Scale, Not Better\u003C\u002Fh2>\n\u003Cp>Early on, builds are fast because codebases are small. Nobody notices the problem until it’s already expensive to fix. As a codebase grows:\u003C\u002Fp>\n\u003Cul>\u003Cli>Dependency graphs get tangled, and clean modularization erodes\u003C\u002Fli>\u003Cli>More tests get added without a parallelization strategy\u003C\u002Fli>\u003Cli>CI pipelines accumulate steps nobody remembers the purpose of\u003C\u002Fli>\u003Cli>Caching layers are either missing or invalidated too aggressively to help\u003C\u002Fli>\u003Cli>Generated artifacts creep into version control and become everyone’s problem\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>In a monorepo, this compounds faster. One slow path isn’t one team’s problem. It’s every team’s wait time, every PR, every day. A redundant step in a shared pipeline taxes backend, frontend, and platform engineers alike. A bad cache key or an unbalanced test shard shows up as “CI is slow” for the whole org, not one squad.\u003C\u002Fp>\n\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Fhidden-tax\u002Fmonorepo.jpg\" alt=\"One shared pipeline — every team pays the same tax\" loading=\"lazy\" \u002F>\u003Cfigcaption>One shared pipeline — every team pays the same tax\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Cp>The result is a slow, creeping decline that’s easy to rationalize away one sprint at a time (“it’s just a bit slower this quarter”) until a team wakes up to 40–50 minute builds and wonders how they got there.\u003C\u002Fp>\n\u003Cp>There’s a related trap that looks like progress: throwing more machines at it. Parallelization helps. But parallelizing work you shouldn’t be doing at all has a cost curve that goes the wrong way. You can finish earlier and spend more.\u003C\u002Fp>\n\u003Ch2>What Actually Moves the Needle\u003C\u002Fh2>\n\u003Cp>Not all optimizations are equal. A small set of principles accounts for most of the gains:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Only rebuild what changed.\u003C\u002Fstrong> Incremental builds sound obvious, but a shocking number of pipelines still rebuild the world on every commit because incremental support was never configured, or was configured once and quietly broken.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Cache for correctness first, speed second.\u003C\u002Fstrong> Shared caching is where real gains show up. The hard part isn’t turning a cache on. It’s versioning it so it doesn’t lie across branches, toolchains, or parallel writers.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Parallelize the right work, then balance it.\u003C\u002Fstrong> A tangled “everything depends on everything” graph makes parallelization impossible no matter what tooling you buy. And even when you fan out, unbalanced shards leave agents idle while the slowest one owns wall-clock. “Parallel” is not the same as “balanced.”\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Delete ceremony. Decouple prove from ship.\u003C\u002Fstrong> The same lint or type-check often runs in the PR gate and again in the deploy build. Unit tests rarely need a full production packaging step. If your feedback loop waits on work that isn’t required for that job’s purpose, you’re paying a coupling tax.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Stop treating humans as a build step.\u003C\u002Fstrong> Unused dependencies, oversized artifacts, and committed generated output silently slow builds, reviews, and merges. Hygiene is unglamorous and pays for itself repeatedly.\u003C\u002Fp>\n\u003Cp>None of this is exotic. The reason it doesn’t get fixed isn’t lack of solutions. It’s lack of ownership. Build performance sits in the gap between “not really infra’s job” and “not really product engineering’s job,” so it drifts.\u003C\u002Fp>\n\u003Ch2>How to Actually Achieve It\u003C\u002Fh2>\n\u003Cp>Knowing the principles isn’t enough. Order matters, especially in a monorepo where “fix the build” can feel too big to start.\u003C\u002Fp>\n\u003Ch3>1. Instrument before you optimize\u003C\u002Fh3>\n\u003Cp>Break the pipeline into stages and measure wall-clock: dependency restore, compile\u002Fpackage, lint, unit tests (per shard), integration\u002Fe2e, artifact publish. Find the slowest stage and the widest gap between shards. Those two numbers tell you where to go first.\u003C\u002Fp>\n\u003Ch3>2. Draw the dependency graph of the pipeline\u003C\u002Fh3>\n\u003Cp>For every job, ask: does this step need to succeed for this job’s purpose? PR gates need correctness signals. Deploy builds need shippable artifacts. Local loops need the shortest path to “is my change broken?” Anything that appears twice without a reason is a deletion candidate.\u003C\u002Fp>\n\u003Ch3>3. Delete before you parallelize\u003C\u002Fh3>\n\u003Cp>This is the sequence that consistently pays off:\u003C\u002Fp>\n\u003Col>\u003Cli>Remove duplicate gates\u003C\u002Fli>\u003Cli>Decouple test from ship\u003C\u002Fli>\u003Cli>Stop committing generated artifacts\u003C\u002Fli>\u003Cli>Fix cache correctness (version by branch\u002Flockfile\u002Ftoolchain; isolate parallel writers)\u003C\u002Fli>\u003Cli>Replace the slow tool on the hot path\u003C\u002Fli>\u003Cli>Parallelize the bottleneck itself (a single-threaded step on a 16-core box is not fixed by more CI agents)\u003C\u002Fli>\u003Cli>Rebalance shards (idle agents are still cost)\u003C\u002Fli>\u003Cli>Only then buy more machines\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>If you reverse this order, you often get a faster and more expensive pipeline.\u003C\u002Fp>\n\u003Ch3>4. Ship it as a portfolio, not a hero PR\u003C\u002Fh3>\n\u003Cp>One dramatic change rarely delivers a lasting win. A sequence of small, measured improvements does. Track before\u002Fafter per stage so the org doesn’t forget and reintroduce the fat.\u003C\u002Fp>\n\u003Ch3>5. Assign an owner\u003C\u002Fh3>\n\u003Cp>Someone has to be accountable for pipeline wall-clock and CI cost the way someone owns latency SLOs. Without that, every sprint prefers a product ticket over plumbing, and the tax keeps compounding.\u003C\u002Fp>\n\u003Ch2>How I Did It in a Monorepo\u003C\u002Fh2>\n\u003Cp>I own this story from inside a large production monorepo: many modules, shared libraries, multiple CI paths, and a build that had grown the way monorepo builds usually do, by accretion.\u003C\u002Fp>\n\u003Cp>The starting point looked familiar. Packaging paths that redid far more work than they needed to. A custom asset-processing step that didn’t scale with available cores. Caches that existed but weren’t versioned or isolated safely for parallel workers. Quality checks running twice, once as a PR gate and again in the deploy path. Unit tests gated behind a full production-style build they didn’t need. Test shards that were “parallel” but uneven. Generated artifacts committed to git (on the order of ~150K+ lines), creating noisy diffs, merge conflicts, and a manual rebuild ritual.\u003C\u002Fp>\n\u003Cp>None of that is unique to one language or framework. It’s what happens when a monorepo’s shared pipeline is everyone’s infrastructure and nobody’s roadmap item.\u003C\u002Fp>\n\u003Cp>I worked the sequence above. Made the bottleneck itself parallel instead of only fanning the same slow step across more agents. Cached correctly, not just “on,” with branch-based versioning and per-worker cache directories. Deleted duplicate static analysis and decoupled unit tests from the ship build. Rebalanced uneven test shards so agents finished closer together. Moved generated artifacts into the pipeline and out of git. Replaced a CPU-heavy step on the hot path with a much faster tool. Cleaned the long tail: unused dependencies, LTS upgrades, better dependency caching, sensible test timeouts.\u003C\u002Fp>\n\u003Cp>What didn’t work was also useful. A popular “rewrite the compiler stack for speed” migration looked great on paper but failed the risk\u002Freward test under our framework constraints. Documenting why a trendy optimization doesn’t apply saves the next engineer weeks.\u003C\u002Fp>\n\u003Cp>Results on the paths I owned:\u003C\u002Fp>\n\u003Cul>\u003Cli>~10–15 minutes faster on the first major build path\u003C\u002Fli>\u003Cli>~19–20 minutes faster on the second\u003C\u002Fli>\u003Cli>~32 minutes of wall-clock saved combined\u003C\u002Fli>\u003Cli>~50% cost reduction on those builds, because we removed work, not only parallelized it\u003C\u002Fli>\u003Cli>~150K+ LOC of generated artifacts out of version control\u003C\u002Fli>\u003C\u002Ful>\n\u003Cp>The monorepo lesson that stuck with me: optimizations in a shared pipeline are force multipliers. One deleted step, one correct cache, one balanced shard, and every team that ships through that pipeline inherits the win. That’s also why ownership matters more here than in a single-service repo. If nobody owns the shared path, everybody pays.\u003C\u002Fp>\n\u003Ch2>The Business Case, Not Just the Engineering Case\u003C\u002Fh2>\n\u003Cp>If you’re trying to get this prioritized, don’t pitch it as a developer comfort issue. Pitch it as what it actually is: a cost and velocity issue.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Cost:\u003C\u002Fstrong> Reduced CI compute time translates directly into lower cloud spend, often the single easiest infrastructure cost to cut with zero product risk.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Velocity:\u003C\u002Fstrong> Faster feedback loops mean faster iteration, faster bug fixes, and faster time-to-production, which compounds across every team that ships through that pipeline.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Retention:\u003C\u002Fstrong> Developer experience is a real retention lever. Engineers notice when their tools work against them, and “our build is painfully slow” is a recurring theme in exit interviews at companies that never invested here.\u003C\u002Fp>\n\u003Cp>Framed this way, build optimization stops looking like a nice-to-have cleanup task and starts looking like what it is: one of the highest-leverage, lowest-risk investments an engineering org can make. You’re not betting on an unproven feature. You’re removing friction from something every single engineer touches, every single day.\u003C\u002Fp>\n\u003Ch2>The Real Question\u003C\u002Fh2>\n\u003Cp>The question isn’t whether your build pipeline has room to improve. Almost every pipeline does, because nobody budgets time to maintain it the way they budget time to build features. The real question is whether anyone owns it.\u003C\u002Fp>\n\u003Cp>If the honest answer is “not really,” that’s usually the actual problem worth solving first, especially in a monorepo, where the tax is shared, and the ownership gap is largest.\u003C\u002Fp>\n\u003Cp>What’s the slowest part of your build pipeline right now, and has anyone actually looked at why?\u003C\u002Fp>",{"slug":314,"title":315,"excerpt":316,"topic":14,"platform":317,"url":318,"xUrl":269,"substackUrl":269,"date":319,"dateLabel":320,"year":321,"readTime":273,"cover":322,"content":323,"full":289},"the-philosophy-of-cause-and-its-effect","The Philosophy of “Cause and its Effect”","We are all born into different time zones, environments, and upbringings, but there is one thing that we are all taught in common: the philosophy of good and bad. But we are never taught the philosophy of cause and effec…","Substack","https:\u002F\u002Fjainprayush9.substack.com\u002Fp\u002Fthe-philosophy-of-cause-and-its-effect","2025-10-03T13:04:58.000Z","Oct 3, 2025",2025,"https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!9zjc!,w_256,c_limit,f_auto,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fa4581f38-c823-48e1-8651-6e24f92a1545_960x960.jpeg","\u003Cdiv class=\"captioned-image-container\">\u003Cfigure>\u003Ca class=\"image-link image2 is-viewable-img\" target=\"_blank\" href=\"https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,f_auto,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg\" data-component-name=\"Image2ToDOM\">\u003Cdiv class=\"image2-inset\">\u003Cpicture>\u003Csource type=\"image\u002Fwebp\" srcset=\"https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_424,c_limit,f_webp,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 424w, https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_848,c_limit,f_webp,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 848w, https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_1272,c_limit,f_webp,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 1272w, https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_1456,c_limit,f_webp,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 1456w\" sizes=\"100vw\">\u003Cimg src=\"https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg\" width=\"256\" height=\"320\" data-attrs=\"{"src":"https:\u002F\u002Fsubstack-post-media.s3.amazonaws.com\u002Fpublic\u002Fimages\u002Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg","srcNoWatermark":null,"fullscreen":null,"imageSize":null,"height":320,"width":256,"resizeWidth":null,"bytes":null,"alt":null,"title":null,"type":null,"href":null,"belowTheFold":false,"topImage":true,"internalRedirect":null,"isProcessing":false,"align":null,"offset":false}\" class=\"sizing-normal\" alt=\"\" srcset=\"https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_424,c_limit,f_auto,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 424w, https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_848,c_limit,f_auto,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 848w, https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_1272,c_limit,f_auto,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 1272w, https:\u002F\u002Fsubstackcdn.com\u002Fimage\u002Ffetch\u002F$s_!Gy75!,w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep\u002Fhttps%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc7e40b9a-4983-4152-b172-b94425858658_256x320.jpeg 1456w\" sizes=\"100vw\" fetchpriority=\"high\">\u003C\u002Fpicture>\u003Cdiv class=\"image-link-expand\">\u003Cdiv class=\"pencraft pc-display-flex pc-gap-8 pc-reset\">\u003Cbutton tabindex=\"0\" type=\"button\" class=\"pencraft pc-reset pencraft icon-container restack-image buttonBase-GK1x3M\">\u003Csvg aria-hidden=\"true\" width=\"20\" height=\"20\" viewBox=\"0 0 20 20\" fill=\"none\" stroke-width=\"1.5\" stroke=\"var(--color-fg-primary)\" stroke-linecap=\"round\" stroke-linejoin=\"round\" xmlns=\"http:\u002F\u002Fwww.w3.org\u002F2000\u002Fsvg\" class=\"icon-noB79L\">\u003Cg>\u003Cpath d=\"M2.53001 7.81595C3.49179 4.73911 6.43281 2.5 9.91173 2.5C13.1684 2.5 15.9537 4.46214 17.0852 7.23684L17.6179 8.67647M17.6179 8.67647L18.5002 4.26471M17.6179 8.67647L13.6473 6.91176M17.4995 12.1841C16.5378 15.2609 13.5967 17.5 10.1178 17.5C6.86118 17.5 4.07589 15.5379 2.94432 12.7632L2.41165 11.3235M2.41165 11.3235L1.5293 15.7353M2.41165 11.3235L6.38224 13.0882\">\u003C\u002Fpath>\u003C\u002Fg>\u003C\u002Fsvg>\u003C\u002Fbutton>\u003Cbutton tabindex=\"0\" type=\"button\" class=\"pencraft pc-reset pencraft icon-container view-image buttonBase-GK1x3M\">\u003Csvg xmlns=\"http:\u002F\u002Fwww.w3.org\u002F2000\u002Fsvg\" width=\"20\" height=\"20\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"currentColor\" stroke-width=\"2\" stroke-linecap=\"round\" stroke-linejoin=\"round\" class=\"lucide lucide-maximize2 lucide-maximize-2 icon-noB79L\">\u003Cpolyline points=\"15 3 21 3 21 9\">\u003C\u002Fpolyline>\u003Cpolyline points=\"9 21 3 21 3 15\">\u003C\u002Fpolyline>\u003Cline x1=\"21\" x2=\"14\" y1=\"3\" y2=\"10\">\u003C\u002Fline>\u003Cline x1=\"3\" x2=\"10\" y1=\"21\" y2=\"14\">\u003C\u002Fline>\u003C\u002Fsvg>\u003C\u002Fbutton>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fa>\u003C\u002Ffigure>\u003C\u002Fdiv>\u003Cp>We are all born into different time zones, environments, and upbringings, but there is one thing that we are all taught in common: the philosophy of good and bad. But we are never taught the philosophy of cause and effect. What I feel is that all certainty in our relationships with the world rests on the acknowledgment of cause and its effect. Ours is a world of cause and its effect. Other phenomena cause every phenomenon and give rise to another phenomenon.\u003C\u002Fp>\u003Cp>Certain things happen in our lives, and we question ourselves that “Why does this happen to me? “But that specific cause is the sum-total of the circumstances whose interaction gave rise to that effect, and that will lead to another effect.\u003C\u002Fp>\u003Cp>What I feel good about the philosophy of good and bad is that when good deeds are done, they make us feel confident and empowered, and if something bad is done, it leads to regret about the thing. But the best part about the philosophy of cause and its effect is that we know we are the cause, and so have to bear its effect. That gives us the strength and power to face any problem and makes us feel confident.\u003C\u002Fp>\u003Ch3>\u003Cem>\u003Cstrong>“Shallow men believe in luck or in circumstances. Strong men believe in cause and its effect.” ~ Emerson\u003C\u002Fstrong>\u003C\u002Fem>\u003C\u002Fh3>\u003Cdiv>\u003Chr>\u003C\u002Fdiv>\u003Cp>\u003C\u002Fp>\u003Cdiv class=\"subscription-widget-wrap-editor\" data-attrs=\"{"url":"https:\u002F\u002Fjainprayush9.substack.com\u002Fsubscribe?","text":"Subscribe","language":"en"}\" data-component-name=\"SubscribeWidgetToDOM\">\u003Cdiv class=\"subscription-widget show-subscribe\">\u003Cdiv class=\"preamble\">\u003Cp class=\"cta-caption\">Thanks for reading Prayush’s Substack! Subscribe for free to receive new posts and support my work.\u003C\u002Fp>\u003C\u002Fdiv>\u003Cform class=\"subscription-widget-subscribe\">\u003Cinput type=\"email\" class=\"email-input\" name=\"email\" placeholder=\"Type your email…\" tabindex=\"-1\">\u003Cinput type=\"submit\" class=\"button primary\" value=\"Subscribe\">\u003Cdiv class=\"fake-input-wrapper\">\u003Cdiv class=\"fake-input\">\u003C\u002Fdiv>\u003Cdiv class=\"fake-button\">\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fform>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003Cp>Feel free to reach out and follow me on these social media platforms — \u003Ca href=\"https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fjainprayush9\u002F\">LinkedIn\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Fwww.youtube.com\u002Fchannel\u002FUClTaK5iNKLPdY9uYMq5sTEg\">YouTube\u003C\u002Fa>, \u003Ca href=\"https:\u002F\u002Ftwitter.com\u002Fjainprayush9\">Twitter\u003C\u002Fa>, and \u003Ca href=\"https:\u002F\u002Fwww.instagram.com\u002Fjainprayush9\">Instagram\u003C\u002Fa>.\u003C\u002Fp>",{"slug":325,"title":326,"excerpt":327,"topic":298,"platform":267,"url":328,"xUrl":269,"substackUrl":269,"date":329,"dateLabel":330,"year":321,"readTime":273,"cover":269,"content":331,"full":289},"realizations-you-have-after-5-years-of-coding","Realizations you have after 5+ years of coding","1\u002F Most problems are not technical. The code is usually the easy part. Miscommunication, unclear specs, and changing requirements cause… Continue reading on JavaScript in Plain English »","https:\u002F\u002Fjavascript.plainenglish.io\u002Frealizations-you-have-after-5-years-of-coding-6a3d69f5ff6d","2025-06-29T10:34:13.000Z","Jun 29, 2025","\u003Cfigure class=\"essay-figure\">\u003Cimg src=\"\u002Fimages\u002Fessays\u002Frealizations\u002Fthink-code.png\" alt=\"Think, then code\" loading=\"lazy\" \u002F>\u003Cfigcaption>Think, then code\u003C\u002Ffigcaption>\u003C\u002Ffigure>\n\u003Cp>\u003Cstrong>1\u002F Most problems are not technical.\u003C\u002Fstrong>   The code is usually the easy part. Miscommunication, unclear specs, and changing requirements cause most of the delays.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>2\u002F “It works” is not the same as “it’s done.”\u003C\u002Fstrong>   Working code isn’t always reliable, maintainable, or scalable. The second version is usually better.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>3\u002F Reading code is harder than writing it.\u003C\u002Fstrong>   Clean code isn’t just for others. It’s for your future self, who won’t remember why you did what you did.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>4\u002F You’ll never know everything.\u003C\u002Fstrong>   There’s always a new framework, language, or tool. Learning how to learn is more valuable than trying to master it all. Master the ability to learn, not just the tools themselves.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>5\u002F Tests are not optional.\u003C\u002Fstrong>   Good tests are like insurance. Even small projects benefit from tests. The time you save debugging later is worth the effort upfront.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>6\u002F Technical debt is not always bad.\u003C\u002Fstrong>   Sometimes you need to ship. The key is knowing which shortcuts are reversible and which aren’t.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>7\u002F Good code is simple code.\u003C\u002Fstrong>   Complex solutions often feel smart in the moment but become painful later. Simplicity wins long-term.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>8\u002F Collaboration beats heroism.\u003C\u002Fstrong>   The best engineers aren’t the ones who work alone all night. They’re the ones who elevate the team.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>9\u002F Imposter syndrome never fully goes away.\u003C\u002Fstrong>   Even experienced devs feel it. The difference is, you learn to work through it.\u003C\u002Fp>",{"slug":333,"title":334,"excerpt":335,"topic":14,"platform":267,"url":336,"xUrl":269,"substackUrl":269,"date":337,"dateLabel":338,"year":339,"readTime":273,"cover":269,"content":340,"full":276},"the-power-of-tiny-habits-how-small-changes-lead-to-big-results","The Power of Tiny Habits: How Small Changes Lead to Big Results","Introduction Continue reading on Medium »","https:\u002F\u002Fjainprayush9.medium.com\u002Fthe-power-of-tiny-habits-how-small-changes-lead-to-big-results-d22f462c9e4d","2024-08-19T09:54:41.000Z","Aug 19, 2024",2024,"\u003Cdiv class=\"medium-feed-item\">\u003Cp class=\"medium-feed-snippet\">Introduction\u003C\u002Fp>\u003Cp class=\"medium-feed-link\">\u003Ca href=\"https:\u002F\u002Fjainprayush9.medium.com\u002Fthe-power-of-tiny-habits-how-small-changes-lead-to-big-results-d22f462c9e4d?source=rss-5795ce0c67d5------2\">Continue reading on Medium »\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fdiv>",{"slug":342,"title":343,"excerpt":335,"topic":266,"platform":267,"url":344,"xUrl":269,"substackUrl":269,"date":345,"dateLabel":346,"year":339,"readTime":273,"cover":347,"content":348,"full":276},"a-comprehensive-analysis-of-the-firstcry-brainbees-solutions-ipo-investment-insights-and-risks","A Comprehensive Analysis of the FirstCry (Brainbees Solutions) IPO: Investment Insights and Risks","https:\u002F\u002Fjainprayush9.medium.com\u002Fa-comprehensive-analysis-of-the-firstcry-brainbees-solutions-ipo-investment-insights-and-risks-b5dc964d07e7","2024-08-18T12:40:04.000Z","Aug 18, 2024","https:\u002F\u002Fcdn-images-1.medium.com\u002Fmax\u002F600\u002F0*iOG918Lo5BzHoIpw.jpg","\u003Cdiv class=\"medium-feed-item\">\u003Cp class=\"medium-feed-image\">\u003Ca href=\"https:\u002F\u002Fjainprayush9.medium.com\u002Fa-comprehensive-analysis-of-the-firstcry-brainbees-solutions-ipo-investment-insights-and-risks-b5dc964d07e7?source=rss-5795ce0c67d5------2\">\u003Cimg src=\"https:\u002F\u002Fcdn-images-1.medium.com\u002Fmax\u002F600\u002F0*iOG918Lo5BzHoIpw.jpg\" width=\"600\">\u003C\u002Fa>\u003C\u002Fp>\u003Cp class=\"medium-feed-snippet\">Introduction\u003C\u002Fp>\u003Cp class=\"medium-feed-link\">\u003Ca href=\"https:\u002F\u002Fjainprayush9.medium.com\u002Fa-comprehensive-analysis-of-the-firstcry-brainbees-solutions-ipo-investment-insights-and-risks-b5dc964d07e7?source=rss-5795ce0c67d5------2\">Continue reading on Medium »\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fdiv>",{"slug":350,"title":351,"excerpt":352,"topic":298,"platform":267,"url":353,"xUrl":269,"substackUrl":269,"date":354,"dateLabel":355,"year":339,"readTime":273,"cover":356,"content":357,"full":276},"demystifying-git-your-beginners-guide-to-version-control-collaboration-and-code-management","Demystifying Git: Your Beginner’s Guide to Version Control, Collaboration, and Code Management","Introduction: In the world of software development, managing code efficiently is crucial. Whether you’re working on a solo project or… Continue reading on JavaScript in Plain English »","https:\u002F\u002Fjavascript.plainenglish.io\u002Fdemystifying-git-your-beginners-guide-to-version-control-collaboration-and-code-management-04676fbbfada","2024-05-13T14:27:54.000Z","May 13, 2024","https:\u002F\u002Fcdn-images-1.medium.com\u002Fmax\u002F800\u002F0*2JmybDZfrOcRabcS.png","\u003Cdiv class=\"medium-feed-item\">\u003Cp class=\"medium-feed-image\">\u003Ca href=\"https:\u002F\u002Fjavascript.plainenglish.io\u002Fdemystifying-git-your-beginners-guide-to-version-control-collaboration-and-code-management-04676fbbfada?source=rss-5795ce0c67d5------2\">\u003Cimg src=\"https:\u002F\u002Fcdn-images-1.medium.com\u002Fmax\u002F800\u002F0*2JmybDZfrOcRabcS.png\" width=\"800\">\u003C\u002Fa>\u003C\u002Fp>\u003Cp class=\"medium-feed-snippet\">Introduction:\nIn the world of software development, managing code efficiently is crucial. Whether you’re working on a solo project or…\u003C\u002Fp>\u003Cp class=\"medium-feed-link\">\u003Ca href=\"https:\u002F\u002Fjavascript.plainenglish.io\u002Fdemystifying-git-your-beginners-guide-to-version-control-collaboration-and-code-management-04676fbbfada?source=rss-5795ce0c67d5------2\">Continue reading on JavaScript in Plain English »\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fdiv>",{"slug":359,"title":360,"excerpt":361,"topic":298,"platform":267,"url":362,"xUrl":269,"substackUrl":269,"date":363,"dateLabel":364,"year":365,"readTime":273,"cover":366,"content":367,"full":276},"crafting-a-flawless-software-release","Crafting a Flawless Software Release","In the world of software development, taking a project from the Product Requirement Document (PRD) to a successful release should involve… Continue reading on JavaScript in Plain English »","https:\u002F\u002Fjavascript.plainenglish.io\u002Fcrafting-a-flawless-software-release-e297e5520c16","2023-11-01T08:58:09.000Z","Nov 1, 2023",2023,"https:\u002F\u002Fcdn-images-1.medium.com\u002Fmax\u002F1072\u002F0*5I2qxmaY-ZNW3-ym.png","\u003Cdiv class=\"medium-feed-item\">\u003Cp class=\"medium-feed-image\">\u003Ca href=\"https:\u002F\u002Fjavascript.plainenglish.io\u002Fcrafting-a-flawless-software-release-e297e5520c16?source=rss-5795ce0c67d5------2\">\u003Cimg src=\"https:\u002F\u002Fcdn-images-1.medium.com\u002Fmax\u002F1072\u002F0*5I2qxmaY-ZNW3-ym.png\" width=\"1072\">\u003C\u002Fa>\u003C\u002Fp>\u003Cp class=\"medium-feed-snippet\">In the world of software development, taking a project from the Product Requirement Document (PRD) to a successful release should involve…\u003C\u002Fp>\u003Cp class=\"medium-feed-link\">\u003Ca href=\"https:\u002F\u002Fjavascript.plainenglish.io\u002Fcrafting-a-flawless-software-release-e297e5520c16?source=rss-5795ce0c67d5------2\">Continue reading on JavaScript in Plain English »\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fdiv>",{"slug":369,"title":370,"excerpt":371,"topic":14,"platform":267,"url":372,"xUrl":269,"substackUrl":269,"date":373,"dateLabel":374,"year":365,"readTime":273,"cover":375,"content":376,"full":276},"the-paryushan-a-jain-festival-of-spiritual-reflection-forgiveness-and-purification","The Paryushan: A Jain Festival of Spiritual Reflection, Forgiveness, and Purification","Paryushan is the most important annual religious observance for Jains. It is a time for spiritual reflection, purification, and… Continue reading on No Time »","https:\u002F\u002Fmedium.com\u002Fno-time\u002Fthe-paryushan-a-jain-festival-of-spiritual-reflection-forgiveness-and-purification-e4dcd47d1316","2023-09-22T12:27:13.000Z","Sep 22, 2023","https:\u002F\u002Fcdn-images-1.medium.com\u002Fmax\u002F1262\u002F1*IqeJCCC2zedocDl6wFrNcg.png","\u003Cdiv class=\"medium-feed-item\">\u003Cp class=\"medium-feed-image\">\u003Ca href=\"https:\u002F\u002Fmedium.com\u002Fno-time\u002Fthe-paryushan-a-jain-festival-of-spiritual-reflection-forgiveness-and-purification-e4dcd47d1316?source=rss-5795ce0c67d5------2\">\u003Cimg src=\"https:\u002F\u002Fcdn-images-1.medium.com\u002Fmax\u002F1262\u002F1*IqeJCCC2zedocDl6wFrNcg.png\" width=\"1262\">\u003C\u002Fa>\u003C\u002Fp>\u003Cp class=\"medium-feed-snippet\">Paryushan is the most important annual religious observance for Jains. It is a time for spiritual reflection, purification, and…\u003C\u002Fp>\u003Cp class=\"medium-feed-link\">\u003Ca href=\"https:\u002F\u002Fmedium.com\u002Fno-time\u002Fthe-paryushan-a-jain-festival-of-spiritual-reflection-forgiveness-and-purification-e4dcd47d1316?source=rss-5795ce0c67d5------2\">Continue reading on No Time »\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fdiv>",{"slug":378,"title":379,"excerpt":380,"topic":292,"platform":267,"url":381,"xUrl":269,"substackUrl":269,"date":382,"dateLabel":383,"year":365,"readTime":384,"cover":269,"content":269,"full":276},"airtel-interview","Backend Engineer, Airtel — Interview Experience","An honest account of an interview that didn't end in an offer, and the things it taught me about hiring processes and communication.","https:\u002F\u002Fjainprayush9.medium.com\u002Fbackend-engineer-airtel-interview-experience-india-2022-e78a60af973c","2023-08-23T00:00:00.000Z","Aug 23, 2023","7 min",{"slug":386,"title":387,"excerpt":388,"topic":292,"platform":267,"url":389,"xUrl":269,"substackUrl":269,"date":390,"dateLabel":391,"year":365,"readTime":311,"cover":269,"content":269,"full":276},"clevertap-internship","CleverTap Internship Experience","From final-year student at KIIT to shipping code at CleverTap — what the internship was actually like, and how it turned into a full-time role.","https:\u002F\u002Fjainprayush9.medium.com\u002Fclevertap-internship-experience-india-2022-1db96f8805d4","2023-08-12T00:00:00.000Z","Aug 12, 2023",1789648026942]