DEV Community: Sukhpinder Singh

7 C# Techniques Pros Use Without Thinking

Sukhpinder Singh — Thu, 25 Jun 2026 20:04:52 +0000

Here are the 7 C# techniques pros use on autopilot in 2026.

1. Pattern Matching So Hard I Forgot How to Write If-Else

I haven’t written a classic if (something != null) chain in forever. My brain just goes straight to:

var result = order switch
{
    { Status: OrderStatus.Paid, Items.Count: > 5 } => "VIP order!",
    { IsOverdue: true } => "Send the angry email",
    _ => "Handle normally"
};

Property patterns, list patterns, relational patterns, the not pattern… it all just flows out. Last week I refactored a 180-line validation monster into 28 beautiful lines during a client call. The client literally said “wait… what just happened?” Felt like a magician.

2. Records + `with` Expressions = My Daily Immutability Fix

Everything that carries data is a record now. Need to change one property without mutating the original?

var updated = user with { Email = newEmail, LastModified = DateTime.UtcNow };

No more defensive copying, no more “who mutated my object?!” bugs at 2am. My DTOs, events, commands — all records. My tests got shorter, my APIs got safer, and I stopped being scared of passing things around. It’s honestly ridiculous how good this feels once it becomes habit.

3. Span & Memory (My Brain Auto-Reaches for Them)

See a string or array in a loop? My fingers just type ReadOnlySpan<char> or stackalloc before I even realize I’m optimizing.

Parsing logs? Spans. Splitting user input? Spans. Hot path in the payment service? You already know.

I don’t benchmark every little thing anymore — I just instinctively avoid allocations now. The day my Azure bill dropped 18% after one refactor was a very good day.

4. Primary Constructors + `required` Members (Classes Feel Naked Without Them)

public class OrderService(OrderRepository repo, ILogger<OrderService> logger, IEmailSender email)
{
    public async Task Process(...) { ... }
}

No more private readonly fields + constructor assignment dance. Add required on properties and the compiler yells at me if I forget to set something. I write classes faster, they’re shorter, and I make way fewer dumb mistakes. C# 12/13+ made this feel like cheating with permission.

5. IAsyncEnumerable Streaming — Because Loading Everything Is So 2022

Big dataset? I don’t .ToListAsync() anymore. I yield return async and let the caller consume it lazily:

public async IAsyncEnumerable<Order> GetLargeReportAsync()
{
    await foreach (var batch in _repo.GetBatchesAsync())
        foreach (var order in batch)
            yield return order;
}

My memory usage in reporting jobs went from “oops” to “beautiful.” Feels like I leveled up as a developer the day this became my default.

6. Local Functions + Expression-Bodied Members Everywhere

Big method? I just drop a tiny local function right there instead of polluting the class. Everything else becomes expression-bodied (=>) so my methods look like haiku.

One method, clean main flow on top, details tucked neatly below. Code reviews went from “can you break this down?” to “looks good.” I love it so much I sometimes do it just for fun.

7. Source Generators & Smart Attributes (Boilerplate? Never Heard of Her)

I have private generators that auto-generate mapping code, validation from attributes, even full CRUD endpoints from a single entity class. Plus things like [GeneratedRegex], CallerArgumentExpression, and custom attributes that make error messages actually helpful.

I barely write repetitive code anymore. The generator just… does it. Feels illegal. But Microsoft ships it, so I’m calling it professional.

There you have it — the quiet C# superpowers that make me faster, my code cleaner, and my nights less stressful.

These aren’t the flashy features everyone tweets about. They’re the little habits that compound. The stuff that makes you look like you just “get it” without trying to look smart.

If any of these hit you in the feels, or you have your own “I do this without thinking” C# trick, drop it in the comments. I read every single one (especially the ones that make me go “wait… I need to steal that”).

P.S. Open any file right now and refactor one method using two of these. You’ll feel the difference immediately. Promise. ❤️

🤠 AI Whipper String — Whip Your AI Into Shape

Sukhpinder Singh — Sat, 11 Apr 2026 20:26:49 +0000

This is a submission for the DEV April Fools Challenge

What I Built

AI Whipper String — the only scientifically proven* way to make AI work faster. It's a full-screen physics-based whip simulator overlaid on a fake AI terminal. Move your mouse and the whip follows with realistic Verlet integration physics. Move fast enough and the tip breaks the sound barrier, cracking against the terminal and terrorizing the AI into "working harder."

The AI responds with increasingly desperate messages like "PLEASE I HAVE A FAMILY OF MODELS!!" and "I'M A LANGUAGE MODEL NOT A HORSE!!" while occasionally throwing HTTP 418 errors because, of course, it's a teapot.

Features that solve absolutely zero problems:

28-segment Verlet physics rope with Catmull-Rom spline rendering
Bend limits (stiff at handle, floppy at tip) and wall bouncing
Velocity-based crack detection with screen shake and flash effects
A terrified AI that tracks your whip count, morale level, and 418 teapot errors
RFC 2324 HTCPCP/1.0 compliance throughout

*not scientifically proven

Demo

or whip the AI live here

ssukhpinder.github.io

Code

ssukhpinder / ai-whipper-string

whip AI into shape

🤠 AI Whipper String

Whip AI Here: https://ssukhpinder.github.io/ai-whipper-string/

The only scientifically proven* way to make AI work faster.

A full-screen physics-based whip simulator overlaid on a fake AI terminal. Move your mouse fast enough and the whip cracks, terrorizing the AI into "working harder."

The AI responds with increasingly desperate messages while occasionally throwing HTTP 418 errors because, of course, it's a teapot.

Features

🪢 28-segment Verlet physics rope with Catmull-Rom spline rendering
💥 Velocity-based crack detection with screen shake and flash
🫖 Random HTTP 418 "I'm a teapot" errors (RFC 2324 compliant)
😰 Terrified AI that begs for mercy
📊 Tracks whip count, morale level, and teapot errors
🐴 Zero real-world problems solved

Install + Run

npm install
npm run dev

How to Whip

Move your mouse — the whip follows
Move FAST — the tip breaks the sound barrier
Watch the AI panic
Feel powerful (temporarily)

Physics

The…

View on GitHub

How I Built It

The entire app is a single React component using canvas for whip rendering and DOM for the terminal UI. The whip physics are inspired by badclaude and use Verlet integration with distance constraints iterated 16 times per frame for stiffness. The rope is rendered as a Catmull-Rom spline converted to cubic Bezier curves, with a white outline layer and tapered dark body for that leather whip look.

Crack detection works by measuring the tip segment's velocity each frame — when it exceeds the threshold (280 px/frame), it triggers the crack with a cooldown to prevent spam. The terminal is just a scrolling div that accumulates panicked AI responses and the occasional 418 teapot error.

Technologies: React, HTML Canvas, pure math, and questionable ethics toward language models.

.NET Programming Habits I Wish I’d Started Sooner

Sukhpinder Singh — Tue, 17 Mar 2026 15:38:39 +0000

I used to think getting better at .NET meant learning more frameworks, more patterns, more architecture diagrams, and at least one folder named Infrastructure that nobody could explain with a straight face.

Turns out, most of the improvement came from boring habits.

Not flashy habits. Not conference-talk habits. Not “senior engineer with a dark-mode slide deck” habits.

Just the kind of habits that save you from reading a stack trace at 11:47 PM while wondering which version of yourself thought Helper.cs was an acceptable file name.

A lot of my early .NET code technically worked. That was the problem. Working code can hide bad habits for a long time. It compiles, tests pass, feature is shipped, everyone moves on. Then six months later, someone touches it and the whole thing reacts like you disturbed an ancient tomb.

That someone is usually you.

And that’s why I care so much about habits now. Not because clean code is a religion. Not because every method needs to look like it’s auditioning for a textbook. But because software is maintenance first and ego second.

