DEV Community: Mark

Modeling the Expected Value of a Sealed Card Box (and Where the Number Quietly Lies)

Mark — Mon, 06 Jul 2026 03:18:19 +0000

A friend messaged me a photo of a sealed booster box last month with one question: "worth it?" He'd already decided, really. The chase card in that set was all over his feed, so the box felt like a good deal. I asked him to send me the pull rates instead of the hype, and we spent twenty minutes turning "worth it?" into something we could actually compute.

That exercise is a small, self-contained data problem. It's also a good example of how a clean-looking model can hand you a confident number that doesn't survive contact with reality. If you like building little estimators, this one is worth doing carefully, because the interesting part isn't the formula. It's everything the formula assumes.

The formula is the easy part

Expected value of a box is a weighted sum. Each card you can pull has a probability and a market value, and you multiply the two across every slot the box gives you. That's it. Undergrad probability.

Here's a stripped-down version for a hypothetical set. I'm using made-up numbers so nobody mistakes this for real pull data — the point is the shape of the computation, not the specific set.

# One "hit slot" in a box: probabilities cover the full outcome space.
# Values are illustrative market estimates in USD.
hit_table = [
    {"name": "Alt-art chase",  "p": 0.0125, "value": 180.00},
    {"name": "Secret rare",    "p": 0.030,  "value": 45.00},
    {"name": "Full-art rare",  "p": 0.100,  "value": 8.00},
    {"name": "Standard hit",   "p": 0.400,  "value": 0.55},
    {"name": "No notable hit", "p": 0.4575, "value": 0.06},
]

assert abs(sum(row["p"] for row in hit_table) - 1.0) < 1e-9

ev_per_slot = sum(row["p"] * row["value"] for row in hit_table)
hit_slots_per_box = 36        # e.g. one meaningful slot per pack
ev_box = ev_per_slot * hit_slots_per_box

print(f"EV per slot: ${ev_per_slot:.2f}")   # $4.65
print(f"EV per box:  ${ev_box:.2f}")        # $167.31

The box costs $150 sealed, the model says $167, so you're "up." My friend was thrilled for about four seconds, which is roughly how long that number deserves.

Where it starts lying

The math is correct. The inputs are where it falls apart, and they fall apart in ways that all push the same direction: optimism.

The distribution is heavy-tailed, so the mean is a bad summary. That $167 leans hard on the 1.25% alt-art chase, which alone contributes $2.25 of the $4.65 per-slot figure. Drop that single row and EV per box falls to about $86 — far below the sticker price. Almost half of the "expected" value lives in an outcome that lands in roughly one box out of eighty per slot. The typical buyer does much worse than the mean buyer, and the word "expected" hides that completely.

# Probability a whole box shows zero copies of the chase card
p_miss_chase = (1 - 0.0125) ** hit_slots_per_box
print(f"Chance of no chase in a box: {p_miss_chase:.1%}")   # 63.6%

Roughly two out of three boxes never see the card carrying most of the EV. A mean that ignores that is technically true and practically misleading.

The values decay while you're holding them. value isn't a constant, it's a snapshot. Singles prices for a freshly released set slide as supply floods in, and the chase you priced at $180 on release week is a different number a month later. A model built on today's prices silently assumes you can liquidate instantly at today's prices. You can't.

The probabilities are the shakiest input of all. Very few sets publish official per-slot pull rates. What circulates is a mix of manufacturer statements, community-aggregated opening logs, and outright guesses, and they rarely agree on the long tail — which, per the point above, is exactly the part that moves your answer most. Pinning down a defensible probability for that 1.25% row is harder than the entire rest of the calculation.

That last problem is the one I actually spend time on. When I need a starting distribution I'll pull from a set-odds reference like TCGOdds to see what pull-rate and set-composition data is available for a release, then treat those figures as a documented estimate to sanity-check against rather than as ground truth. It doesn't remove the uncertainty in the tail — nothing does — but it beats a screenshot of one person's box break, and it gives you a consistent baseline to plug into the model above instead of a number you felt was about right.

Turn the point estimate into a range

Because the inputs are uncertain, a single EV figure is the wrong output type. A quick Monte Carlo makes the spread visible, which is the honest version of the answer.

import random

def simulate_box(trials=200_000):
    outcomes = []
    for _ in range(trials):
        total = 0.0
        for _ in range(hit_slots_per_box):
            r = random.random()
            cum = 0.0
            for row in hit_table:
                cum += row["p"]
                if r <= cum:
                    total += row["value"]
                    break
        outcomes.append(total)
    outcomes.sort()
    return outcomes

box_values = simulate_box()
n = len(box_values)
pct = lambda q: box_values[int(q * n)]
print(f"mean ${sum(box_values)/n:.0f} | "
      f"p10 ${pct(0.10):.0f} | p50 ${pct(0.50):.0f} | p90 ${pct(0.90):.0f}")

Now the answer isn't "$167." It's a shape: the mean sits near $167, but the median box lands in the low $80s, a bottom tenth comes in under $50, and the top tenth clears $270 on the back of a chase pull. Against a $150 box, that reframes the decision entirely. You're not buying an expected $167. You're buying a wide distribution where the good outcomes are rare and the typical one is underwater before fees, shipping, and the price decay you haven't modeled yet.

What the model is actually for

None of this tells you whether to buy the box. Expected value isn't profit, and it was never meant to be a purchase recommendation. For something you buy partly for the fun of opening it, the entertainment is a real part of the return and it doesn't show up anywhere in these numbers. Pull rates and market values are estimates, and a model built on estimates gives you a planning aid, not a promise. Treat any figure it produces as "here's the shape of the outcomes," not "here's what you'll get."

The value of writing the estimator is that it makes your assumptions explicit. You can see, in code, that your optimism was concentrated in one 1.25% row and one stale price. That's a better position than "it felt worth it," even when the conclusion is identical.

My friend bought the box. He'd run the numbers, he knew the median outcome, and he wanted to open it anyway. Completely defensible. It's just a different decision than the one he was about to make twenty minutes earlier, and the difference was a dozen lines of Python and a distribution he could finally look at.

Forecasting from a Government PDF: What I Learned Modeling the Visa Bulletin

Mark — Sun, 05 Jul 2026 02:36:29 +0000

Every month the U.S. State Department publishes the Visa Bulletin. If you have never had to read one, picture a set of grids: rows for green-card categories like EB-2 and EB-3, columns for a handful of countries, and inside each cell either a date or the letter "C" for current. That date is the cutoff. If your priority date is earlier than the cutoff for your category and country, your case can move forward. If it isn't, you wait.

It looks like structured data. It mostly isn't. And the moment you try to turn a year of these bulletins into anything a person can plan around, you run straight into the reason immigration timing feels so unknowable: the source is a monthly snapshot that was never designed to be a time series.

I spent a while building tooling around exactly this problem, and the interesting engineering was almost never where I expected it.

The parsing is annoying before it is hard

The bulletins are published as web pages and PDFs whose layout drifts over the years. Column headers get reworded. A country gets its own column one year and gets folded into "All Chargeability Areas Except Those Listed" another. Dates appear as 08JAN20, sometimes 01JANUARY2020, sometimes just C, and occasionally U for unavailable, which is a different thing from a date being blank.

None of that is intellectually deep. It is the ordinary tax of pulling a dataset out of documents meant for human eyes. The trap is treating it as a one-time scrape. Because the format shifts, a parser that passed on last year's files can silently mangle this month's, and a silent mangle in a forecast is worse than a crash. So the real work is validation: range-check every parsed date, assert that categories that existed last month still exist, and flag any cell that moved in a direction the rules say is unusual, so a human can look before it feeds anything downstream.

Movement is not a smooth signal

Once you have a clean series of cutoff dates per category and country, the instinct is to fit a line and extrapolate. Resist it. The line does not move the way a naive model assumes.

A category can jump several months in a single bulletin and then sit frozen for the next two. It can go backward — retrogression — when demand outpaces the annual supply. And the whole system has a seasonal heartbeat: the government fiscal year resets in October, visa numbers refill, and the rhythm of movement early in a fiscal year often looks nothing like the rhythm in August or September when annual limits are running dry.

Here is a concrete version of the problem. Say a category advanced 47 days in the most recent bulletin. Extrapolated blindly, that pace implies a cutoff sweeping through more than a year of priority dates every twelve months. But if you look back three or four years, you might find the same category averaged closer to 18 days a month, with two separate stretches where it went backward. The single most recent number is the least reliable input you have, and it is exactly the one an anxious applicant fixates on.

