LINQPad, the scratchpad for .NET!

A long time ago (Before AI, before agentic engineering), we created code by hand. As a .NET developer, one of the most time-consuming things was crafting complex LINQ queries for the database. I’d execute the app, hit a breakpoint, and start playing with different LINQ expressions in a debugger.

Then I had to create a full Visual Studio project just to test a small piece of logic: a .csproj file, a Program.cs, model definitions, connection strings. All the boilerplate.

Then I found LINQPad.

It let me test code on the fly. No project. No boilerplate. Just a blank .lpd file and a database connection.

The .Dump() method

The most iconic feature of LINQPad is the .Dump() extension method. Instead of Console.WriteLine(), you call .Dump() on any object, collection, or variable:

var customers = db.Customers
    .Where(c => c.Age > 30)
    .Select(c => new { c.Name, c.Email, OrderCount = c.Orders.Count() })
    .Dump();

db.Orders.Where(o => o.Total > 100)
    .GroupBy(o => o.CustomerId)
    .Dump();

LINQPad renders the result in a formatted table or tree view. Inspecting complex nested objects becomes instant, no Console.WriteLine() spam, no manual string formatting.

It’s still a great tool

Sure, IA tools can generate LINQ expressions now. But you still need:

• Ad-hoc exploration — “What does this table actually look like?” → LINQPad.
• Debugging data — “Why did this query slow down?” → LINQPad with a live connection.
• One-off migrations — “Move this column to another table” → LINQPad script.
• Reporting — “Show me top customers by region for last quarter” → LINQPad dashboard.

IA writes the code. LINQPad tests it against your real database, instantly.

Conclusion

LINQPad is a must-have for any .NET developer who works with data. It’s not just a query tool — it’s a thinking companion. When you can type and see results in under three seconds, your relationship with data changes. You stop guessing and start exploring.