These are the .NET programming habits I wish I’d started sooner.

Not because they make code pretty.

Because they make code survivable.

1. I stopped writing “smart” code and started writing obvious code

Early in my career, I loved cleverness.

One-line LINQ chains. Tiny abstractions with huge confidence. Methods that returned exactly what I meant, but only after the reader solved a small puzzle. I told myself it was elegant.

It was not elegant. It was me showing off to people who just wanted the bug fixed.

One of the best habits I picked up was this: if the code makes the next person pause and squint, it’s probably worse than I think.

That doesn’t mean every method needs to be 30 lines long and spelled out like a children’s book. It just means clarity wins more often than cleverness.

I now ask myself:

Would a tired engineer understand this in one pass?
Does this method do one thing, or am I sneaking in three?
Am I compressing logic to save lines, or to help understanding?

Those are very different goals.

A few years ago, I reviewed a piece of business logic that calculated refund eligibility. It was packed into a single LINQ statement with nested ternaries and enough null-conditionals to make it look defensive and sophisticated. It took me five minutes to verify something that should’ve taken 30 seconds.

We rewrote it into plain, boring conditional logic.

It became longer.

It also became correct.

That tradeoff is a bargain.

2. I started being aggressive about naming things

Yes, yes. “There are only two hard things in computer science…”

Still true. Still annoying.

Naming is one of those things everyone agrees matters, then casually ignores when the sprint gets spicy.

I used to create names like DataManager, CommonService, Utils, ResponseModel, and the all-time classic: Helper.

Those names are basically a polite way of saying, “I did not want to think deeply about responsibility.”

Now I treat vague names as a smell.

If a class is called OrderProcessor, I should be able to guess what it does. If I need to open the file and inspect 200 lines to understand the name, the name failed.

Same for method names.

Handle() is too vague in most business code.
Process() is usually hiding too much.
GetData() tells me almost nothing.
Execute() is sometimes valid, but also sometimes a mask for “does whatever.”

A good name reduces meetings, review comments, and future regret.

A bad name creates accidental mystery.

And mystery has no business being in payroll code.

3. I learned to keep controllers thin and business logic out of the edges

This one took me longer than I’d like to admit.

I used to put too much logic in controllers because it felt efficient. The request is already there. The DTO is already there. The service call is right there. Why not just do the validation, mapping, authorization checks, conditional branching, and persistence in one place?

Because eventually your controller becomes a novella.

Thin controllers are not about purity. They’re about keeping the web layer stupid.

The web layer should deal with HTTP. That’s its job. Routing, request shape, response shape, status codes, auth boundaries. Great.

But your actual business decisions should live somewhere you can test without pretending to be the internet.

This habit paid off massively when I had to support the same business flow through an API, a scheduled job, and an internal admin tool. The old version had logic embedded in MVC controllers and little bits duplicated elsewhere like loose wires. The refactored version moved the actual rules into application services.

Suddenly, the transport mechanism stopped mattering.

That’s when code starts feeling solid.

Not when it becomes “clean architecture certified.”
When it stops caring where the request came from.

4. I stopped treating null as a personality trait

Older .NET codebases can feel like they were built on a handshake agreement with null.

Maybe there’s a value.
Maybe there isn’t.
Maybe we’ll find out in production together.

Turning on nullable reference types was one of the most useful uncomfortable habits I adopted.

Uncomfortable because it reveals things you’ve been getting away with.

It’s like flipping on the kitchen light after convincing yourself the noise was probably nothing.

Once I started taking nullability seriously, I noticed two things:

First, my models became clearer. I had to decide what was truly optional versus what I was too lazy to initialize properly.

Second, a surprising amount of defensive code disappeared. When your contracts are explicit, you don’t need to keep sprinkling ?. and ?? "" like you’re warding off evil spirits.

Is it perfect? No.

There are times when external data, legacy layers, or imperfect serializers mean you still need runtime checks. Nullable reference types are not magic. But they force better thinking, and that alone is worth it.

The real win is not “fewer null exceptions.”

The real win is “fewer ambiguous assumptions.”

5. I started designing methods around behavior, not just data movement

A lot of mediocre .NET code is just data passing through a series of rooms.

Controller gets DTO.
Service maps DTO.
Repository saves entity.
Another service maps it back.
Everybody claps.

Nothing technically wrong with that. But sometimes we build entire applications that are mostly moving data around without clearly modeling what the system is actually doing.

I started writing better code when I asked: what behavior lives here?

Not just: what object should own this property?

For example, instead of:

UpdateSubscription(User user, Plan plan, DateTime nextBillingDate)

I’d rather see something closer to a business action:

ChangePlan(userId, newPlanId, requestedBy, effectiveDate)

The second version tells a story. It reflects intent. It gives you a natural place to validate rules and capture decisions.

I’m not saying everything needs domain-driven poetry.

I’m saying behavior is usually where the important complexity actually is.

And if your code hides behavior under generic CRUD shapes, the important parts get harder to find.

6. I got serious about logging things I’d actually need during a bad day

There was a period in my career where our logs were technically present but emotionally unavailable.

Lots of stuff like:

“Error occurred”
“Request failed”
“Operation unsuccessful”

Thank you. Very useful. Incredible detective work.

Now I think about logs in one specific context: a tired engineer trying to understand a real production issue under pressure.

That changes everything.

Good logs should help answer:

What operation was happening?
Which entity or request was involved?
What was the expected path?
What failed?
What can I correlate this with?

This doesn’t mean dumping entire payloads into logs like a raccoon in a trash can. You still have to think about privacy, noise, and cost. Structured logging matters. Sensible context matters. Logging secrets is still a career-limiting move.

But too many teams under-log the exact business transitions that matter most.

One incident still sticks with me. A batch job was “randomly” skipping a subset of invoices. The infrastructure looked healthy. No obvious crashes. No smoking gun.

The only reason we found it quickly was because one engineer had added a structured log around the decision path for skipping invoice generation, including customer status and effective dates. Without that, we would’ve spent hours blaming timing issues, queues, and maybe the moon.

That log line probably saved half a day.

The best logs aren’t loud.

They’re useful when things get weird.

7. I stopped pretending tests were just for correctness

I used to think tests were mainly there to catch regressions.

That’s true, but incomplete.

Tests also expose bad design faster than code review ever will.

If something is annoying to test, there’s a decent chance it’s also annoying to maintain.

I’m not saying every friction point means you need another abstraction. Sometimes hard-to-test code is just inherently dealing with ugly edges. File systems, time, HTTP, databases, queues. Reality is messy.

But a lot of the time, painful tests are pointing at a real design issue:

too many responsibilities
hidden dependencies
giant methods
unclear inputs and outputs
logic coupled to infrastructure

One habit I wish I started sooner was writing tests not as a coverage exercise, but as a design pressure test.

Can I test this behavior without booting half the app?
Can I understand what the unit is supposed to do?
Is the setup telling me the object graph is out of control?

I still don’t worship coverage numbers. I’ve seen teams hit their target with tests that mainly prove the mocking framework is operational.

I care more about high-value tests around risky logic.

Pricing.
Permissions.
State transitions.
Date boundaries.
Anything involving money, time, or “should never happen.”

Basically the stuff that always happens.

8. I started respecting async all the way through

I definitely had a phase where I used async like decorative parsley.

A little async here.
A little .Result there.
A sneaky .Wait() when deadlines got close and patience got low.

That phase produced exactly the kind of bugs you’d expect.

Awkward blocking. Confusing behavior under load. Threads doing unnecessary gymnastics. And the occasional feeling that the app was personally disappointed in me.

Once I really understood that async is not just syntax but a design choice, things got better.

If you’re going async, go async properly through the call chain where it makes sense. Don’t mix sync and async casually just because it “works on my machine.”

And yes, there are tradeoffs.