Why a point estimate is the wrong output

This is the part that changed how I thought about the whole project. For a while I treated "predict the date this person becomes current" as the goal. That framing is quietly dishonest, because it hands back a single day with an implied precision the data cannot support.

A system with retrogression, seasonal resets, and demand that shifts by country is not something you forecast to the day. You forecast a distribution. The useful output is a window with a confidence range attached: given how this category has moved over the past several years, someone at this priority date has historically reached the front in somewhere between roughly this and that, and here is how wide the uncertainty is. A range that admits it might be wrong is more honest than a date that hides it.

There is a discipline that follows from this, and it is easy to skip. If you publish forecasts, you should check them against what actually happened and keep the score. When I later wrote about the finished product, the thing I most wanted to get right was that accountability loop, and it is why the immigration forecast hub I ended up building keeps its confidence ranges and its own historical accuracy visible together rather than printing a clean date and quietly moving on. A model you cannot grade is not a model. It is a guess with good production values.

The honest limits, stated plainly

I want to be direct about what this kind of tooling can and cannot do, because the domain punishes overpromising.

A forecast built from public data is a reading of patterns, not a decision from USCIS or the State Department. It cannot see inside anyone's case, it has no access to private government data, and it cannot guarantee an outcome. Immigration timing genuinely changes with agency policy, visa availability, and demand by country and category, and any of those can shift without warning. A category that advanced steadily for a year can stall. Treat any number the model produces as a planning aid with a wide margin, never a countdown clock.

And to be equally plain: none of this is legal advice, and it does not replace an immigration attorney. If a real decision hangs on timing — a job change, a lease, a filing choice — an estimate can inform the conversation, but the decision belongs with someone who knows the full case.

What actually transfers

The specifics here are immigration, but the shape of the problem is not. Anytime you build a forecast on top of a public dataset that was published for reading rather than analysis, the same three things decide whether the result is trustworthy: how carefully you validate a source that changes shape over time, whether you model the seasonality instead of extrapolating the last data point, and whether you output honest uncertainty instead of false precision.

The Visa Bulletin will keep arriving once a month, a grid of dates that looks more certain than it is. The engineering worth doing is not making it look even more certain. It is turning it into a range someone can plan around, and being willing to check, out loud, how often that range was right.

The Minecraft anvil is a tree-cost optimization problem in disguise

Mark — Thu, 02 Jul 2026 05:23:17 +0000

I fell down this rabbit hole because of a small, annoying moment in a survival game.

I had a diamond pickaxe I liked, four enchanted books I wanted on it, and an anvil. I combined them in whatever order felt natural — book, book, book, book — and somewhere around the third combine the anvil flashed "Too Expensive!" and refused to continue. Same items, same tool, and yet the order I'd picked had walked me straight into a wall.

If you've played Minecraft you've probably hit this. What I didn't expect was that untangling why it happens turns out to be a genuinely nice little computer-science exercise. The anvil isn't a flat price list. It's a cost function over a binary tree, and the "right answer" is a small optimization problem. This post is about that structure — and why it's the kind of thing worth building a tool around rather than solving in your head each time.

A caveat before I start: Minecraft is a trademark of Mojang/Microsoft, and I'm writing as a player, not on behalf of anyone. Exact anvil numbers also shift between game versions and editions, so treat the specific figures below as illustrative of the shape of the problem rather than a spec to memorize.

Two rules that quietly interact

Most of the anvil's behavior comes from two rules that are simple on their own and awkward together.

Rule 1: enchantments have a cost. When you merge an enchanted book into an item, each enchantment adds some number of levels to the operation, roughly scaled by how "expensive" that enchantment is. Fine. Predictable. You could tally it on paper.

Rule 2: there's a prior-work penalty. Every time an item passes through an anvil, it carries a growing tax on the next time it's used. In many versions that penalty roughly doubles with each use — think of it as 2^n - 1 extra levels, where n is how many times that item has already been anvil-ed. The first combine is cheap. The second is a bit more. By the fourth or fifth, the penalty alone can blow past the game's hard cap.

Rule 1 says "enchantments cost something." Rule 2 says "touching the item repeatedly costs something, independent of what you're adding." The trap is that the second rule punishes a strategy the first rule makes feel natural: dumping every book onto your main item one at a time.

Why order is the whole game

Here's the part that makes it interesting. Combining a set of books isn't a straight line — it's a tree. Each anvil operation takes two inputs and produces one output, and that output can be an input to a later operation. So four books plus one tool can be assembled in several different tree shapes:

Linear ("caterpillar"): tool + book, then + book, then + book, then + book. Your tool gets anvil-ed four times, so it accumulates the full stacked prior-work penalty. This is the shape that hits "Too Expensive!" first.
Balanced ("bracket"): combine book A + book B into one book, combine book C + book D into another, then merge those two results, then apply the result to the tool. No single item gets anvil-ed more than a couple of times, so the penalty never compounds as hard.

Same four books. Same final gear. Wildly different total level cost, purely because of the tree you chose. That's the tell that you're looking at an optimization problem and not an arithmetic one.

If it feels familiar, it should: minimizing the total cost of pairwise merges under a penalty for reuse is a cousin of classic optimal-merge and Huffman-style problems. You're deciding how to pair things up so the expensive operations sit near the leaves and the cheap accumulation stays balanced. It doesn't reduce to a single greedy rule, because the enchantment costs and the doubling penalty pull in different directions — sometimes the greedy "cheapest pair first" move sets up a worse penalty downstream.

Why I stopped doing this in my head

You can brute-force it. With a handful of books the number of distinct combine trees is small enough that a search over orderings is trivial for a computer. The problem is that it is exactly not trivial for a human standing at an anvil with limited XP, because:

The penalty is exponential, so mistakes are punished disproportionately — one bad early combine can make an otherwise-fine plan illegal.
The costs aren't all visible at once; you find out you've overspent only when the game blocks you.
XP is a real, non-refundable resource in survival. A wrong tree isn't just slower — it can strand a good item halfway to being finished.

That last point is why I'm careful to frame any calculator here as a planning aid, not a guarantee. It estimates a good combine order under a model of the rules; the actual game is the source of truth, and version differences are real. What a tool buys you is the search: it can enumerate the tree shapes and hand you an order that stays under the cap, so you spend your levels on the plan instead of on discovering the plan.

That's the modeling job behind a small fan-made site I've been poking at, a Minecraft anvil cost planner called MCAnvil, which takes the set of enchantments you want and works out a combine order rather than making you feel it out one expensive mistake at a time. It's independent and fan-made — the interesting part, for me, was less the UI and more that the "obvious" flat-cost model is wrong, and getting the tree cost and prior-work penalty right is what makes the output actually match what the game does.

The takeaway for builders

Two things stuck with me from this.

First, it's a clean reminder that a lot of game "mechanics" are really cost functions, and the moment a cost function has a reuse penalty and a branching structure, you've quietly crossed from look-up into search. Recognizing that boundary is most of the work — once you see the tree, the algorithm to explore it is the easy part.

Second, it's a good argument for encoding fiddly rules into a small tool instead of a wiki page. A table that says "enchantment X costs Y" is accurate and still won't stop you overspending, because the cost that hurts is emergent from order. The value of a calculator here isn't that the arithmetic is hard; it's that the interaction between two simple rules produces a result humans are bad at eyeballing.

If you play and you've ever eaten a "Too Expensive!" on a favorite item, it's worth planning the tree before you commit the levels. And if you don't play but you like modeling systems, the anvil is a surprisingly tidy example of an ordinary-looking mechanic that turns out to have a real optimization problem hiding underneath.

The hardest part of a pre-release game tracker isn't the UI, it's the provenance field

Mark — Wed, 01 Jul 2026 09:45:09 +0000

I started sketching a small reference page for a game that hasn't launched yet, and the first schema I wrote was embarrassingly naive.

{
  "character": "Example Unit",
  "element": "Ice",
  "role": "Support"
}

That looks fine until you ask a simple question: where did this come from?

For a game that's still in beta or pre-release, "where did this come from" is not a nitpick. It's the whole problem.

Why this is easy to underestimate

Most content models for a wiki-style tracker assume the data is settled. You pick a schema for a character or item, fill in the fields, done. That works for a game that already shipped, because the publisher's own patch notes are the ground truth.

Pre-release communities don't have that luxury. Information arrives in layers:

