The Space Between Your Code: Where Most Bugs Live

𝗬𝗼𝘂𝗿 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗱𝗲 𝗯𝗶𝗹𝗹 𝗶𝘀 𝟰𝟬% 𝗯𝗶𝗴𝗴𝗲𝗿 𝘁𝗵𝗮𝗻 𝗶𝘁 𝘀𝗵𝗼𝘂𝗹𝗱 𝗯𝗲, 𝗮𝗻𝗱 𝘁𝗵𝗲 𝗰𝘂𝗹𝗽𝗿𝗶𝘁 𝗶𝘀 𝗴𝗿𝗲𝗽. 𝗬𝗼𝘂 𝗰𝗮𝗻 𝘀𝗼𝗹𝘃𝗲 𝗶𝘁 𝘄𝗶𝘁𝗵 𝘁𝗵𝗲 𝗽𝗹𝘂𝗴𝗶𝗻 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗻𝘁𝗲𝘅𝘁, 𝘄𝗵𝗶𝗰𝗵 𝗵𝗶𝘁 𝗚𝗶𝘁𝗛𝘂𝗯'𝘀 𝗱𝗮𝗶𝗹𝘆 𝘁𝗿𝗲𝗻𝗱𝗶𝗻𝗴 𝘁𝗵𝗶𝘀 𝘄𝗲𝗲𝗸 𝗮𝘁 𝟴.𝟴𝗸 𝘀𝘁𝗮𝗿𝘀. Every Claude Code search reads thousands of irrelevant lines trying to find the 10 that matter. Grep can't tell that compute_final_cost() and calculate_total_price() are the same concept, so grep grabs everything that might match and hands the whole pile to the model. 𝗧𝗵𝗲 𝗽𝗹𝘂𝗴𝗶𝗻 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 swaps grep for semantic code search. It indexes your repo into a vector database, chunks code by AST so functions stay whole, and uses a Merkle tree so editing one file doesn't re-index the project. The Django YearLookup bug in the benchmark shows 𝘁𝗵𝗲 𝘁𝗼𝗸𝗲𝗻 𝗰𝗼𝘀𝘁 𝗼𝗳 𝗲𝗮𝗰𝗵 𝗮𝗽𝗽𝗿𝗼𝗮𝗰𝗵: • Stock Claude Code burned 130,819 tokens across 8 grep-driven tool calls and still landed on the wrong file. • Claude Code with Claude Context found the fix in 3 calls and 9,036 tokens, 𝗮 𝟵𝟯% 𝘁𝗼𝗸𝗲𝗻 𝗰𝘂𝘁. 𝗔𝗰𝗿𝗼𝘀𝘀 𝘁𝗵𝗲 𝗳𝘂𝗹𝗹 𝗯𝗲𝗻𝗰𝗵𝗺𝗮𝗿𝗸, 𝗖𝗹𝗮𝘂𝗱𝗲 𝗖𝗼𝗻𝘁𝗲𝘅𝘁 𝗮𝘃𝗲𝗿𝗮𝗴𝗲𝘀 𝟰𝟬%+ 𝘁𝗼𝗸𝗲𝗻 𝘀𝗮𝘃𝗶𝗻𝗴𝘀 𝗮𝘁 𝘁𝗵𝗲 𝘀𝗮𝗺𝗲 𝗿𝗲𝗰𝗮𝗹𝗹. Installing Claude Context takes one claude mcp add command, and the same plugin works with Cursor, Gemini CLI, and Cline. 𝗧𝗵𝗲 𝗿𝗲𝗽𝗼 𝗵𝗶𝘁 𝗚𝗶𝘁𝗛𝘂𝗯'𝘀 𝗱𝗮𝗶𝗹𝘆 𝘁𝗿𝗲𝗻𝗱𝗶𝗻𝗴 𝘁𝗵𝗶𝘀 𝘄𝗲𝗲𝗸 𝗮𝗻𝗱 𝗻𝗼𝘄 𝘀𝗶𝘁𝘀 𝗮𝘁 𝟴.𝟴𝗸 𝘀𝘁𝗮𝗿𝘀: 🔗 https://lnkd.in/gBHR9En5