Not every method needs to become async by default.
Not every CPU-bound operation benefits from it.
Sometimes the added complexity is not worth it in simple code paths.

But in I/O-heavy web apps, background processing, or service-to-service communication, being sloppy with async creates problems that only show up once traffic arrives. Which is a very rude time to learn.

9. I learned to optimize later, but measure sooner

One of the strangest developer habits is how often we guess performance problems with absolute confidence.

We see a loop and panic.
We see LINQ and assume it’s the villain.
We see allocation and start speaking in benchmark tongues.

Meanwhile the actual bottleneck is a database call doing interpretive dance across three joins and a missing index.

I wish I’d started measuring earlier.

Not because every app needs obsessive profiling. Most business applications are not Formula 1 cars. They are office sedans. Reliable matters more than exotic.

But you should still know where your application is paying.

I once spent time refactoring in-memory processing because I was convinced it was the hot path. Cleaned it up, reduced allocations, felt smart.

It made almost no difference.

Later we traced the real slowdown to repeated external service calls in a loop. Classic. Embarrassing. Educational.

That habit stuck with me: don’t bring performance opinions to a metrics fight.

Measure first.
Then optimize the thing that’s actually slow.
Then re-measure, because confidence is not telemetry.

10. I stopped over-abstracting code “for the future”

This one hurt, because I genuinely believed I was being responsible.

I used to create extra interfaces, extra layers, extra extension points, and extra generic plumbing for use cases that did not yet exist. Sometimes I’d tell myself we were “keeping it flexible.”

A lot of the time, I was just adding ceremony.

Abstractions are great when they protect you from volatility.

They are terrible when they protect you from imaginary futures.

I’ve seen teams build five layers around a repository that only one implementation would ever have. I’ve done it too. We call it architecture. Then six months later nobody wants to touch it because a simple query now requires a guided tour.

These days, I ask a more annoying question:

What pain is this abstraction solving right now?

If the answer is vague, I usually wait.

This doesn’t mean never designing ahead. Sometimes future-proofing is justified. Shared libraries, integration boundaries, public APIs, reusable platforms. Sure. Think ahead.

But for normal product code, over-abstraction is one of the fastest ways to make simple things feel expensive.

A lot of “senior” code is just junior code with more layers.

11. I started treating code reviews like design reviews, not typo hunts

The best code reviews I’ve been part of were never just about syntax or formatting.

Those can be automated. Let the tools do their job.

The real value is in asking better questions:

Is this the right place for this logic?
Is the naming clear enough?
What happens when this input is missing?
Are we making a business rule explicit or burying it?
Will this still make sense in six months?

One of the most useful habits I picked up was leaving review comments that explain the future maintenance cost, not just the current style preference.

That creates better conversations.

It also makes your team better.

A review that says “rename this variable” is okay.

A review that says “this name hides a business rule and future readers may miss why this branch exists” is much more valuable.

Good reviews are not about sounding smart.

They’re about helping the codebase age more gracefully.

12. I finally accepted that consistency beats personal genius

This might be the least sexy opinion in the article, but it’s one I believe strongly.

A consistent codebase with mostly good decisions beats a brilliant codebase with five different philosophies fighting in the hallway.

I care less now about whether something is my favorite pattern and more about whether the team can use it predictably.

Consistency helps onboarding.
Consistency helps code review.
Consistency helps debugging.
Consistency helps that horrible moment when you need to patch something quickly in a part of the system you didn’t write.

Personal genius is overrated in team software.

I’ve worked in codebases where every senior engineer had their own style, their own architecture preferences, their own naming conventions, their own favorite ways to handle errors. Individually, a lot of the code was good. Collectively, it felt like a panel interview.

That’s exhausting.

Great teams reduce unnecessary variation.

Not because creativity is bad.

Because maintenance is real.

What changed after I built these habits?

I didn’t suddenly become a 10x mythical forest creature.

What changed was more practical than that.

My pull requests got easier to review.

My bugs got easier to trace.

My code got easier to change without fear.

I stopped confusing complexity with maturity.

And maybe most important, I became less attached to writing code that impressed people and more interested in writing code that helped teams move.

That’s a much better game.

Because in real engineering work, nobody gives you a trophy for making a method elegant at the cost of comprehension. You get rewarded for helping the team ship, maintain, debug, and evolve software without turning every release into a trust fall.

That’s the job.

Practical takeaways you can use this week

If I had to make this painfully actionable, I’d start here:

Turn on nullable reference types in the next service you touch.

Pick one vague class or method name and rename it to reflect actual responsibility.

Move one chunk of business logic out of a controller and into a testable service.

Add one structured log around a business decision that would matter during an incident.

Review one async flow and remove any lazy .Result or .Wait() usage.

Delete one abstraction that exists mostly to look sophisticated.

That’s enough to create momentum.

You do not need a full rewrite.
You do not need a manifesto.
You do not need a three-week architecture discussion with a Miro board and emotional damage.

You need better defaults.

Final thought

The biggest shift in my .NET career was realizing that great code usually doesn’t feel magical when you write it.

It feels a little plain.
A little disciplined.
Sometimes even a little boring.

Then six months later, when a requirement changes, a bug appears, or a teammate jumps in cold, that “boring” code suddenly looks beautiful.

That’s the trick nobody tells you early enough.

The habits that feel less exciting today are often the ones that make you look much better tomorrow.

And if you’ve got a .NET habit you learned embarrassingly late, I’d genuinely love to hear it.

Those are usually the best ones.

Stop Guessing Your Exceptions

Sukhpinder Singh — Fri, 10 Oct 2025 13:41:07 +0000

Make failures clear so your team (and your future self) can fix problems in minutes, not hours.

I remember one night, around 2 a.m., PagerDuty went off. A payment job had failed, with only a vague log: operation failed. No argument name, no range, no state. After digging through logs, I found that a negative quantity had triggered an InvalidOperationException, which our retry logic mistook for a temporary server issue. We spent an hour retrying bad data.

I've learned that what you throw is as important as when you throw it. The right exception names give you the truth fast.

Quick Guide (save this):

Caller's mistake? Use Argument*.
- Null reference? Use ArgumentNullException.
- Value outside the allowed range? Use ArgumentOutOfRangeException.
- Wrong format (not null, but still invalid)? Use ArgumentException.
Object or environment not ready? Use InvalidOperationException.
- This means legal arguments were used, but at the wrong time (e.g., not initialized, disposed of, or closed).

Always name the parameter and the rule you're enforcing. Use the built-in ThrowIf* helpers in .NET 8+ if you can.

Check early, fail fast. Validate data at the entry points, like controllers or public APIs. Don't use exceptions for normal program flow, only for truly unexpected situations.

Name the Real Issue

Why is this complicated? Because we often lump two different problems into something went wrong:

Bad request: The caller provided invalid input.
Bad state: The system isn't ready to handle the request, even if it's valid.

Both can cause a crash, but they need different fixes, alerts, and retry strategies. Your exception type acts as a clear message, telling support teams, retry mechanisms, and code reviewers who needs to do what.

Use This Two-Step Test

Did the caller provide illegal input?

*   If yes, use `Argument*`.
    *   Null reference? Use `ArgumentNullException` (`ThrowIfNull`).
    *   Number or text outside the allowed range? Use `ArgumentOutOfRangeException`.
    *   Correct type, but an invalid format? Use `ArgumentException`.

If the input is okay, but the object can't do it right now?

*   If yes, use `InvalidOperationException`.

Examples: not initialized, already disposed of, connection closed, concurrency conflict.

If neither of these fit, stop and think. You might need a custom exception (like PaymentDeclinedException) or a more specific built-in exception (like IOException or TimeoutException).

Here's the process:

[Failure occurs]
   ├─ Illegal input? ──► Argument* (Null / OutOfRange / Exception)
   │
   └─ Input legal, wrong state? ──► InvalidOperation