Official trailers and dev posts (solid, but sparse).
Datamined values pulled from client files (often accurate, sometimes from a build that never ships).
Community translation or paraphrase of the above (frequently where small errors creep in).
Pure speculation dressed up as a "leak" because it gets more clicks that way.

If your tracker stores all of that in the same flat table with the same visual weight, you've built a rumor amplifier, not a reference site. And once a wrong number gets copied from your page onto three other fan wikis, it's basically impossible to walk back.

A concrete case: the stat that wasn't final

A recurring pattern in creature-collector and gacha communities is a skill value or character kit that circulates from an early build, gets treated as fact, and then quietly changes before release. Nobody posts a correction thread with the same energy as the original "leak."

If a tracker's schema doesn't have a place to record "this came from a datamine of build X, not an official announcement," that context disappears the moment the entry gets copy-pasted somewhere else. The reader has no way to tell a confirmed detail from a snapshot of unfinished work.

So the fix isn't a UI problem. It's a data modeling problem:

{
  "entity": "Example Unit",
  "field": "role",
  "value": "Support",
  "status": "unconfirmed",
  "source_type": "datamine",
  "last_checked": "pre-release build"
}

Once status and source_type exist as first-class fields instead of afterthoughts, the rendering layer can do something useful with them: gray out unconfirmed rows, add a small label, sort official info above speculation instead of interleaving it.

Where this actually gets built

I've been using this as the underlying model for a small Honkai: Nexus Anima reference tracker, which exists mainly to organize public, official information about the game ahead of release. It's an independent fan project, not an official HoYoverse resource, and it isn't trying to be a leak aggregator or a prediction engine.

That narrow scope is intentional. The whole point is to give people a place to see what's actually been confirmed, separated from what's still floating around as speculation, without pretending the site has some special pipeline into unreleased information it doesn't have.

The limits are part of the design

A tracker like this is only as good as its restraint. It won't tell you what a character's kit will be before it's announced. It won't resolve a debate between two conflicting datamines. Pre-release game data changes, sometimes substantially, right up until launch, and any static page claiming otherwise is quietly lying to its readers.

Practically, that means:

Entries need a visible confirmed/unconfirmed distinction, not just a mental one the maintainer keeps in their head.
"Last updated" matters more than usual, since the ground truth itself is moving.
The maintenance cadence can be light early on and only needs to tighten up as the actual release window gets close.

The takeaway for anyone building something similar

If you're building any kind of tracker for something that hasn't shipped yet — a game, a product roadmap, a spec still in draft — the interesting engineering problem isn't the list view or the search box. It's whether your schema can honestly represent "I don't fully know this yet" instead of forcing every field into a false certainty.

That one field is the difference between a reference site and a rumor mill with better formatting.

The data model behind an employee cost calculator is messier than the UI

Mark — Tue, 30 Jun 2026 02:01:58 +0000

I thought the simplest part of an employee cost calculator would be the salary input.

In the UI, it looks harmless:

Salary: 85000
State: California

Then the calculator should explain what that employee roughly costs the employer.

The hard part is that the salary is not the model. It is just the starting value.

The actual model is a stack of assumptions:

employer payroll taxes
wage bases
state unemployment assumptions
workers' compensation assumptions
benefit assumptions
retirement or other optional contributions
pay period conversions
rounding and display rules

The lesson I took from building around this problem is that a calculator like this should not pretend to be more certain than it is.

It needs to be useful without acting like a payroll system.

The first product decision: show the assumptions

For a lot of finance tools, the temptation is to return one clean number.

Estimated employer cost: $X

That is tidy, but it is not very helpful if the user cannot see why the number moved.

For employer cost planning, the breakdown matters as much as the total. If the total changes because of an employer tax assumption, that is different from the total changing because someone added a benefits estimate.

So the better output shape is closer to:

{
  "salary": 85000,
  "payrollTaxes": "...",
  "stateUnemployment": "...",
  "benefits": "...",
  "insurance": "...",
  "estimatedTotalCost": "..."
}

The exact field names are less important than the principle: do not hide the cost stack.

When a small business owner, founder, or ops person is budgeting a role, they need to know which parts are assumptions and which parts are direct salary math.

State-specific logic changes the shape of the code

A naive version of the calculator can use one flat multiplier.

const estimatedCost = salary * 1.25;

That can be fine for a quick mental estimate, but it has a major flaw: it hides state-level differences.

Two employees with the same salary may not create the same employer-side cost profile if they are in different states. Wage bases, employer-side programs, and unemployment assumptions can differ. Some costs are capped. Some are not. Some are optional assumptions rather than fixed rules.

That pushed the implementation toward a more explicit model:

const estimate = calculateEmployerCost({
  salary,
  state,
  payFrequency,
  assumptions: {
    benefits,
    insurance,
    retirementMatch
  }
});

The interesting part is not the function call. It is the contract around it.

The calculator has to answer:

What is required input?
What is an optional assumption?
What is state-specific?
What should be itemized?
What should be labeled as an estimate?
What should not be claimed at all?

Those questions matter more than the UI polish.

Estimated does not mean sloppy

One mistake I try to avoid in planning tools is using "estimate" as an excuse for vague output.

An estimate can still be structured.

An estimate can still show its components.

An estimate can still make it clear that the user should not treat the result as payroll, tax, legal, or insurance advice.

That distinction is important. A tool like EmployerCosts is useful as a planning calculator because it makes the hidden employer cost stack visible. It should not pretend to replace a payroll provider, accountant, benefits broker, or employment advisor.

For me, that means the product language has to be part of the implementation:

"estimated" instead of "guaranteed"
"planning" instead of "compliance"
"assumptions" instead of "facts" when a value depends on the employer
itemized output instead of a single unexplained number

This is not just legal caution. It is better UX.

Users trust a calculator more when it is honest about what it knows.

The edge case that keeps showing up

The recurring edge case is not a strange salary number.

It is a reasonable user expectation:

"I know the salary. Why can't the calculator tell me the exact cost?"

Because the salary is only one input.

A real employer cost can depend on payroll setup, state rules, local rules, benefits, insurance classifications, workers' compensation details, company history, and other settings that a lightweight web calculator may not know.

So the tool has to balance two jobs:

Make the first estimate fast enough to be useful.
Avoid implying a level of precision it does not have.

That balance affects copy, field labels, component names, disclaimers, and result layout.

The useful abstraction

The abstraction that helped me think about the product is:

salary + employer-side burden assumptions = planning estimate

Not:

salary = employee cost

And not:

calculator result = payroll truth

That sounds obvious, but it changes the product.

It pushes the tool toward transparency. It makes the result page more educational. It prevents the calculator from turning into a black box with a dollar sign at the end.

The more I work on small planning calculators, the more I think the hard part is rarely the arithmetic alone.

The hard part is deciding what the calculator should be honest about.

The Unicode trap I had to design around in a LinkedIn formatter

Mark — Mon, 29 Jun 2026 04:14:47 +0000

I built a small tool for formatting LinkedIn posts, and the deceptively simple part was also the most important part:

styled text is not formatting. It is Unicode substitution.

That sounds obvious once you say it out loud, but it changes the product decision.

When someone clicks bold in a normal editor, the text usually remains the same text with a style applied around it. When someone uses a LinkedIn-style formatter, the tool often converts normal characters into mathematical Unicode characters that only look bold or italic.

For example, a plain A may become a styled Unicode character that visually resembles a bold A.

That works because LinkedIn accepts Unicode text in posts. It is also why these formatters are useful. You can create text that appears bold, italic, monospace, or decorative, then paste it into a post without needing LinkedIn to support rich text.

But it comes with tradeoffs.

The tempting bad version

The easy version of a formatter is just a character map:

A -> 𝐀
B -> 𝐁
C -> 𝐂

Then you loop through the input string and swap each supported character.

That gets you a working demo quickly. It also creates a product that quietly encourages people to overuse styled text everywhere.

The first version of the product question was:

How many styles can this tool support?

The better question became:

How do we help people use styles without making the final post worse?

That is a different problem.

Unicode styled text is less harmless than it looks

Styled Unicode can be useful in small doses. It can make a heading easier to spot or make a short list easier to scan.

It can also create issues:

Screen readers may read styled characters poorly or inconsistently.
Some search and parsing systems may not treat styled characters like normal text.
Copying styled text into resumes, applications, or ATS-sensitive fields can be a bad idea.
Over-styled posts can look noisy and less professional.

That meant the formatter needed to avoid pretending this was normal rich-text formatting.

The product copy had to be honest: use styled text sparingly.