𝐑𝐄𝐒𝐓 𝐢𝐬 𝐍𝐎𝐓 𝐉𝐒𝐎𝐍 🚫📦 I recently took a deep dive into REST API Best Practices (link below!), and it sparked a realization: many people think REST and JSON are the same. They aren't! Think of 𝐑𝐄𝐒𝐓 𝐚𝐬 𝐭𝐡𝐞 𝐑𝐮𝐥𝐞𝐬of the Road (the architecture) and JSON as the Car (the data format). You can drive a truck (XML) or a bike (HTML) on the same road—the rules don't change! The 5 Rules that make an API "RESTful": 𝐂𝐥𝐢𝐞𝐧𝐭-𝐒𝐞𝐫𝐯𝐞𝐫: They work separately. Change your UI without breaking your Database. 𝐒𝐭𝐚𝐭𝐞𝐥𝐞𝐬𝐬: The server doesn't "remember" you. Every request must be a complete package. 𝐂𝐚𝐜𝐡𝐞𝐚𝐛𝐥𝐞: Clients can "save" old answers to speed things up. 𝐋𝐚𝐲𝐞𝐫𝐞𝐝 𝐒𝐲𝐬𝐭𝐞𝐦: The client doesn't care if it's talking to the server directly or via a Load Balancer. 𝐔𝐧𝐢𝐟𝐨𝐫𝐦 𝐈𝐧𝐭𝐞𝐫𝐟𝐚𝐜𝐞: Everything has a specific address (URL) and follows standard request methods. The takeaway? JSON is just the most popular "language," but REST is the high-level design that makes systems scale. 📖 𝐂𝐡𝐞𝐜𝐤 𝐨𝐮𝐭 𝐭𝐡𝐞 𝐝𝐨𝐜𝐮𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧 𝐈'𝐯𝐞 𝐛𝐞𝐞𝐧 𝐬𝐭𝐮𝐝𝐲𝐢𝐧𝐠 𝐡𝐞𝐫𝐞: https://lnkd.in/dte4Zc8e Special Thanks To: Mukesh Murugan #REST #API #WebDev #DotNet #Backend #Coding101 #SoftwareArchitecture What’s your favorite data format to use with REST? Let’s discuss below!

60,000 rows. 1 label. 8 minutes. ⏱️ Nothing crashed. Nothing failed. EF Core was working perfectly. And that’s the problem. ⚠️ It tracked every entity. Held ~1.5GB in memory. 💾 Executed thousands of operations… one by one. Clean. Safe. Predictable. And painfully slow. 🐢 So I rewrote the same logic in raw SQL. Same machine. Same database. Same data. → 6 seconds. ⚡ ~50× faster. 🚀 Let that sink in. This wasn’t optimization. This was tool selection. 🧠 Most developers don’t have a performance problem. They have a wrong abstraction problem. So I made a rule (and I don’t break it): 👇 • CRUD → EF Core • Bulk UPDATE / DELETE → ExecuteUpdate / ExecuteDelete • Bulk INSERT / mapping → Dapper + raw SQL No exceptions. 🔒 Because ORMs are amazing… Until they aren’t. So I built a reference project to prove it: • EF Core + Dapper hybrid architecture ⚙️ • PostgreSQL COPY → 1M rows in seconds 📊 • UNNEST → many-to-many in a single round-trip 🔁 • Loading strategies demo (see the actual SQL) 👀 Built it after wasting hours debugging something that wasn’t even broken. 😅 If you’ve ever seen EF Core “hang”… It wasn’t hanging. It was doing exactly what you asked. Comment “repo” and I’ll send the GitHub link + full breakdown. 📩 Now I’m curious— What’s your strategy for bulk operations? 🤔 • Pure EF Core • Hybrid • Raw SQL only Let’s see where people stand 👇 #dotnet #efcore #dapper #postgresql #performance