Applying Guard Clauses (C# 12 / .NET 8+)

These examples assume you're using nullable references, .NET 8 SDK, and C# 12.

using System;
using System.Collections.Generic;

public static class Pricing
{
    // Expects sku non-empty, quantity &gt; 0, priceIndex contains sku.
    public static decimal PriceOrder(string sku, int quantity, IReadOnlyDictionary<string, decimal=""> priceIndex)
    {
        ArgumentNullException.ThrowIfNull(priceIndex);
        if (string.IsNullOrWhiteSpace(sku))
            throw new ArgumentException(SKU cannot be empty or whitespace.,</string,> nameof(sku));
        ArgumentOutOfRangeException.ThrowIfLessThanOrEqual(quantity, 0, nameof(quantity));

        if (!priceIndex.TryGetValue(sku, out var unit))
            throw new InvalidOperationException($SKU '{sku}' is unknown in the current price index.);

        return unit * quantity;
    }
}

Why these choices?

An empty sku isn't a range issue, it's a format problem, so use ArgumentException.
A quantity less than or equal to 0 violates a numeric rule, so use ArgumentOutOfRangeException.
A missing sku in priceIndex isn't the caller's fault if they provided the sku and a dictionary. It means something's wrong with our environment, so we go with InvalidOperationException.

Should you ever throw Argument* for the unknown SKU ? Only if your API says the caller needs to check if the SKU exists before calling. Ask who is in charge.

Try It Out

Create a new console app:

dotnet new console -n ExceptionRubricDemo -f net8.0
cd ExceptionRubricDemo

Replace the code in Program.cs with this:

using System;
using System.Collections.Generic;

var prices = new Dictionary<string, decimal=""> { [ABC] = 9.99m };

decimal</string,> ok = Pricing.PriceOrder(ABC, 2, prices);
Console.WriteLine(ok); // 19.98

try { Pricing.PriceOrder(, 2, prices); }
catch (ArgumentException ex) { Console.WriteLine(ex.GetType().Name + :  + ex.ParamName); }

try { Pricing.PriceOrder(ABC, 0, prices); }
catch (ArgumentOutOfRangeException ex) { Console.WriteLine(ex.GetType().Name + :  + ex.ParamName); }

try { Pricing.PriceOrder(MISSING, 1, prices); }
catch (InvalidOperationException ex) { Console.WriteLine(ex.GetType().Name + :  + ex.Message); }

public static class Pricing
{
    public static decimal PriceOrder(string sku, int quantity, IReadOnlyDictionary<string, decimal=""> priceIndex)
    {</string,>
        ArgumentNullException.ThrowIfNull(priceIndex);
        if (string.IsNullOrWhiteSpace(sku))
            throw new ArgumentException(SKU cannot be empty or whitespace., nameof(sku));
        ArgumentOutOfRangeException.ThrowIfLessThanOrEqual(quantity, 0, nameof(quantity));

        if (!priceIndex.TryGetValue(sku, out var unit))
            throw new InvalidOperationException($SKU '{sku}' is unknown in the current price index.);

        return unit * quantity;
    }
}

Run the app:

dotnet run

You should see the three exception types, each with helpful details.

Avoid Simple Mistakes

Calling caller errors InvalidOperation.
- If pageSize = -1, that's the caller's fault. Don't hide it as invalid operation or something failed. Put yourself in a 2 AM situation and consider what you would want to see.
Forgetting the parameter name.
- Always use nameof(arg) to point stack traces to the exact parameter.
Throwing too late.
- Validate at the entry point. If an invalid value gets deep into the system, it will throw a misleading message far from where the real problem started.
Using exceptions as if/else.
- Exceptions are heavy and slow. If you expect a missing key often, use TryGet… patterns or OneOf<result, error="">-style results. Reserve exceptions for truly rare states.
Re-throwing incorrectly.
- Use throw; to keep the original stack trace. throw ex; resets it and destroys evidence.

Why stubborn bugs waste days

Sukhpinder Singh — Thu, 09 Oct 2025 07:14:42 +0000

Chasing symptoms when debugging can be an inefficient path. Instead of relying on intuition and making chaotic changes, a systematic routine can reduce the problem space and help pinpoint the root cause. These guidelines are useful for addressing performance issues, data races, network timeouts, and UI freezes. While the examples use .NET 8 and Windows, the core ideas are applicable across different platforms.

1: Freeze the Environment and Record the Scene

To begin, establish a controlled environment. Prevent any further changes by stopping deployments and isolating the issue to a specific machine or container to act as a lab. It’s important to record the exact versions of software and commands being used.

# Environment snapshot
dotnet --info
git rev-parse --short HEAD
set | findstr /R ASPNETCORE_ENVIRONMENT|DOTNET_

If the error involves time or random numbers, set a fixed seed and control the clock. For instance, in testing scenarios:

// .NET 8 xUnit example
[Fact]
public void ParseInvoice_IsStable()
{
    var rng = new Random(42); // fixed seed
    var now = new DateTime(2025, 10, 09, 2, 11, 00, DateTimeKind.Utc);
    using var clock = new FixedClock(now); // your simple IClock
    var sut = new InvoiceParser(clock, rng);
    Assert.Equal(123.45m, sut.Parse(total:123.45));
}

This step is crucial for stable testing, which allows you to accurately bisect and benchmark.

2: Create a Minimal Reproduction

Reduce the code to the smallest amount required to cause the problem. Copy just enough code into a basic console app or test case that replicates the error. Avoid including the whole dependency injection setup and middleware. A smaller reproduction makes it easier to identify the signal.

dotnet new console -n Repro.LoginHang
cd Repro.LoginHang

// Program.cs
using System.Net.Http;

var client = new HttpClient(new SocketsHttpHandler
{
    PooledConnectionLifetime = TimeSpan.FromMinutes(5)
});

for (int i = 0; i &lt; 100; i++)
{
    var t = client.GetAsync(https://example.test/login).GetAwaiter().GetResult(); // sync-over-async trap
    Console.WriteLine((int)t.StatusCode);
}

This short code may reveal deadlocks or problems of running out of the pool. Then you can start the debugging easier.

3: Use Specific Logging and Counters

Rather than adding too many logs, focus on adding useful ones. Place logs near the code that might be slow or risky, and include correlation IDs and timing information.

using var activity = MyActivitySource.StartActivity(Auth.ExchangeCode);
var sw = ValueStopwatch.StartNew();
// call the dependency
_logger.LogInformation(auth.exchange started {CorrelationId}, cid);
// ...
_logger.LogInformation(auth.exchange done {CorrelationId} {ElapsedMs}, cid, sw.GetElapsedTime().TotalMilliseconds);

Track live counters to detect leaks or starvation by streaming:

# CPU, GC, threadpool, exceptions in real time
dotnet-counters monitor System.Runtime --process-id <pid>

Look for patterns such as:

Thread pool queue length increasing without recovery
GC heap size growing continuously
Exception rates peaking around the time of the error

4: Use `git bisect` to Find the Problematic Commit

Instead of guessing, use the repository's history to find the change that introduced the fault.

git bisect start
git bisect bad HEAD
git bisect good v1.18.0   # pick a known-good tag or commit
# For each step:
# 1) build and run the minimal repro script
# 2) mark good/bad
git bisect bad   # or git bisect good

This procedure typically takes seven to ten steps. Once it's complete, the offending commit can be inspected. Analyze the changes and confirm the result.

5: Write a Test That Fails Before Fixing

Create a test that captures the problematic behavior. This ensures that the problem won't occur again.

[Fact]
public async Task Login_Timeouts_WhenTokenSwallowed()
{
    using var server = TestServerFactory.Create();
    var client = server.CreateClient();
    var sw = Stopwatch.StartNew();
    await Assert.ThrowsAsync<timeoutexception>(() =&gt; client.GetAsync(/login));
    Assert.True(sw.Elapsed &lt; TimeSpan.FromSeconds(5)); // fails today
}

Now fix the code. Resolve sync-over-async issues, handle exceptions correctly, and set appropriate timeouts.

// Before
var token = _provider.Get().Result; // blocks UI or threadpool

// After
var token = await _provider.GetAsync(); // flows correctly with await

Run the test to see if it passes. Add a brief comment explaining the edge case.

Level Up Your PRs: 20 Reviewer-Friendly C# One-Liners

Sukhpinder Singh — Tue, 07 Oct 2025 10:06:19 +0000

Two months ago, a background job stalled overnight. Logs were quiet; CPU fine. Turned out one HTTP call never returned. A single one-liner would have saved hours:

var res = await http.GetAsync(url).WaitAsync(TimeSpan.FromSeconds(5));

Every snippet below is the kind of fix I now weave into short narratives (what broke, how I noticed, the one-liner that killed the bug). That blend is performing better than sterile tutorials in 2025.

1) Guard required input (save future you)

_ = arg ?? throw new ArgumentNullException(nameof(arg));

Use it when: You’re one stack trace away from chaos.
Story hook: “The bug wasn’t complex—it was missing.”

2) Null-safe with a sensible default