The UI choice: make restraint the default

For LinkedIn Formatter, I wanted the tool to stay quick:

Paste plain text.
Choose a style.
Preview the result.
Copy it back into LinkedIn.

But the UI also needed to avoid making every decorative option feel equally recommended.

So the strongest product pattern was not a giant wall of fonts. It was a workflow that makes common professional formatting easy:

bold for short emphasis
italic for light contrast
bullets and line breaks for readability
preview before copy
no-login usage for quick one-off edits

Decorative styles can exist, but they should not be the main recommendation for a professional post.

The accessibility note is part of the product

One of the best improvements was simply adding caveats directly into the content and product positioning.

Not as a legal footnote. As product guidance.

If a tool changes text into Unicode lookalikes, users should understand when that is fine and when it is risky.

That is especially true for:

profile names
resumes
job applications
heavily formatted posts
content where screen reader clarity matters

The formatter is still useful. The honest framing makes it more useful, not less.

What I would build differently next time

If I were starting the tool from scratch again, I would treat the Unicode caveat as a first-class feature from day one.

I would also test each style against three questions:

Does this style help a real post become easier to scan?
Does it create avoidable accessibility or parsing problems?
Is the UI encouraging people to use it in the right amount?

That third question matters more than it first appears.

Small tools shape user behavior. If a formatter makes loud styles feel like the main event, people will use loud styles. If it makes clean structure feel like the main event, people are more likely to create readable posts.

The lesson

The technical implementation was character mapping.

The product work was deciding what not to encourage.

That is the part I underestimated.

A LinkedIn formatter is not just a Unicode conversion tool. It is also a tiny writing interface, and tiny writing interfaces still need product judgment.

A roof calculator that multiplies length by width is lying to you

Mark — Thu, 18 Jun 2026 01:58:53 +0000

I started building a roof area calculator thinking it would be a weekend thing. You take the length, you take the width, you multiply, you show a number. Roofs are rectangles. How hard can it be.

It is not a rectangle. That was the whole project, really — slowly understanding all the ways "length times width" is wrong, and that the wrongness compounds the moment someone tries to actually buy materials with your number.

The roof you measure isn't the roof you walk on

Here's the thing that took me embarrassingly long to internalize. The footprint of a house — the shadow it casts at noon — is flat. But the roof is tilted. The shingles cover the slanted surface, not the shadow. So the area you care about is always bigger than the footprint, and how much bigger depends entirely on the slope.

Roofers express slope as "rise over run" — a 6:12 roof goes up 6 inches for every 12 inches it goes sideways. To get from footprint to actual surface area you multiply by what's called the pitch factor, which is just the hypotenuse of that little triangle divided by the run:

// rise per 12" of run -> area multiplier
const pitchFactor = Math.sqrt(144 + pitchX * pitchX) / 12;

For a 6:12 roof that's sqrt(144 + 36) / 12 ≈ 1.118. So a house with a 1,500 sq ft footprint actually has about 1,677 sq ft of roof. That's 177 square feet you'd have just... not ordered. Almost two full squares of shingles (a "square" is 100 sq ft — roofing has its own units for everything). On a steeper 12:12 roof the factor is 1.414 and you'd be short by 40%.

The naive calculator doesn't return a slightly-off answer. It returns an answer that gets someone to the supply yard one delivery short, on a Saturday, with the old roof already torn off and rain in the forecast. The error has a cost and the cost lands on a specific bad afternoon.

So the geometry is the easy part once you see it. I put all the conversions in one place so a pitch could never mean two different things in two different spots:

export function calculatePitch(riseInches: number, runInches: number) {
  const slope = riseInches / runInches;
  const angleDeg = Math.atan(slope) * (180 / Math.PI);
  const pitchPer12 = slope * 12;
  const rafterPer12 = Math.sqrt(144 + pitchPer12 * pitchPer12);
  return {
    angleDegrees: angleDeg,         // 6:12 -> 26.57°
    pitchFactor: rafterPer12 / 12,  // 6:12 -> 1.118
    // ...
  };
}

I figured that was the project. It was not the project.

Area is necessary and completely insufficient

The moment I had a correct area number, I tried to answer the question people actually have, which is "okay, what do I buy." And area gets you exactly one line of the shopping list: the field shingles.

Everything else on a roof is sold by the edge, not the surface. Walk a roof in your head:

Drip edge runs along the eaves and rakes — the bottom and the slanted sides.
Starter strip runs along those same perimeters.
Ridge cap runs along the ridges and hips — the top lines and the diagonal corners.
Ice & water shield runs in a band along the eaves and up the valleys.

None of those scale with area. A long skinny ranch house and a compact two-story can have identical square footage and wildly different amounts of edge. So a "roofing calculator" that only knows area literally cannot tell you how many boxes of drip edge to buy. It's not that it's imprecise. It's missing the input.

Which means to do the real job, you can't ask for area at all. You have to ask for the shape and derive both the area and every edge length from it. So the calculator that started as one multiplication became a little parametric model of a roof:

export function calculateRoofShape(
  shape: "gable" | "hip" | "shed",
  length: number,
  width: number,
  pitchX: number
) {
  const pf = Math.sqrt(144 + pitchX * pitchX) / 12;
  const roofArea = length * width * pf;

  if (shape === "gable") {
    return {
      roofArea,
      edges: {
        eaves: 2 * length,
        rakes: 2 * width * pf,   // rakes follow the slope, so they get the factor too
        ridges: length,
        hips: 0,
        valleys: 0,
      },
    };
  }
  // hip and shed each have their own edge geometry...
}

The detail I love in that snippet, and the one I got wrong the first time: the rakes get the pitch factor and the eaves don't. The eave runs horizontally along the bottom — it's a true plan-view length. The rake climbs the slope from eave to ridge, so its real length is the plan length stretched by the same pf. Two edges of the same triangle, one scaled and one not. Get that backwards and your drip-edge count is fine but your starter-strip count drifts, and nobody notices until they're 8 feet short on the last run.

Once the shape gives you every edge, the bill of materials falls out of dividing lengths by coverage rates:

const capBundles     = Math.ceil((ridges + hips) / 25);   // ~25 lf per bundle
const starterBundles = Math.ceil((eaves + rakes) / 100);  // ~100 lf per bundle
const dripEdgePieces = Math.ceil((eaves + rakes) / 10);   // 10 ft pieces

Math.ceil everywhere, because you can't buy 0.3 of a bundle, and rounding down is the same Saturday problem in a smaller font.

The boring decision that mattered most

There's a calculator page, and there are written guides with worked examples ("a 1,500 sq ft 6:12 roof needs..."), and there are little reference tables. Early on, the worked examples were prose. I'd typed the numbers by hand. And of course one of them disagreed with what the calculator produced for the same inputs, because I'd updated a coverage assumption in the code and not in the paragraph I'd written three weeks earlier.

That's the failure mode that actually erodes trust in a tool like this. Not being wrong — being inconsistently wrong, where the calculator says one thing and the explanation under it says another, and now the reader has no idea which to believe. For a tool whose entire pitch is "trust this number," two numbers is worse than a wrong one.

So the rule became: there is exactly one file that knows how to do roofing math, and every surface — the calculator, the worked examples, the reference tables — imports from it. If a constant changes, it changes in one place and everything downstream moves together. The published assumptions (bundle coverage, waste factor, nails per square) live next to the functions that use them, so the "how we calculate this" page can't drift from the calculation either. It's not clever. It's just refusing to keep the same fact in two places.

The takeaway, if there is one

The lesson I keep relearning on these little domain tools: the naive model isn't a simpler version of the real thing, it's a different thing that happens to return a number in the same units. "Length times width" and "the actual surface area of a tilted plane with this much edge perimeter" aren't 80% the same answer. They diverge exactly where it costs the user money.

The interesting work was never the trigonometry. It was noticing that the question "how big is my roof" is secretly the question "what do I buy," and that the second one needs you to model the shape, not just scale a rectangle.

I put the whole thing online as a set of free calculators — pitch, area, the full material takeoff — at roofing-calculator.io if you want to poke at it, and there's a methodology page that lays out every assumption so you can argue with the numbers. If you've built tools in a domain where the obvious formula turns out to be quietly lying, I'd genuinely like to hear what tipped you off.

The worked example that disagreed with its own calculator

Mark — Wed, 17 Jun 2026 01:17:24 +0000

I run a small site of home-improvement cost calculators (costto.build) — pick a project, get a low / average / high estimate with a materials-and-labor breakdown. Boring on the surface. The interesting part is that every page has the same number in four different places, and for a while, those four places didn't agree.

