Somebody in a design discussion asks whether you should cache that, or add an index, or split the job into batches. You have an instinct, and underneath the instinct is nothing at all, because you do not know how big any of it is.
This is the most common gap I see in people three years in, and it is also the easiest one to close.
Almost every engineering question is a question about size wearing a disguise. Four thousand rows and four hundred million rows are different problems with the same schema and the same query. A job that runs in nine seconds and a job that runs in nine hours want different designs. Without the magnitudes you are reasoning about a shape, and everybody in the room is doing the same thing, which is why those conversations go round.
So go and learn the numbers for the system you actually work on. Half a dozen is plenty. How many of the main thing happen in a day, an order, a claim, a booking, whatever your system exists for. The row count of the biggest table and how much it grows in a month, because the growth is what will hurt you next year. What the busiest hour looks like against the average, which is usually a much bigger gap than people guess. How slow the one endpoint that matters is when it is slow, not on average. The largest thing anybody sends you. How long a restore takes.
You can find most of these in an afternoon, from the database's own statistics and the dashboard nobody opens.
What changes afterwards is your standing in the room. You stop trading anecdotes and start saying that table holds around three hundred thousand rows and adds twenty thousand a month, which ends a lot of arguments in one sentence. You also stop worrying about performance problems that do not exist, and start noticing the ones arriving on a schedule.
Monday: write your six numbers on one page, then show them to somebody who would know, and let them correct you. The corrections are the best part.
– Asael Shinder
Top comments (0)