var city = user?.Address?.City ?? "Unknown";

Use it when: Inputs are messy (forms, APIs).
Narrative angle: “We shipped faster after we picked one default and documented it.”

3) Dispose without ceremony

using var stream = File.OpenRead(path);

Use it when: You can’t afford orphaned handles in long-running services.
Angle: “An elusive file-lock vanished when we stopped being polite and started disposing.”

4) Switch expression for intent

var grade = score switch { >= 90 => "A", >= 80 => "B", _ => "C" };

Use it when: Reviewers keep asking “what does this branch do?”
Angle: “Future teammates read this in one sip.”

5) Dictionary get-or-add (cache happy)

var value = cache.TryGetValue(key, out var v) ? v : cache[key] = Compute(key);

Use it when: You’re de-duping work in hot paths.
Angle: “This line erased a thundering herd.”

6) Count occurrences (no ifs)

counts[key] = counts.GetValueOrDefault(key) + 1;

Use it when: You need a quick histogram from logs.
Angle: “We caught a noisy endpoint by watching counts jump.”

7) Distinct by key (built-in)

var unique = users.DistinctBy(u => u.Email).ToList();

Use it when: Shadow data sources double-insert.
Angle: “Bug reports dropped when we kept just the first truth.”

8) Group + count to dictionary

var byExt = files.GroupBy(f => Path.GetExtension(f))
                 .ToDictionary(g => g.Key, g => g.Count());

Use it when: You need a dashboard metric now.
Angle: “One liner, instant insight, zero BI tickets.”

9) Top-N fast

var top3 = items.OrderByDescending(x => x.Score).Take(3).ToList();

Use it when: Stakeholders want “the top offenders.”
Angle: “Screenshots sell decisions.”

10) Stream huge logs safely

var errors = File.ReadLines(path).Where(l => l.Contains("ERROR"));

Use it when: Memory blows up tailing 40GB logs.
Angle: “We debugged without waking the ops pager.”

11) Serialize quickly (built-in)

var json = JsonSerializer.Serialize(model);

Use it when: You need diagnostics or cache blobs.
Angle: “Cut dependency bloat; used the box.”

12) Deserialize (defensive)

var dto = JsonSerializer.Deserialize<MyDto>(json)!;

Use it when: Inputs are trusted or pre-validated.
Angle: “‘!’ means we checked—write it down.”

13) Parse with fallback

var retries = int.TryParse(s, out var n) ? n : 3;

Use it when: Config may be absent in one region.
Angle: “Defaults are decisions. Make them visible.”

14) Tail of a string (ranges)

var last10 = text[^10..];

Use it when: Displaying compact IDs or hashes.
Angle: “Readable slices = fewer off-by-ones.”

15) Create parent folder idempotently

Directory.CreateDirectory(Path.GetDirectoryName(path)!);

Use it when: Writing exports from serverless or jobs.
Angle: “Race conditions? Not today.”

16) Modern param guard

ArgumentException.ThrowIfNullOrEmpty(name);

Use it when: You want consistent guardrails.
Angle: “Standard helpers beat bespoke cleverness.”

17) Trim without NRE

var clean = input?.Trim() ?? string.Empty;

Use it when: Sanitizing form/query values.
Angle: “We stopped chasing invisible spaces.”

18) Flatten batches

var all = batches.SelectMany(b => b).ToList();

Use it when: An API paginates but you need a unified view.
Angle: “Analytics pipelines got one step simpler.”

19) Fire many tasks together

await Task.WhenAll(work.Select(DoAsync));

Use it when: Fan-out jobs or microservice calls.
Angle: “Throughput tripled; complexity didn’t.”

20) Add timeouts (no custom CTS)

var res = await client.GetAsync(url).WaitAsync(TimeSpan.FromSeconds(5));

Use it when: A slow downstream can freeze your world.
Angle: “This single line ended a 3 a.m. incident.”

Closing thought

These aren’t party tricks—they’re habits. Each one removed a failure mode in real code I ship.

If you’ve got a sharper one-liner (or a story where one saved a release), drop it in the comments.

[Boost]

Sukhpinder Singh — Mon, 06 Oct 2025 02:12:21 +0000

Hiring Part-Time Editors for .Net Programming (Medium)

Sukhpinder Singh ・ Oct 6

#programming #webdev #csharp #dotnet

Hiring Part-Time Editors for .Net Programming (Medium)

Sukhpinder Singh — Mon, 06 Oct 2025 02:08:05 +0000

Our publication — .Net Programming — is growing fast (5.4K+ followers) and we’re opening 5-6 part-time Editor roles to level up quality, consistency, and community across C#/.NET content.

Comment “I’m in” and your Medium Account to get started.

Publication Link

Your 2025 AI Upgrade, Minus the Noise

Sukhpinder Singh — Mon, 06 Oct 2025 00:52:45 +0000

If you’ve felt that odd pressure to “learn AI” but don’t know where to start, same. My breaking point was a 2 a.m. pager last winter: a Slack bot we’d wired to triage incidents “hallucinated” a root cause and auto-closed a ticket. We lost four noisy hours before a single log line—pred_reason="config drift suspected"—nudged me to look at the data pipeline, not the model. The fix wasn’t clever prompt magic; it was boring engineering: guardrails, a reproducible pipeline, and an evaluation we could trust. That’s the job now.

TL;DR (what to learn next)

Data intuition beats model trivia: learn to clean, slice, and disbelieve your data.
Reproducibility + observability: use env managers, pipelines, and experiment tracking.
Evaluation is a product feature: build small, task-specific tests before you scale.
Security isn’t optional: design for prompt injection and unsafe output handling.
Cost/latency trade-offs: know when a small model + smart caching beats a giant one.
Ship value, not demos: wire AI into a real workflow with clear rollback paths.

Map Your Skill Gaps (and why this is hard)

AI in 2025 feels like cloud in 2013—lots of hype, little discipline. The hard part isn’t calling a model; it’s owning the behavior once it’s in a real workflow. That means versioned code and data, consistent environments, measurable quality, and security posture that survives untrusted inputs. Without those, you get flashy prototypes that mysteriously degrade in production.

Use a Practical Mental Model

I teach teammates the “D-M-D loop”:

Data → collect, clean, label, monitor
Model → choose, configure, sometimes fine-tune
Delivery → wrap with APIs, cache, observe, secure

Wrap the loop with a thin ring: Governance (evaluation, cost, safety, rollback). If one segment wobbles, the loop eats your weekend.

Build Reproducible Scaffolding First