Build In Public - Day 30 - Phase 3 - availability-aware discovery flow A few things I worked through: parsing raw query params into a clean internal filter object instead of letting messy request input leak into service logic normalizing free-text search input so matching is more predictable validating date filters strictly with a fixed YYYY-MM-DD contract converting a single selected day into a UTC start/end range so the database can query time windows correctly avoiding an N+1 query pattern by designing search around bulk lookup instead of checking availability one profile at a time One small TypeScript detail I liked here was using function signatures like: function parseDiscoveryFilters(query: Request['query']): DiscoveryFilters That keeps the parser tied directly to the shape of req.query, and makes the boundary between raw HTTP input and trusted application data much clearer. Good search usually needs careful thinking around: input contracts, normalization, time boundaries, query efficiency, response shaping. #buildinpublic #typescript #nodejs #expressjs #backend #softwareengineering #webdevelopment #postgresql #systemdesign

𝐈𝐬 𝐲𝐨𝐮𝐫 𝐀𝐏𝐈 𝐬𝐥𝐨𝐰𝐞𝐫 𝐭𝐡𝐚𝐧 𝐢𝐭 𝐬𝐡𝐨𝐮𝐥𝐝 𝐛𝐞? 𝐓𝐡𝐞 𝐫𝐞𝐚𝐬𝐨𝐧 𝐦𝐢𝐠𝐡𝐭 𝐛𝐞 𝐚 𝐬𝐢𝐧𝐠𝐥𝐞 𝐥𝐢𝐧𝐞 𝐨𝐟 𝐜𝐨𝐝𝐞. In Entity Framework, there is a big difference between building a query and running one. When you use IQueryable, you are just writing instructions. Nothing happens in the database yet. The danger starts when you call .𝑻𝒐𝑳𝒊𝒔𝒕(). This is called "Materialization." It tells your application to stop building the query, go to the database, and pull all that data into your server’s memory. 𝐓𝐡𝐞 𝐰𝐫𝐨𝐧𝐠 𝐰𝐚𝐲: var data = context.Users.ToList().Where(u => u.IsActive); In this case, you fetch every single user from the database first. The filtering happens in your app's RAM. If you have 100,000 users, your app will struggle. 𝐓𝐡𝐞 𝐫𝐢𝐠𝐡𝐭 𝐰𝐚𝐲: var data = context.Users.Where(u => u.IsActive).ToList(); By placing the filter before the list command, EF Core sends a smart SQL query to the database. You only download the users you actually need. 𝐓𝐡𝐞 𝐫𝐮𝐥𝐞 𝐢𝐬 𝐬𝐢𝐦𝐩𝐥𝐞: Use IQueryable to filter, sort, and join. Use .𝑻𝒐𝑳𝒊𝒔𝒕() only when you are ready to use the final results. Build your query fully before you execute it. Your database and your users will thank you. #DotNet #EFCore #EntityFramework #SoftwareEngineering #CleanCode #ProgrammingTips

“Backend is dead.” But that statement is a bit misleading. In many modern apps, especially CRUD-heavy ones, some responsibilities traditionally handled by the backend can actually be moved into the database. One interesting approach is using Row-Level Security (RLS). Instead of writing authorization logic in every API endpoint, the database itself can enforce rules like: Users can only read their own data Users can only update rows they own Unauthorized rows never get returned This shifts part of the security logic closer to the data itself. In this article, I explored: • Why direct frontend → database access is normally dangerous • How Row-Level Security (RLS) changes that equation • How to design policies for real applications (SELECT, INSERT, UPDATE, DELETE) • What people often miss in production setups • And when you still absolutely need a backend The backend isn’t dead — but the way we design it is evolving. 📖 Read the article: https://lnkd.in/giwefsnH I’m also documenting what I’m learning along the way. Backend Engineering from First Principles: https://lnkd.in/g7MJ6TnP System Design from First Principles (HLD + LLD): https://lnkd.in/gateH6Jz #BackendEngineering #SystemDesign #DatabaseDesign #PostgreSQL #SoftwareEngineering

I still remember the first time I opened a database. It felt… intimidating. Tables. Rows. Columns. Strange commands like CREATE, UPDATE, DELETE. And that constant fear: “What if I break something?” So I avoided it. Focused only on frontend. Built UI after UI… But deep down, I knew — I was missing something. Then one day, I tried anyway. Just one simple step: 👉 Created a table 👉 Added one user 👉 Fetched it back And suddenly… It didn’t feel scary anymore. It felt… logical. A database isn’t some complex monster. It’s just: 📦 A place to store data 📥 Get it when you need ✏️ Change it when required 🗑️ Remove it when it’s done That’s it. No chaos. No danger. And that fear you feel right now? It disappears the moment you use it once. Every developer goes through this phase. The ones who grow… don’t avoid it. They try. They break. They learn. 💡 You’re not breaking anything. You’re learning. Start small. One table. One query. That’s all it takes. Comment “DB” and I’ll help you get started with your first database. #WebDevelopment #Databases #SQL #CodingJourney #Developers #LearnToCode #Backend #Skillxa #TechEducation