This is a post about that bug, why it was inevitable, and the one rule that made it impossible to repeat.

Four sources of truth for one number

A single calculator page — say, the room-addition one — shows a cost in four spots:

The interactive widget, driven by a calculate() function (low/avg/high).
A static "cost by size" reference table above the fold.
A couple of worked examples written out in prose ("a 20×20 in-law suite runs about…").
The FAQ, with its own cost bands.

When I built the first batch, I wrote all four by hand. The widget had its formula. The table had numbers I'd typed from research. The prose examples had numbers I'd reasoned out while writing the paragraph. They were close enough that nothing looked wrong.

Then I ran a consistency pass and found this: the in-law-suite worked example said $62,300. The widget, fed the exact same square footage and finish level, returned $56,779.

Same project. Two pages of the same page. A $5,500 gap.

Why it happened (and why it was always going to)

The numbers weren't random — they came from different assumptions that nobody had written down.

The prose example assumed a brand-new HVAC unit for the addition. The calculate() function assumed you extend the existing system. Both are defensible. But one lived in my head as I wrote a paragraph at 11pm, and the other lived in a TypeScript function I'd written two weeks earlier. Nothing connected them.

This is the ordinary failure mode of derived data: the moment you store the same fact in two spots, they start drifting the instant you look away. It's the DRY principle, except the duplicated thing isn't code — it's a value a function already knows how to produce. I'd just chosen to retype it.

A static table of "costs by size" is, definitionally, a table of calculate() outputs. A worked example is calculate() plus a sentence explaining it. I had been hand-copying a function's return value into prose and calling it content.

The fix: compute the page from the calculator

The rule I landed on — I call it source-first — has two halves.

Half one: calculate() is the only place a cost is born. Everything else is derived from it at build time. The reference table isn't typed; it's generated by calling calculate() across a range of sizes. Same for the example numbers.

// Before: a hand-typed table that rots independently
const costBySize = [
  { sqft: 200, low: 22000, avg: 32000, high: 48000 }, // typed from "research"
  { sqft: 400, low: 40000, avg: 58000, high: 86000 }, // ...probably
];

// After: the table IS the calculator, sampled at build time
const costBySize = [200, 300, 400, 500].map((sqft) => ({
  sqft,
  ...calculate({ sqft, finish: "mid" }), // single source of truth
}));

Static export makes this clean — it all runs once at build, ships as plain HTML, and there's no way for the table to disagree with the widget because they're the same function. (This is Next.js 16 with output: export, so the page is fully rendered text by the time Google or a user sees it. That matters more than it sounds — but that's a different post.)

The worked examples got the same treatment. Instead of writing "$62,300," the example pulls the real figure and the prose explains the assumption around it:

const inLaw = calculate({ sqft: 400, finish: "mid", hvac: "extend" });
// example text references inLaw.avg, and states the "extend existing" assumption out loud

The $62,300 figure didn't get corrected to $56,800. It stopped existing. There was no longer a number to be wrong.

Half two: every born number carries where it came from. A calculate() is only as honest as its anchor, so each calculator now ships a small provenance object that renders on the page:

costBasis: {
  scenario: "Mid-range room addition, national average",
  nationalAvg: 56800,
  source: "Industry cost data, 2026",
  accessed: "2026-06",
  reviewBy: "2026-12",
}

That reviewBy date is the part I'd push on anyone building this kind of site. Cost data isn't a fact, it's a perishable fact. Putting an expiry on it — visible to the reader, and a reminder to me — is the difference between "numbers I sourced once" and "numbers I maintain."

The counterpoint, because there is one

Generating everything from one function has a failure mode: if the anchor is wrong, it's now wrong consistently, across all four spots, very convincingly. Hand-written numbers at least disagree loudly enough to tip you off — which is exactly how I caught this bug in the first place.

So source-first only pays off if you pair it with the provenance half. The single anchor has to be sourced and dated, not vibes. Otherwise you've just made it easier to be uniformly wrong. I'd still take that trade — a contradiction a user can spot destroys trust faster than an error they can't — but it's a trade, not a free win.

There's also real content this approach can't generate: the why. A function can tell you a 400 sq ft addition averages $56,800. It can't tell you the permit will hold you up six weeks or that the HVAC decision is where people overspend. That part stays hand-written. The rule is narrow: stop hand-writing numbers a function already computes — not stop writing.

What I'd take to the next project

If two places on a page show the same number, one of them should be importing it, not retyping it. This is just DRY, but it's weirdly easy to forget that data is code.
Build-time generation (static export, or any SSG) turns "keep these in sync" from a discipline problem into an impossibility-of-drift property. Let the build do the copying.
Any number that can go stale should ship with a visible source and a review date. It costs five lines and it's the most honest thing on the page.

The whole thing was maybe a day of refactoring across the calculators on costto.build, most of it deleting numbers rather than writing them. The codebase got smaller and stopped lying about itself. That's a good day.

The third enum variant that stopped my tax calculator from lying

Mark — Tue, 16 Jun 2026 01:56:54 +0000

I built a small thing that estimates what a US pay raise actually lands in your pocket after federal tax, FICA, state tax, and inflation. The arithmetic is the boring part. The part that took three rewrites was deciding how to represent fifty states plus DC when you don't actually have clean data for all of them on day one.

This is a writeup of that one decision, because it generalizes well beyond taxes.

The problem isn't the math, it's the gaps

Federal brackets are easy. There's one set of numbers, the IRS publishes them, and progressive tax is a five-line loop:

function taxFromBrackets(taxable: number, brackets: Bracket[]): number {
  if (taxable <= 0) return 0;
  let tax = 0;
  let prevCap = 0;
  for (const { upTo, rate } of brackets) {
    const band = Math.min(taxable, upTo) - prevCap;
    if (band <= 0) break;
    tax += band * rate;
    prevCap = upTo;
  }
  return tax;
}

State tax is the same loop with different numbers. The trouble is that "different numbers" hides a lot. Nine states don't tax wage income at all. A couple (New Hampshire, Tennessee) don't tax wages but have historically taxed other things, so you can't just lump them with Texas without a footnote. Some states publish 2026 figures early; others inflation-index their brackets and won't publish the new thresholds until mid-year. And when I started, I had verified numbers for about ten states and unverified-but-plausible numbers for the rest.

That last category is the dangerous one. The easy move is to ship the plausible numbers and fix them later. The problem is that a wrong tax estimate doesn't look wrong. It looks like a number. Someone in Oregon types in their salary, sees a confident dollar figure, and has no way to know it was a placeholder I never got around to checking.

Two variants felt like enough. It wasn't.

My first model was the obvious one:

type StateTax =
  | { kind: "none"; code: string; name: string; note: string }
  | { kind: "taxed"; code: string; name: string; brackets: ...; standardDeduction: ... };

This is clean and it compiles and it's a lie. It forces every state to be either "no tax" or "here are the exact brackets," which means the moment I add a state to the union, I'm implicitly claiming I've verified it. There's no way for the type to say this state taxes income, but I haven't confirmed the numbers yet. So either I block the entire feature until all 51 are done, or I quietly promote guesses to facts.

The fix was a third variant whose only job is to represent honesty about the gap:

/** Taxing state not yet data-verified — selectable, but calc returns 0 with a UI caveat. */
type PendingState = { kind: "pending"; code: string; name: string };

type StateTax = NoneState | PendingState | TaxedState;

pending means: yes, this state taxes wages, no, I will not pretend to know how much. The calculator returns 0 for it, and the UI renders a visible caveat instead of a clean dollar amount. It's selectable so the dropdown still lists every state, but it can't masquerade as a verified result.

The calculation function gets to stay honest because the type makes the gap unrepresentable as a real value:

function calcStateTax(gross: number, status: FilingStatus, code: string | null): number {
  if (gross <= 0 || !code) return 0;
  const st = STATES_2026[code];
  if (!st || st.kind !== "taxed") return 0; // none AND pending both fall through here
  const taxable = Math.max(0, gross - st.standardDeduction[status]);
  return taxFromBrackets(taxable, st.brackets[status]);
}

The single line st.kind !== "taxed" is the whole point. There is exactly one branch that produces a state-tax number, and it's only reachable when the data has been verified. A pending state and a no-tax state both return 0, but they mean completely different things, and the UI is allowed to treat them differently because the variant carries that distinction.

"Verified" needed a definition I could check later

Once pending existed, I had to define what it took for a state to leave pending. Hand-wavy "I looked it up" doesn't survive contact with a tax year that changes under you. So every taxed state carries its own provenance:

type TaxedState = {
  kind: "taxed";
  brackets: Record<Filing, Bracket[]>;
  standardDeduction: Record<Filing, number>;
  provenance: Provenance; // where each number came from + a dated note
};

The rule I held myself to: a state's numbers only graduate to taxed when they're cross-checked against two independent sources — the state's own Department of Revenue, and an outside table (I used the Tax Foundation's bracket data). Both agree, or it stays pending. The provenance.note records the date and any caveat, like "state inflation-indexes brackets and hasn't published 2026 thresholds, so rates are exact and thresholds are the latest complete schedule."