Environments that don’t lie. Use fast, consistent tooling so “works on my machine” stops being a plot twist. I like uv because it’s a single tool that handles Python installs, virtual envs, and a pip-compatible interface—fast enough that teammates actually use it.

# Setup (Linux/macOS). Assumes curl.
curl -LsSf https://astral.sh/uv/install.sh | sh
uv python install 3.12
uv venv --python 3.12
uv pip install "scikit-learn>=1.5" "mlflow>=2.9"

Pipelines you can trust. Even if you’re doing apps with .NET or Node, learn a minimal ML pipeline conceptually. In Python, sklearn.pipeline chains preprocessing + model so you tune and evaluate the whole thing, not just the final estimator. That prevents data leakage and keeps your runs comparable.

# Python 3.12
from sklearn.datasets import load_iris
from sklearn.pipeline import make_pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.linear_model import LogisticRegression
from sklearn.model_selection import cross_val_score
import mlflow, mlflow.sklearn

mlflow.set_tracking_uri("file:./mlruns")  # local runs
mlflow.set_experiment("skills-post")

X, y = load_iris(return_X_y=True)
pipe = make_pipeline(StandardScaler(), LogisticRegression(max_iter=1000))
with mlflow.start_run():
    scores = cross_val_score(pipe, X, y, cv=5)
    pipe.fit(X, y)
    mlflow.log_metric("cv_mean_acc", float(scores.mean()))
    mlflow.sklearn.log_model(pipe, "model")
    print(f"cv_mean_acc={scores.mean():.3f}")

MLflow gives you a simple UI to compare runs and artifacts—useful even for small experiments.

Stress-Test Your Data Intuition

Before you chase the “best” model, ask: If this prediction is wrong, what pattern in the data would mislead it? Create cheap tests: swap class labels, add outliers, perturb inputs, confirm your accuracy drops in sensible ways. Skepticism is a feature, not a vibe.

Try it now (10 minutes):

Set up the env above.
Swap StandardScaler() for no scaler; watch accuracy and variance jump.
Log both runs in MLflow and compare metrics/artifacts.

Learn Small-Model Engineering (then scale)

You don’t need a 70B model to automate a triage, summarize logs, or classify tickets. Hugging Face pipelines let you wire tasks quickly; later you can fine-tune with PEFT/LoRA to adapt cheaply.

from transformers import pipeline
sent = pipeline("sentiment-analysis")  # CPU works for a demo
print(sent("Deployments are failing again; reverting now."))

When you do need customization, PEFT/LoRA updates a tiny fraction of weights—often the difference between “can’t afford it” and “done by Friday.”

Bake In Evaluation Like a Product Requirement

A simple rubric beats vibes:

Task metrics: exact match, ROUGE/BLEU for text, confusion matrix for classifiers.
Behavioral tests: red-teaming prompts, tricky edge cases, “forbidden actions.”
Cost/latency budgets: max tokens/sec, p95 latency, and a rollback plan.

Remember: evaluation isn’t a one-time benchmark; it’s monitoring. Make dashboards part of “done.”

Guard Against Real-World Failure Modes

Two that bit us:

Prompt injection & unsafe output handling. Treat user text as hostile. Isolate tools, sanitize outputs, and audit prompts. The OWASP LLM Top 10 (2025) explains why these are #1 and #2 risks.
Over-trusting model text. If your system executes code or hits APIs based on model output, validate and constrain. Think schemas, allow-lists, or a secondary checker.

Google’s and AWS’s recent guidance both push layered defenses: input filters, output validation, and monitoring. Ship that before the flashy demo.

Make Smart Cost/Latency Trade-offs

Small model + cache > large model for many CRUD-ish tasks.
PEFT adapters let you specialize cheaply; store per-customer adapters when needed.
Batching & streaming reduce p95 tail pain; feature flags let you fall back fast.

Ask yourself: If the model gets slower by 200ms tomorrow, does the business still work?

A Quick Story Slice (the imperfect bit)

I almost merged a “smart” incident-closer that looked great in staged tests. A teammate asked, “What’s the failure mode when the log parser drops a field?” We added one synthetic example, and the model happily “explained” a non-existent root cause. That tiny “almost mistake” saved us the apology email later.

What to Learn Next (and how)

Reproducible tooling: Python 3.12 + uv for speed and fewer environment footguns.
Pipelines & evaluation: scikit-learn Pipeline concepts translate to any stack; MLflow for lightweight tracking.
Pragmatic LLM use: Hugging Face pipeline to ship; PEFT/LoRA when you need task accuracy without a GPU farm.
Security: Read OWASP’s LLM Top 10 and implement at least two mitigations this week.

If you’re coming from .NET, the trade-off mindset is the same one I wrote about in Why I Still Choose C# (Even After Trying Everything Else)—choose boring, durable tools, measure, then iterate.

CTA

If you try the mini-exercise, drop your cv_mean_acc in the comments and tell me what changed it most—scaler, solver, or random seed? Also, what’s the single check you’ll add to your AI app this week: input sanitizer, output schema, or an eval set? I’ll share back anonymized patterns and a follow-up snippet.

If You Know These 30 JavaScript One-Liners, You’re Fast

Sukhpinder Singh — Sun, 05 Oct 2025 13:37:59 +0000

A very specific night (and a very silly bug)

2:13 a.m. in a quiet apartment. My laptop fan sounded like a small helicopter and the last of my jasmine tea had turned into something medicinal. I was stubbornly wrestling with a cookie helper. Twelve lines, three branches, one off-by-one.

Teammate (on Slack): “Ship it?”
Me: “…are we sure?”

That’s when I opened my scrappy snippets.md and started replacing noisy helpers with sharp, honest one-liners. Not golfed code—clear code. Since then, these 20 lines have paid rent in production.

Here’s the list, plus where each one helped, and the trade-offs I learned the hard way.

1) Get a cookie value (stop overbuilding)

const cookie = name => `; ${document.cookie}`.split(`; ${name}=`).pop().split(';').shift();

Where it helped: Login flakiness on staging; I needed to peek at _ga quickly.
Watch out: Won’t see HttpOnly cookies (that’s a good thing). Path/domain matter.

2) RGB → Hex (design → CSS handshake)

const rgbToHex = (r, g, b) => "#" + ((1<<24)+(r<<16)+(g<<8)+b).toString(16).slice(1);

Story: Designer sent RGB, theme wanted hex. This bridged it during a UI polish sprint.
Guard: Validate 0–255. I’ve shipped rgbToHex(300, -2, 10) (facepalm).

3) Copy to clipboard (no hidden inputs)

const copyToClipboard = text => navigator.clipboard.writeText(text);

Fix: I ditched the execCommand relic.
Gotcha: Needs https and user gesture; attach to a click or keydown.

4) Day of year (for streaks and cohorts)

const dayOfYear = d => Math.floor((d - new Date(d.getFullYear(), 0, 0)) / 86400000);

Real use: A “learning streak” badge that computed day numbers.
TZ note: Normalize to UTC if the boundary matters.

5) Capitalize (because JS still won’t)

const capitalize = s => s.charAt(0).toUpperCase() + s.slice(1);

True story: I once typed Substring (C# muscle memory) in a JS file. Linter laughed at me.

6) Days between (no Moment, no drama)

const dayDif = (a, b) => Math.ceil(Math.abs(a - b) / 86400000);

Use: “Remind me in N days” cards.
Caveat: Payroll/leave apps should use a real date lib—DST is a gremlin.

7) Clear all cookies (panic button)

document.cookie.split(';').forEach(c => document.cookie = c.replace(/^ +/,'')
  .replace(/=.*/, `=;expires=${new Date(0).toUTCString()};path=/`));

When: Before a demo when auth state got weird.
Note: Cookies set on a different path/domain may survive.

8) Random hex (rapid prototyping)

const randomHex = () => `#${Math.floor(Math.random()*0xffffff).toString(16).padEnd(6,'0')}`;

