'Newest First' Is a Re-Priority Problem, Not an ORDER BY

A customer wanted new event folders at the top of one admin list. The list already had an order. People had put it there by hand. I nearly flipped one sort direction and reversed all of it.

The column already had an owner

The list was sorted by a column called priority, lowest number first. That looks like the most ordinary thing in the world until you ask what writes to it.

Nothing writes a date to that column. People do. They drag folders up and down until the list looks the way they want it to look, and the drag saves a number on each row so the arrangement sticks. A folder sitting third is third because somebody decided it should be third.

So reversing the sort would not have shown newest first. It would have turned every arranged list in the product upside down. A customer who spent an afternoon getting their folders into the right order would have opened the page the next morning and found their afternoon undone.

What they actually asked for was much smaller. One new folder at the top, and everything else still meaning what it meant yesterday. That moves the job from how the list gets read to what happens the moment a folder gets created. Give the new one a number that lands it above the current top, and leave every other row alone.

The rows that came before the feature

A table with twenty years of rows in it has rows made by paths that stopped existing a decade ago. Plenty of them have no meaningful position at all, because they were created before anyone could drag anything. They sit at zero, or at a negative number, or at nothing.

You cannot put a row above a row whose position is undefined. So before it does anything else, the code looks at the current top row. If that row’s number is unusable, it repairs the list first: walk the folders in the order the screen is already showing them, and renumber them one, two, three, on down.

That repair is not free. It writes to every folder under that parent, one at a time. On a customer with a long list, that is the part of this change worth knowing about. The bit that actually puts the new folder on top is two lines.

Kept to the one screen that asked

The code that creates these folders is shared. A lot of different screens make new things through it, and they do not all want their new thing at the top.

So the new behavior sits behind a check for which screen the request came from. One line. Anything that does not match that check goes down the same road it went down before. In a shared path, that check is the entire safety margin. Without it, one customer’s request about one list quietly becomes a change that everybody gets.

The wrinkle I left in

Here is the decision that positions the new folder, with the names shortened. It is the only part of this worth putting on screen.

if (top <= 0) {
  renumber(parent);
  top = 1;
}

newPos = (top === 1)
  ? -1
  : top - 1;

If the top folder is at 8, the new one gets 7. If it is at 2, the new one gets 1. Nothing else moves, which is the whole point.

Now read those two halves against each other.

When the top folder is sitting at 1, the first line treats that as perfectly healthy, skips the repair, and hands the new folder a position of -1. Which means the top of that list is now a negative number. Which is exactly what the line above calls unusable.

So the next person who adds a folder there trips the repair. The check sees a negative number on top, decides the list is damaged, renumbers every folder underneath that parent, and then the last line looks at the fresh 1 and writes another -1.

It works. The folder lands on top, nobody’s ordering gets reversed, the customer got what they asked for and never wrote back. But the first create hands the code the exact mess the repair exists to clean up, and every create after it pays for the cleanup. I found that reading my own diff five months later, which is not the same thing as catching it in review.