That sounds like bureaucracy for a side project. But it's the difference between a number I can defend and a number I'm hoping is right. Six months from now when a state changes its top rate, the provenance tells me which states to recheck instead of re-auditing all of them.

The inflation formula people get wrong

Separate gotcha, same theme of "the obvious version is subtly false." A "real" raise — what your raise is worth after inflation eats some of it — is not nominal minus inflation. A 5% raise in 4% inflation is not a 1% real raise.

It's multiplicative, because you're dividing two ratios of purchasing power:

function calcRealRaise(nominalPct: number, inflationPct: number): number {
  const n = nominalPct / 100;
  const i = inflationPct / 100;
  return ((1 + n) / (1 + i) - 1) * 100; // ≈ 0.96%, not 1%
}

The gap is small at low inflation and embarrassing at high inflation. Subtraction says a 10% raise in 9% inflation keeps 1% of growth; the real figure is about 0.92%. At the inflation levels of the last few years that error is big enough to flip "you beat inflation" into "you didn't." I shipped the subtraction version first. A spreadsheet caught me.

What I'd take to the next project

The reusable lesson has nothing to do with taxes:

Model the absence of data as a first-class state, not a falsy placeholder. 0, null, and undefined all collapse "no value" and "value I haven't verified" into the same shape. A named variant keeps them apart and lets the UI tell the user which one they're looking at.
If a number is going to be presented as authoritative, make "unverified" unrepresentable as that number. The type system can enforce that the only code path producing a real figure runs on real data.
Attach provenance to data that decays. Tax tables, prices, anything time-sensitive — a dated source note turns "is this still right?" from a re-audit into a lookup.

The calculator is at raise-calculator.com if you want to poke at the output (the take-home page is where all of this surfaces). But honestly the interesting artifact was the tagged union, not the website. I've started reaching for a pending-style variant in unrelated code now — anywhere I'm tempted to ship a guess that looks like a fact.

If you've got a cleaner way to model "taxing state, unknown brackets" than a third variant, I'd genuinely like to hear it.

What I learned building an after-tax raise calculator

Mark — Mon, 15 Jun 2026 03:02:16 +0000

I built a pay raise calculator because I got a raise, multiplied my salary by 1.05, and then watched my actual paycheck go up by a lot less than I expected. The gap between "5% raise" and "the extra money that shows up" turned out to be wide enough that I wanted to understand it properly — and once I started writing the code, "what's my raise worth?" split into three completely different questions.

This is a write-up of the small TypeScript engine behind it, and the three gotchas that made the math less obvious than salary * 1.05.

Question 1: the gross number (the easy one)

This is the only part that is salary * 1.05:

const newSalary = currentSalary * (1 + raisePct / 100);

A $80,000 salary with a 5% raise is $84,000. A $4,000 raise. Done. This is the number everyone quotes, and it's the least useful one, because you never see $4,000.

Question 2: the after-tax number (where the marginal bracket bites)

The first thing people get wrong — including me, before I wrote this — is assuming a raise is taxed at your average rate. It isn't. A raise lands entirely on top of your existing income, so it's taxed at your marginal rate: the bracket your last dollar falls into.

The other thing people get wrong is the opposite, and it's a myth I wanted the tool to kill: "a raise can bump me into a higher bracket and leave me with less money." That can't happen with progressive brackets — only the dollars inside the higher band are taxed at the higher rate. The brackets are bands, not switches.

So the engine computes total tax at the old and new salary and just subtracts:

type Bracket = { upTo: number; rate: number };

function taxFromBrackets(taxable: number, brackets: Bracket[]): number {
  let tax = 0;
  let prevCap = 0;
  for (const { upTo, rate } of brackets) {
    const band = Math.min(taxable, upTo) - prevCap;
    if (band <= 0) break;
    tax += band * rate;   // only THIS band's dollars get THIS rate
    prevCap = upTo;
  }
  return tax;
}

function netRaise(currentGross: number, newGross: number): number {
  const taxBefore = totalTax(currentGross); // federal + FICA + state
  const taxAfter  = totalTax(newGross);
  return (newGross - currentGross) - (taxAfter - taxBefore);
}

The federal part is easy once you have taxFromBrackets. FICA is where the cliffs live, and it's the part most back-of-envelope calculators skip:

function calcFica(gross: number): number {
  // Social Security: 6.2%, but ONLY up to the annual wage base.
  const ss = Math.min(gross, SS_WAGE_BASE) * 0.062;

  // Medicare: 1.45% on everything...
  let medicare = gross * 0.0145;
  // ...plus a 0.9% surtax on dollars above a high threshold.
  if (gross > ADDITIONAL_MEDICARE_THRESHOLD) {
    medicare += (gross - ADDITIONAL_MEDICARE_THRESHOLD) * 0.009;
  }
  return ss + medicare;
}

That Math.min(gross, SS_WAGE_BASE) is the interesting line. Social Security stops being withheld once you cross the wage base for the year — so the same 5% raise keeps a wildly different fraction of itself depending on where you sit relative to that cap. A raise that straddles the wage base is partly free of the 6.2%; a raise entirely below it isn't. A flat "multiply by 0.92 for taxes" can't express that.

Worked example, $80,000 → $84,000, single filer, no state tax:

	Amount
Gross raise	$4,000
Extra federal tax (22% marginal band)	−$880
Extra FICA (6.2% + 1.45%)	−$306
Net raise	$2,814

You keep about 70% of it. The headline "$4,000" was never going to hit your account. And note the federal hit is 22% even though this person's effective federal rate is around 11% — that's the marginal-vs-average gap in one number.

Question 3: the real number (inflation eats the rest)

Here's the question that actually matters and almost no calculator answers: did your purchasing power go up?

If prices rose 3.3% over the year and your raise was 5%, you are not 5% richer and you're not even 1.7% richer (the naive subtraction). The correct relationship is multiplicative, because you're deflating next year's dollars back to today's:

function realRaise(nominalPct: number, inflationPct: number): number {
  const n = nominalPct / 100;
  const i = inflationPct / 100;
  return ((1 + n) / (1 + i) - 1) * 100;
}

realRaise(5, 3.3); // → 1.645...  not 1.7

So the $4,000-that's-really-$2,814 raise is, in purchasing-power terms, about a 1.6% real raise. And the uncomfortable corollary the tool makes very visible: any nominal raise below the inflation rate is a real pay cut, even though the number on the letter is positive. A "3% raise" in a 3.3% year means you can buy less than you could last year.

The architecture decision that mattered most: one source of truth

The boring part turned out to be the most important. Early on I had tax constants and "current inflation" hardcoded into page copy — $168,600 here, "3.2%" in one blog post, "3.3%" in another. They drifted. A site whose entire pitch is accurate numbers had inconsistent numbers, which is the worst possible failure mode.

The fix was to make every displayed figure — including the ones baked into prose and reference tables — derive from a single constants module, and to compute the example tables at build time from the same engine that powers the live calculator:

// data/tax-2026.ts — the only place a tax/inflation number is written down,
// each one cross-checked against two independent sources before it lands.
export const CPI_U_LATEST = { rate: 0.033, periodLabel: "12 months ending March 2026" };
export const SS_WAGE_BASE = 184_500;
// ...brackets, deductions, FICA rates...

Now a reference table like "what a 3% / 5% / 7% raise nets at $60k / $80k / $100k" isn't typed out by hand — it's a .map() over the same calcRaiseAfterTax the interactive tool calls. The numbers in the article body cannot disagree with the calculator, because they're the same function. Updating for next tax year is a one-line edit to the constants, and the whole site re-derives. (It's a Next.js static export, so all of this runs at build time and ships as plain HTML.)