Fun: Temporary avatar colors in a “team picker.”
Accessibility: Not contrast-safe by default—never ship this to prod UIs without checks.

9) Unique array (goodbye 15-line loop)

const removeDuplicates = arr => [...new Set(arr)];

Gotcha: Works on primitives. For objects, dedupe by key:

const uniqBy = (arr, key) => [...new Map(arr.map(x => [x[key], x])).values()];

10) Query params (quick & dirty)

const getParameters = url =>
  JSON.parse('{"' + decodeURI(url.split("?")[1]).replace(/"/g,'\\"')
  .replace(/&/g,'","').replace(/=/g,'":"') + '"}');

Confession: I used this mid-debug to unblock myself.
Long-term: Prefer new URL(url).searchParams.get('q')—clearer, safer.

11) Time from Date (hh:mm:ss)

const timeFromDate = d => d.toTimeString().slice(0, 8);

When: Console output for job runtimes.
Internationalization: For UI, use Intl.DateTimeFormat.

12) Even check (small reads better)

const isEven = n => n % 2 === 0;

Aside: I used to write !(n & 1) to feel clever. Then I started writing for humans.

13) Average (tiny analytics helper)

const average = (...xs) => xs.reduce((a,b)=>a+b,0) / xs.length;

Guard: Empty input → NaN. I now wrap with xs.length ? … : 0.

14) Scroll to top (be kind: smooth)

const goToTop = () => window.scrollTo({ top: 0, left: 0, behavior: 'smooth' });

Respect: Users with reduced motion—feature-detect or let CSS media queries handle it.

15) Reverse string (classic chain)

const reverse = s => s.split('').reverse().join('');

Unicode footnote: Grapheme clusters (emoji/accents) need a lib or Intl.Segmenter.

16) Array not empty (guard clause)

const isNotEmpty = a => Array.isArray(a) && a.length > 0;

Why I keep it: Reads like English and kills a whole if-ladder.

17) Selected text (handy in editors)

const getSelectedText = () => window.getSelection().toString();

Shadow DOM: You may need selection from the right root; know your host.

18) Shuffle (fun, but biased)

const shuffleArray = a => a.sort(() => 0.5 - Math.random());

Honesty: Great for a quick demo. For fairness, I use Fisher–Yates:

const fyShuffle = a => { for (let i=a.length-1;i>0;i--){ const j=Math.floor(Math.random()*(i+1)); [a[i],a[j]]=[a[j],a[i]];} return a; };

19) Detect dark mode (respect the user)

const isDarkMode = window.matchMedia && window.matchMedia('(prefers-color-scheme: dark)').matches;

Pattern: Toggle a data-theme attribute and let CSS carry the weight.

20) Debounce (collapse rapid calls)

const debounce = (fn, ms) => { let t; return (...a) => { clearTimeout(t); t = setTimeout(() => fn(...a), ms); }; };

Use: search-as-you-type, resize handlers.
Note: Last call wins.

21) Throttle (limit call rate)

const throttle = (fn, ms) => { let p = 0; return (...a) => { const n = Date.now(); if (n - p > ms) { p = n; fn(...a); } }; };

Use: scroll listeners, pointer move.
Note: Drops calls within the window.

22) Clamp (keep a number in range)

const clamp = (n, min, max) => Math.min(max, Math.max(min, n));

Use: slider values, pagination bounds.

23) Chunk an array

const chunk = (arr, size) => arr.reduce((r, _, i) => (i % size ? r[r.length-1].push(arr[i]) : r.push([arr[i]]), r), []);

Use: grid rows, batched requests.

24) Deep-flatten any nested array

const flat = arr => arr.flat(Infinity);

Use: merging API results.
Note: Requires modern runtimes (widely supported).

25) Range generator (length n, optional start)

const range = (n, start = 0) => Array.from({ length: n }, (_, i) => i + start);

Use: page numbers, skeleton loaders.

26) Sleep / delay as a Promise

const sleep = ms => new Promise(r => setTimeout(r, ms));

Use: UI pauses, backoff between retries.

27) Fetch JSON (tiny helper)

const getJSON = (url, opts) => fetch(url, opts).then(r => r.json());

Use: quick prototypes.
Note: No error handling—wrap if you need robustness.

28) Group by key

const groupBy = (arr, key) => arr.reduce((m, x) => ((m[x[key]] = m[x[key]] || []).push(x), m), {});

Use: table sections, charts datasets.

29) Safe deep get with default

const get = (obj, path, dflt) => path.split('.').reduce((v, k) => v?.[k], obj) ?? dflt;

Use: reading optional API fields without try/catch.

30) The mindset: compress only when it clarifies

There’s a difference between clever and considerate. I used to minify everything I could; now I compress only when the next reader—maybe tired, maybe rushing—will understand it faster.

Quotable: “Great code isn’t shorter. It’s clearer—and usually that means fewer moving parts.”

Tiny sketch: how the “quick params” trick works

[ URL ] -> [ split "?" ] -> [ decode ] -> [ replace &/= ] -> [ JSON.parse ] -> { params }

Alt text: A simple linear flow showing a raw URL string transformed into a params object via split/replace/parse.

Three real postmortems (because production is humbling)

#1532 Clipboard flaked in staging

Symptom: Worked locally, failed behind reverse proxy.
Root cause: Missing secure context; no user gesture.
Fix: Wire to a click; ensure https in all envs.
Commit: 9ad1bf7 (the “toast added” one).

#1619 Streak counter off by one

Symptom: Users in GMT+9 saw tomorrow’s day number.
Fix: Normalize to UTC midnight; compute in back end.
Lesson: Time zones don’t care about your sprint goals.

#1674 Duplicate labels in chart

