About CSharpMind

CSharpMind is a technical publication about C#, .NET, and the runtime underneath both. Every article starts from the same question:

What is the system actually doing beneath the abstraction?

Why this publication exists

A language feature, a base-class-library type and a framework middleware all present a simple surface. That surface holds right up to the moment behaviour stops matching the mental model — a request that allocates far more than the code appears to allocate, a thread pool that will not grow fast enough to clear its queue, a container that gets OOM-killed at a heap size the process never asked for. At that point the documentation runs out, because a framework’s documentation describes its API and not the runtime underneath it. This site is written for the gap between those two things.

The aim is narrow and deliberate: explain the mechanism, in enough detail that a reader can go and observe it on their own machine. That means naming the runtime knob, naming the CoreCLR or System.Private.CoreLib type, stating the SDK the behaviour was seen on, and describing a measurement precisely enough to repeat. It also means being willing to end on “it depends” when the honest answer depends on the workload, and then saying what it depends on and how to measure it. The readership assumed throughout is working .NET developers with a few years behind them — people who already ship C# and have hit the point where the surface stopped explaining what they were seeing.

Advice ages with the runtime; mechanisms age far more slowly. A tuning recommendation written for .NET Framework 4.5 is mostly archaeology now, while an explanation of how the compiler lowers an async method into a state machine still holds across every release that has shipped since. Preferring the second over the first is the long-term bet this publication makes, and it is why articles are written to be re-readable against a newer release rather than to be correct for one afternoon.

Who writes it

Callum Reeve writes every article here. His work covers the language and its lowering — what the C# compiler emits for iterators, async methods, pattern matches and ref struct code, and the distance between the source and the IL; the runtime — tiered compilation, the JIT’s inlining and devirtualisation decisions, and what actually reaches the CPU; memory and garbage collection — allocation profiles, generation promotion, the difference Server and Workstation GC make to a latency distribution, and what pause-time numbers do and do not tell you; frameworks such as ASP.NET Core and EF Core, measured at the runtime level rather than described at the API level; and diagnostics — dumps, counters and traces, read directly rather than pattern-matched against folklore.

The method behind that range matters more than the range itself. Claims are settled against runtime source, a documented configuration knob, or an experiment that states its SDK build and its hardware — and where a result is a property of one specific build, the article says so rather than generalising. Benchmarks are BenchmarkDotNet, because a hand-rolled Stopwatch loop measures tiered compilation warming up rather than the thing under test. Sample output is real output. Where the evidence is thin or the sources disagree, nothing is published until it is not.

Callum Reeve · CSharpMind

What gets published, and what does not

Articles fall into five subjects — language, runtime, concurrency, frameworks and diagnostics — and a topic that fits none of them is out of scope rather than a sixth subject. Within them, the shape is consistent: the finding goes first, the mechanism comes before the advice, and the recommendation is the consequence of the explanation rather than a substitute for it. Length follows the subject, typically eight hundred to twelve hundred words. Nothing is padded to reach a count, and nothing is split into a series to produce more pages; a series exists when several articles genuinely share one idea.

What does not get published is a shorter list, and a firmer one. No framework tutorials, no “top ten” anything, and no takes on which ORM is correct — those are covered adequately elsewhere. No framework advocacy, and no comparison written in order to have a winner. There are no sponsored articles, no affiliate links and no paid placements; nothing appears here in exchange for a link, and guest submissions are not accepted. That last point is not a moral position — it is what keeps an article’s recommendation readable as an actual recommendation.

Code samples are held to the same standard as the prose. They compile against a stated SDK release, they show the project setting or environment variable they need next to them, and they avoid the shortcuts that make a snippet look clean and behave differently from production code. Error handling is sometimes elided for clarity, which the terms of use already state. Technical writing ages, and some of it is wrong on the day it is published: corrections are made in place, a substantively changed article carries an updated date, and if something here is wrong, say so.

How an article is made

The material comes from production. Articles here start from systems that actually ran, misbehaved, and were diagnosed — which is what makes the numbers real, and also what makes a disclosed process necessary rather than optional. Every piece passes through the same three stages, in this order:

1. The author writes the draft. Callum Reeve picks the subject, reproduces the behaviour, and writes the draft around real production examples — the observed symptom, the diagnostic path, the measurement, and the mechanism it points at. All technical substance, every claim and every number, originates at this stage.
2. AI anonymises and copy-edits the draft. A language model strips the identifying detail out of the production examples — employer, client, service and hostname alike — so that a case study cannot be traced back to the system it came from. The same pass fixes spelling, grammar and awkward phrasing, and returns a draft that is ready to publish. It does not introduce claims, numbers or conclusions; its input is the author’s draft and its output is that draft made publishable.
3. The author reviews and signs off. Before anything goes live, Callum Reeve reads the edited draft against the original, corrects whatever the edit distorted, restores any technical nuance the smoothing flattened, and gives the piece its final form. Nothing publishes without that pass, and the byline means it happened.

The division of labour is the point: the findings, the measurements and the judgement are the author’s, the anonymisation and the copy-edit are mechanical, and the last word is the author’s again. An article that could not survive the third stage does not get a fourth one — it is held back or dropped rather than smoothed over.