If I'd known one thing starting out, it's this: for any "calculator" content site, the moment a number exists in two places it's already wrong. Treat the constants as code, compute the prose from them, and never let a human re-type a figure that a function can produce.

Takeaways

A raise is taxed at your marginal rate, not your average — but progressive brackets mean a raise can never lower your take-home.
FICA wage-base and surtax thresholds create cliffs that flat "multiply by 0.9" estimates silently miss.
Real (inflation-adjusted) raise is (1+n)/(1+i) − 1, not n − i, and it's the only one of the three numbers that tells you whether you're actually better off.
Derive every displayed figure from one constants module. If a number lives in two files, you have a bug waiting to surface.

The live version with the interactive math is at raise-calculator.com if you want to plug in your own numbers — but honestly the three formulas above are the whole thing. Happy to talk through the bracket edge cases in the comments.

Generating valid .ics calendar feeds at build time

Mark — Sun, 14 Jun 2026 03:45:33 +0000

A few weeks ago I shipped a feature I'd been putting off because it felt like it needed a backend: subscribable calendar feeds. "Add this holiday to Google Calendar." "Subscribe to all your country's public holidays so they show up in Apple Calendar forever."

Every calendar competitor has this. My site had none. The catch: the whole thing is a static export — next build produces a folder of HTML/CSS/JS that I drop on Cloudflare Pages. No server, no API routes at request time, no ISR. So how do you serve a .ics feed that a calendar app polls every few hours?

Turns out you don't need a server at all. Here's the approach, the RFC 5545 gotchas that bit me, and the parts I'd tell my past self.

The "aha": a feed is just a file

A .ics subscription feed is not a live API. It's a static text file that calendar clients re-fetch on a schedule. So for a static site, the idiomatic move is a post-build emitter: after next build, run a Node script that walks your data and writes assets straight into out/.

# scripts/deploy.sh
npx next build
node scripts/emit-feeds.mjs   # writes .ics + .json into out/

That's the entire architecture. The emitter reads the same JSON the pages render from, so the feeds can never drift out of sync with the site — there's one source of truth. It emits:

a per-year feed (holidays-de-2026.ics)
a per-holiday feed (one event, for the "download this day" button)
an all-years subscription feed (the one you point webcal:// at)
and, almost for free in the same loop, a JSON API under out/api/

No new pages, no new routes. Just files.

RFC 5545: all-day events are sneakier than they look

I assumed an all-day event on Jan 1 would be DTSTART:20260101, DTEND:20260101. Wrong. DTEND is exclusive. A one-day all-day event ends on Jan 2:

BEGIN:VEVENT
UID:de-2026-neujahr@calendana.com
DTSTAMP:20260614T101500Z
DTSTART;VALUE=DATE:20260101
DTEND;VALUE=DATE:20260102
SUMMARY:Neujahr
TRANSP:TRANSPARENT
CATEGORIES:Holiday
END:VEVENT

Get this wrong and some clients render a zero-length event, or silently drop it. Other things the spec is quietly strict about, all of which I learned by importing broken files into Apple Calendar and watching nothing appear:

CRLF line endings. Not \n. \r\n, everywhere.
75-octet line folding. Lines longer than 75 bytes (not chars — bytes) must be folded, with continuation lines starting with a single space. The byte distinction matters the moment you have non-ASCII content; you must never split a multi-byte UTF-8 codepoint across the fold.
TEXT escaping. Commas, semicolons, backslashes and newlines in SUMMARY/DESCRIPTION have to be escaped (\, \; \\ \n).
A stable UID. If the UID changes between rebuilds, every subscriber gets duplicate events on the next poll. Mine is deterministic: {locale}-{year}-{key}@domain.

The folding function is the bit worth copying, because the byte-vs-char trap is easy to miss:

function foldLine(line) {
  const bytes = new TextEncoder().encode(line);
  if (bytes.length <= 75) return line;
  const dec = new TextDecoder();
  const out = [];
  let start = 0;
  let limit = 75;
  while (start < bytes.length) {
    let end = Math.min(start + limit, bytes.length);
    // back off if the cut lands mid-codepoint (UTF-8 continuation = 10xxxxxx)
    while (end < bytes.length && (bytes[end] & 0xc0) === 0x80) end--;
    out.push((start === 0 ? "" : " ") + dec.decode(bytes.slice(start, end)));
    start = end;
    limit = 74; // continuation lines spend 1 octet on the leading space
  }
  return out.join("\r\n");
}

The zero-infra trick: deeplinks

The .ics files cover "download" and "subscribe." But the highest-intent button — "Add to Google Calendar" — needs no file at all. Google and Outlook both accept a URL that pre-fills a new event:

function googleHref({ name, date }) {
  const compact = (iso) => iso.replace(/-/g, "");
  const next = nextDay(date); // remember: end is exclusive
  const p = new URLSearchParams({
    action: "TEMPLATE",
    text: name,
    dates: `${compact(date)}/${compact(next)}`,
  });
  return `https://calendar.google.com/calendar/render?${p}`;
}

One <a href>. No JS, no library, works on a static page. (Outlook's equivalent is outlook.live.com/calendar/0/deeplink/compose — note the deeplink segment; I shipped it once without it and the prefill silently failed.)

Serving the right MIME type on a static host

If you serve .ics as text/plain, some clients refuse it. On Cloudflare Pages a single _headers file in public/ handles it:

/*.ics
  Content-Type: text/calendar; charset=utf-8
  Cache-Control: public, max-age=86400
/api/*
  Content-Type: application/json; charset=utf-8
  Access-Control-Allow-Origin: *

The part that's actually hard: 15 languages

This is the bit I keep coming back to. The site runs in 15 locales, and the temptation with any multilingual feature is to write the English microcopy once and machine-translate it ×15. Don't. For a content/SEO site that's a fast track to thin, near-duplicate pages that search engines won't index — and for a calendar, it's also just wrong. A Mexican user wants "Agregar a Google Calendar" for "días festivos"; a Spaniard wants "Añadir" for "festivos"; an Argentine says "feriados." Same language, three different words. Those got hand-written per locale, sharing one strings file that both the Node emitter and the React components read, so the button label and the feed's calendar name always agree.

That single-source-of-everything theme — one holiday JSON feeding the pages, the feeds, and the API; one strings file feeding the emitter and the UI — is what kept this feature from becoming a maintenance swamp.

Where it lives

The site is Calendana — printable calendars plus public-holiday and school-holiday data for a bunch of countries, all static, all free, ad-supported, no login. The calendar-export work is live on every holiday page now. If you just want to see the feed format, grab one and open it:

https://calendana.com/de/holidays/2026/holidays-de-2026.ics

or the JSON, if you're building something:

https://calendana.com/api/holidays/de/2026.json

Takeaways

"Needs a backend" is often a reflex, not a requirement. A subscription feed is a file. A "create event" button is a URL. Both fit a static site fine.
Read the RFC. All-day DTEND is exclusive, lines fold on bytes, endings are CRLF. The spec is boring and it is right.
Generate sibling artifacts from one source. Pages, .ics, and JSON all come from the same data in one build step, so they can't disagree.
Localize the words, not just the dates. Especially when "the same language" means different words in different countries.

Happy to answer questions on the emitter or the folding/escaping details in the comments — that's where most of the sharp edges were.

Encoding FIFA’s 495 third-place scenarios for the 2026 World Cup

Mark — Wed, 27 May 2026 08:04:24 +0000

I expected the 2026 World Cup bracket to be a sorting problem.

It turned out to be a sorting problem plus a lookup table.

I recently worked on a small World Cup 2026 bracket project, and the strangest part was not building the knockout bracket itself. It was handling the third-placed teams.

The new format has:

48 teams
12 groups
24 teams qualifying as group winners and runners-up
8 more teams qualifying as the best third-placed teams
a new Round of 32

At first, this sounded straightforward.

Rank the third-placed teams, take the best 8, then put them into the knockout bracket.

But the last step is where it gets weird.

Ranking third-placed teams is the easy part

Once every group has a table, each group gives you one third-placed team.

That gives you 12 third-placed teams.

From there, the basic ranking can be represented as a normal sorting problem:

type GroupId =
  | "A" | "B" | "C" | "D"
  | "E" | "F" | "G" | "H"
  | "I" | "J" | "K" | "L";

type TeamStanding = {
  teamId: string;
  group: GroupId;
  position: number;
  points: number;
  goalDifference: number;
  goalsFor: number;
  fairPlayPoints: number;
};

A simplified ranking function might look like this:

function rankThirdPlacedTeams(teams: TeamStanding[]) {
  return [...teams].sort((a, b) =>
    b.points - a.points ||
    b.goalDifference - a.goalDifference ||
    b.goalsFor - a.goalsFor ||
    a.fairPlayPoints - b.fairPlayPoints
  );
}

This is not the complete official tie-breaker system, but it shows the shape of the problem.

You filter the third-placed teams:

const thirdPlacedTeams = groupTables
  .map(group => group.standings.find(team => team.position === 3))
  .filter(Boolean);

Then you take the top 8:

const qualifiedThirds = rankThirdPlacedTeams(thirdPlacedTeams).slice(0, 8);

So far, this still feels like a normal algorithm problem.

But then comes the awkward part.

The bracket position is not simply “best third-place team goes here”

My first assumption was that the best third-placed team would go into one slot, the second-best into another slot, and so on.

That is not how it works.

The Round of 32 matchup depends on which groups the qualifying third-placed teams came from.

For example, if the qualifying third-placed teams come from groups:

["C", "D", "E", "F", "G", "I", "K", "L"]

that combination maps to one specific set of Round of 32 positions.

If the qualifying groups are:

["B", "D", "E", "F", "G", "I", "K", "L"]

that maps differently.

So the key is not only ranking the third-placed teams.

The key is identifying the set of groups they came from.

With 12 groups and 8 third-placed teams qualifying, the number of possible group combinations is:

C(12, 8) = 495

That means there are 495 possible sets of qualifying third-placed groups.

This is where the implementation stops being a clean formula and becomes a data problem.

Turning the qualified groups into a key

The simplest way I found to model this was to turn the list of qualifying third-place groups into a stable key.

function getThirdPlaceCombinationKey(teams: TeamStanding[]) {
  return teams
    .map(team => team.group)
    .sort()
    .join("");
}

So if the qualified third-placed teams came from groups C, D, E, F, G, I, K, and L, the key becomes:

"CDEFGIKL"

This key can then be used to look up the official mapping for the Round of 32.

const qualifiedThirds = rankThirdPlacedTeams(thirdPlacedTeams).slice(0, 8);

const combinationKey = getThirdPlaceCombinationKey(qualifiedThirds);

Now we can use that key to answer the real question:

Where does each third-placed team go in the bracket?

Representing the mapping as data

Instead of trying to derive the Round of 32 slots every time, I treated the official scenarios as a lookup table.

A simplified version looks like this:

type RoundOf32Slot =
  | "1A" | "1B" | "1D" | "1E"
  | "1G" | "1I" | "1K" | "1L";

type ThirdPlaceSource = `3${GroupId}`;

type ThirdPlaceMapping = Record<RoundOf32Slot, ThirdPlaceSource>;

const thirdPlaceSlotMap: Record<string, ThirdPlaceMapping> = {
  CDEFGIKL: {
    "1A": "3E",
    "1B": "3G",
    "1D": "3I",
    "1E": "3D",
    "1G": "3F",
    "1I": "3C",
    "1K": "3L",
    "1L": "3K",
  },

  BDEFGIKL: {
    "1A": "3E",
    "1B": "3G",
    "1D": "3I",
    "1E": "3D",
    "1G": "3F",
    "1I": "3B",
    "1K": "3L",
    "1L": "3K",
  },

  // ...493 more combinations
};

The exact values need to come from the official table, but the structure is the important part.

The code is not trying to be clever.

It is just making the official tournament rules usable inside an app.

Filling the actual teams into the bracket

Once the mapping is known, the rest is more mechanical.

For each Round of 32 slot, find the third-placed team from the mapped group.

function getThirdPlacedTeamFromGroup(
  qualifiedThirds: TeamStanding[],
  source: ThirdPlaceSource
) {
  const group = source.replace("3", "") as GroupId;

  return qualifiedThirds.find(team => team.group === group);
}

Then apply the mapping:

function resolveThirdPlaceSlots(
  qualifiedThirds: TeamStanding[],
  mapping: ThirdPlaceMapping
) {
  return Object.entries(mapping).map(([slot, source]) => {
    return {
      slot,
      source,
      team: getThirdPlacedTeamFromGroup(qualifiedThirds, source),
    };
  });
}

And the full flow becomes:

const qualifiedThirds = rankThirdPlacedTeams(thirdPlacedTeams).slice(0, 8);

const combinationKey = getThirdPlaceCombinationKey(qualifiedThirds);

const mapping = thirdPlaceSlotMap[combinationKey];

const resolvedSlots = resolveThirdPlaceSlots(qualifiedThirds, mapping);

At this point, the app can place the correct third-placed teams into the Round of 32.

What made this interesting

I usually prefer deriving things from rules instead of hardcoding large tables.

But this was a case where the table itself is part of the rule.

The bracket is not just:

sort teams → seed teams → generate matches

It is closer to:

sort teams → identify qualified groups → use official mapping → generate matches

That small difference changes the architecture.

The app needs both:

normal ranking logic
a predefined scenario table

That is what made this more interesting than a standard tournament bracket.

Why I did not want to hide all of this

From the user’s point of view, none of this should feel complicated.

They should be able to fill out groups, move into the knockout rounds, and understand what happened.

But from the developer’s point of view, the Round of 32 is doing quite a lot behind the scenes.

That also creates a UX question:

How much of this logic should be visible?

If you expose every rule, the page starts to feel like documentation.

If you hide everything, the bracket can feel random.

That balance was one of the harder parts of the project.

The working version

I used this logic in a small bracket predictor here:

https://bracket2026.com

The main goal was to make the new 48-team format easier to play with, especially the Round of 32.

Building it reminded me that some “simple” sports tools are not simple because the UI is complex.

They are complex because the real-world rules are strange.

And sometimes the cleanest code is not the cleverest algorithm.

Sometimes it is a boring lookup table that faithfully represents the rules.

DEV Community: Mark

Modeling the Expected Value of a Sealed Card Box (and Where the Number Quietly Lies)

The formula is the easy part

Where it starts lying

Turn the point estimate into a range

What the model is actually for

Forecasting from a Government PDF: What I Learned Modeling the Visa Bulletin

The parsing is annoying before it is hard

Movement is not a smooth signal

Why a point estimate is the wrong output

The honest limits, stated plainly

What actually transfers

The Minecraft anvil is a tree-cost optimization problem in disguise

Two rules that quietly interact

Why order is the whole game

Why I stopped doing this in my head

The takeaway for builders

The hardest part of a pre-release game tracker isn't the UI, it's the provenance field

Why this is easy to underestimate

A concrete case: the stat that wasn't final

Where this actually gets built

The limits are part of the design

The takeaway for anyone building something similar

The data model behind an employee cost calculator is messier than the UI

The first product decision: show the assumptions

State-specific logic changes the shape of the code

Estimated does not mean sloppy

The edge case that keeps showing up

The useful abstraction

The Unicode trap I had to design around in a LinkedIn formatter

The tempting bad version

Unicode styled text is less harmless than it looks

The UI choice: make restraint the default

The accessibility note is part of the product

What I would build differently next time

The lesson

A roof calculator that multiplies length by width is lying to you

The roof you measure isn't the roof you walk on

Area is necessary and completely insufficient

The boring decision that mattered most

The takeaway, if there is one

The worked example that disagreed with its own calculator

Four sources of truth for one number

Why it happened (and why it was always going to)

The fix: compute the page from the calculator

The counterpoint, because there is one

What I'd take to the next project

The third enum variant that stopped my tax calculator from lying

The problem isn't the math, it's the gaps

Two variants felt like enough. It wasn't.

"Verified" needed a definition I could check later

The inflation formula people get wrong

What I'd take to the next project

What I learned building an after-tax raise calculator

Question 1: the gross number (the easy one)

Question 2: the after-tax number (where the marginal bracket bites)

Question 3: the real number (inflation eats the rest)

The architecture decision that mattered most: one source of truth

Takeaways

Generating valid .ics calendar feeds at build time

The "aha": a feed is just a file

RFC 5545: all-day events are sneakier than they look

The zero-infra trick: deeplinks

Serving the right MIME type on a static host

The part that's actually hard: 15 languages

Where it lives

Takeaways

Encoding FIFA’s 495 third-place scenarios for the 2026 World Cup

Ranking third-placed teams is the easy part

The bracket position is not simply “best third-place team goes here”

Turning the qualified groups into a key

Representing the mapping as data

Filling the actual teams into the bracket

What made this interesting

Why I did not want to hide all of this

The working version

References