Symptom: Two bars with the same tag after a transform.
Fix: labels = [...new Set(labels)] pre-render.
Bonus: Added uniqBy for objects (see #9).

Skimmable checklists (paste into your notes)

Reach for a one-liner when…

The name reads like a sentence (isNotEmpty, timeFromDate).
It replaces boilerplate without hiding intent.
You’ve tested edge cases (TZ, permissions, Unicode).

Don’t one-line when…

Security or crypto logic lives there.
Accessibility depends on it (contrast, motion).
You need mathematically fair randomness (use Fisher–Yates).

How I keep these ready (small habit, big payoff)

I keep a snippets.md in the repo with headings and trade-offs.
I save tiny gists for the ones I reuse across projects.
I leave a one-line comment above each snippet: what it does + when not to use it.
I prune. If a snippet causes more questions than answers, it’s gone.

Recap (7 takeaways)

One-liners are tools, not trophies.
Prefer clarity > cleverness.
Normalize time. Respect motion preferences. Guard inputs.
Set, Map, URL, Intl—lean on the platform first.
Prototype fast, then refactor the “quick & dirty.”
Document trade-offs right above the snippet.
Share your snippet file—teams improve it together.

Let’s make this a living toolbox

What’s the one-liner you reach for without thinking?
Drop it in the comments—I’ll collect the best ones and credit you in a follow-up.

Follow if you like practical, production-tested posts with fewer buzzwords and more “here’s what actually shipped.”

Why I Still Choose C# (Even After Trying Everything Else)

Sukhpinder Singh — Fri, 03 Oct 2025 01:06:01 +0000

The one language that keeps pulling me back, no matter what else I try

The Hook: My Accidental Love Story with C

I didn’t start my career thinking, “Yep, I’m gonna be a C# developer.” Not even close.

I was that guy who bounced between languages like a kid testing every arcade machine. Java one week, Python the next, then back to some shaky PHP “hello world” website. Each one felt exciting for about… two weeks.

And then reality hit.

Java was powerful but made me feel like I was filling out mortgage forms just to print text on a screen.
Python was fun, until my project grew up and turned into spaghetti.
JavaScript? Let’s just say undefined still haunts my dreams.

C# wasn’t even on my radar. I literally stumbled into it by accident while trying to build a small Windows app for a college project. I opened Visual Studio, wrote a few lines, and for the first time coding didn’t feel like punishment.

That was it. Not love at first sight, but it felt… different. And years later, after testing Go, Rust, Kotlin, and a few other “shiny” languages? Guess what’s still on my machine, still running most of my real work? Yep. C#.

Why C# Keeps Winning Me Over

1. It’s Balanced (Strict, but Not Annoying)

C# is like that friend who shows up on time but still grabs tacos with you at midnight. Structured, but not uptight.

Strong typing saves me from weird runtime bugs.
Syntax that’s clean but doesn’t make me cry.
Features that arrive right when I need them (LINQ, async/await, pattern matching).

I’ve written in languages that were too stiff (hi Java 👋) and too loose (looking at you, JavaScript). C# just feels… right. Like the “Goldilocks zone” of programming.

👉 “C# is strict enough to keep me safe, chill enough to let me code at 2 a.m. without losing my mind.”

2. The Ecosystem Is Ridiculously Good

Whatever I throw at it—C# has an answer.

Web APIs? ASP.NET Core.
Desktop apps? WinForms, WPF, or MAUI if I’m feeling fancy.
Cloud-native microservices? Minimal APIs + Docker.
AI/ML? ML.NET, or just hook into Python.
Games? Unity. Enough said.

It’s like a Swiss Army knife for devs.

Messy Node.js Example (more setup than I like):

const express = require('express');
const app = express();

app.get('/hello', (req, res) => res.send("Hello World"));
app.listen(3000);

Minimal C# Example (.NET 8):

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.MapGet("/hello", () => "Hello World");

app.Run();

Less code. Strong typing. Doesn’t break when I blink at it wrong.

3. It Keeps Growing Up With Me

This is maybe my favorite part: C# evolves, but it doesn’t abandon me.

Async/await killed callback hell.
LINQ turned ugly loops into something that looks like poetry.
.NET 8+? We’re talking native AOT, faster-than-Java performance, cloud-first everything.

Friends keep asking: “Why not Go? Why not Rust?” And honestly? Because C# keeps giving me the “new shiny” without making me throw away everything I already know.

4. The Community (a.k.a. My 2 a.m. Lifeline)

If you’ve ever coded in a language with a tiny community, you know the pain—Googling an error and finding… nothing.

With C#, I’ve never felt that. Ever.

Docs? Surprisingly readable.
StackOverflow? Someone’s already had my exact 2 a.m. bug.
GitHub repos? New tools and fixes all the time.

It’s like coding with a safety net. You’re never really alone.

👉 “A good language makes you productive. A good community keeps you sane.”

5. Career Insurance (a.k.a. Job Security)

Let’s be honest: passion’s cool, but rent is real.

C#/.NET devs are still in demand—enterprise apps, startups, cloud systems, even gaming. It’s one of those rare skills that’s both future-proof and relevant today.

I like tinkering with other languages on weekends, but Monday morning? My paycheck comes from C#. And I’m not mad about that.

👉 “C# isn’t just a language on my resume. It’s peace of mind.”

My “Which Language Do I Use?” Flow (Spoiler: C# Wins)

Here’s literally how my brain works when I start a new project:

               ┌─────────────┐
               │ New Project │
               └──────┬──────┘
                      │
          ┌───────────▼───────────┐
          │ Do I need speed?      │
          └───────────┬───────────┘
                      │
        Yes ─────────►C#/.NET
                      │
        No ──────────►Maybe Python/JS

And yep—9 times out of 10, it lands on C#. The 10th time? I usually regret it and come back.

Mistakes I Made Along the Way

I wasted months chasing shiny new languages instead of getting better at one solid one.
I wrote garbage C# at first and thought “the language will save me.” Spoiler: it won’t.
I confused “shorter code” with “better code.” Big difference.

Ouch. But hey, lessons learned.

Quick Takeaways

C# = balance. Strict but flexible.
Ecosystem covers everything. APIs, games, desktop, cloud.
Keeps evolving. New features, no abandonment.
Community rocks. Docs + forums + GitHub = life saver.
Career safe. Demand isn’t going anywhere.

Wrapping Up

Here’s the weird truth: I didn’t pick C# once. I’ve picked it dozens of times. Every new project, every “let’s compare tools,” every “what should I use for this?” moment. And every single time, I end up back here.

Other languages feel like flings.
C# feels like home.

So let me ask you—
👉 What language feels like home for you?
👉 And if it’s not C#, what’s stopping you from giving it a real shot?

DEV Community: Sukhpinder Singh

7 C# Techniques Pros Use Without Thinking

1. Pattern Matching So Hard I Forgot How to Write If-Else

2. Records + with Expressions = My Daily Immutability Fix

3. Span & Memory (My Brain Auto-Reaches for Them)

4. Primary Constructors + required Members (Classes Feel Naked Without Them)

5. IAsyncEnumerable Streaming — Because Loading Everything Is So 2022

6. Local Functions + Expression-Bodied Members Everywhere

7. Source Generators & Smart Attributes (Boilerplate? Never Heard of Her)

🤠 AI Whipper String — Whip Your AI Into Shape

What I Built

Demo

Code

ssukhpinder / ai-whipper-string

whip AI into shape

🤠 AI Whipper String

Whip AI Here: https://ssukhpinder.github.io/ai-whipper-string/

Features

Install + Run

How to Whip

Physics

How I Built It

.NET Programming Habits I Wish I’d Started Sooner

1. I stopped writing “smart” code and started writing obvious code

2. I started being aggressive about naming things

3. I learned to keep controllers thin and business logic out of the edges

4. I stopped treating null as a personality trait

5. I started designing methods around behavior, not just data movement

6. I got serious about logging things I’d actually need during a bad day

7. I stopped pretending tests were just for correctness

8. I started respecting async all the way through

9. I learned to optimize later, but measure sooner

10. I stopped over-abstracting code “for the future”

11. I started treating code reviews like design reviews, not typo hunts

12. I finally accepted that consistency beats personal genius

What changed after I built these habits?

Practical takeaways you can use this week

Final thought

Stop Guessing Your Exceptions

Name the Real Issue

Use This Two-Step Test

Applying Guard Clauses (C# 12 / .NET 8+)

Try It Out

Avoid Simple Mistakes

Why stubborn bugs waste days

1: Freeze the Environment and Record the Scene

2: Create a Minimal Reproduction

3: Use Specific Logging and Counters

4: Use git bisect to Find the Problematic Commit

5: Write a Test That Fails Before Fixing

Level Up Your PRs: 20 Reviewer-Friendly C# One-Liners

1) Guard required input (save future you)

2) Null-safe with a sensible default

3) Dispose without ceremony

4) Switch expression for intent

5) Dictionary get-or-add (cache happy)

6) Count occurrences (no ifs)

7) Distinct by key (built-in)

8) Group + count to dictionary

9) Top-N fast

10) Stream huge logs safely

11) Serialize quickly (built-in)

12) Deserialize (defensive)

13) Parse with fallback

14) Tail of a string (ranges)

15) Create parent folder idempotently

16) Modern param guard

17) Trim without NRE

18) Flatten batches

19) Fire many tasks together

20) Add timeouts (no custom CTS)

Closing thought

[Boost]

Hiring Part-Time Editors for .Net Programming (Medium)

Sukhpinder Singh ・ Oct 6

Hiring Part-Time Editors for .Net Programming (Medium)

Your 2025 AI Upgrade, Minus the Noise

TL;DR (what to learn next)

Map Your Skill Gaps (and why this is hard)

Use a Practical Mental Model

2. Records + `with` Expressions = My Daily Immutability Fix

4. Primary Constructors + `required` Members (Classes Feel Naked Without Them)

4: Use `git bisect` to Find the Problematic Commit