"𝙄 𝙏𝙝𝙤𝙪𝙜𝙝𝙩 𝙈𝙮 𝙌𝙪𝙚𝙧𝙮 𝙒𝙖𝙨 𝙍𝙪𝙣𝙣𝙞𝙣𝙜... 𝙄𝙩 𝙒𝙖𝙨𝙣’𝙩" I wrote this while building product filters: let query = Product.find({ category: "mobile" }); At that moment, I assumed: Data is already fetched from the database. So I kept modifying it: query = query.sort("price"); query = query.limit(10); 𝐖𝐡𝐚𝐭 𝐈 𝐝𝐢𝐝𝐧’𝐭 𝐫𝐞𝐚𝐥𝐢𝐳𝐞: Nothing had actually executed. find() only creates a query object It does NOT hit the database 𝐖𝐡𝐞𝐫𝐞 𝐭𝐡𝐢𝐬 𝐠𝐨𝐞𝐬 𝐰𝐫𝐨𝐧𝐠: It’s easy to assume: • Data is already in memory • Sorting/filtering is happening in Node.js But in reality: You are just building the query step by step Not executing it 𝐀𝐜𝐭𝐮𝐚𝐥 𝐞𝐱𝐞𝐜𝐮𝐭𝐢𝐨𝐧 𝐡𝐚𝐩𝐩𝐞𝐧𝐬 𝐡𝐞𝐫𝐞: const products = await query; This is the moment MongoDB runs the query: “Give me 10 products sorted by price” 𝐖𝐡𝐲 𝐭𝐡𝐢𝐬 𝐦𝐚𝐭𝐭𝐞𝐫𝐬: If queries executed immediately: • You might fetch thousands of records • Then sort/filter in JavaScript • Slower performance, unnecessary load With lazy execution: • Database handles filtering and sorting • Only required data is returned • Much more efficient ⚡ 𝐒𝐢𝐦𝐩𝐥𝐞 𝐫𝐮𝐥𝐞 𝐈 𝐟𝐨𝐥𝐥𝐨𝐰 𝐧𝐨𝐰: find() → build the query await → execute the query

I recently wrote a blog on something that changed how I design backend systems. Most Django projects start simple - everything in public schema. But as systems grow, especially with GIS + multi-project data, things break: - data duplication - unclear ownership - messy joins I shifted to a schema-based design: 👉 shared geospatial data in public 👉 project-specific data in separate schemas 👉 single source of truth for IDs It completely changed how I think about backend design. If you're dealing with complex or reusable datasets, this approach is worth exploring. 🔗 Read more: https://lnkd.in/dZPPvUyT

hi connections Day 25 of 30: Efficient Data Merging with LeetCode 2722 🚀 Today’s challenge, Join Two Arrays by ID, perfectly mirrors a common task in full-stack development: combining data from different API endpoints or database tables into a single, unified list. The Strategy The key to solving this efficiently is avoiding nested loops (which would lead to slow O(n^2) performance). Instead, I used a Hash Map (Object) approach: Map Creation: Store all items from the first array in an object using their id as the key. Smart Overriding: Iterate through the second array. If an id already exists, use the Spread Operator (...) to merge the objects, ensuring the second array's data takes priority. Final Sorting: Convert the object back into an array and sort it by id to meet the output requirements. Why It Matters This logic is the foundation of modern state management. Whether you're merging updated user profiles in a React frontend or joining related documents in MongoDB, understanding how to handle property overrides and unique identifiers is essential. Using a Map keeps the performance at O(n \log n), making it capable of handling large-scale data without lagging the application. Only 5 days left! The momentum is stronger than ever. 💻✨ #JavaScript #LeetCode