Reusing the bounded-window measurement pattern from an adaptive concurrency controller to detect query outliers — except answering ‘is this unusual relative to normal?’ needed a lot more state than reacting to the present moment did.
A database cost project that started as ‘move data to cheaper storage’ ended by eliminating the biggest dependency entirely, once the team stopped treating an existing implementation’s requirements as fixed and started asking what outcome each one actually served.
A whiteboard design and the system that ships from it are never the same thing. Revisiting a project well after handoff means reconstructing what actually shipped together, not grading it against the original diagram.
LLMs make it possible for one person to prototype several plausible end-to-end designs before a cross-team feasibility conversation starts, turning a blank whiteboard into a concrete comparison of trade-offs.
Rolling up team estimates for an ambitious cross-team project hides the architectural choices behind them. Real feasibility work means simulating how the pieces fit together before anyone estimates.
Leaving a comment every time something catches your eye feels like a thorough review, but it just hands the author a pile of reactions to organize. Here’s how to review like you’re helping drive a decision, not narrating your read.
Comment threads on a design doc create a false sense of progress. Real design review means treating comments as signals to synthesize into decisions, not a checklist to clear one thread at a time.
Software engineers are told to automate or be automated. But 150 years ago, the typewriter promised the same thing — and real adoption was gradual.
Sometimes when you are inspecting data, you come across duplicates that shouldn’t exist. Here’s a an easy way to remove duplicate rows using the ROW_NUMBER function. In a previous post about using ROW_NUMBER to find the latest record for each member in a group, I set up some sample data with this statement: CREATE TABLE metrics AS ( SELECT date, CASE WHEN n > random() * 2 and n < random() * 4 THEN 'A' WHEN n > random() * 2 and n < random() * 4 THEN 'B' WHEN n > random() * 4 and n < random() * 6 THEN 'C' WHEN n > random() * 6 and n < random() * 8 THEN 'D' WHEN n > random() * 8 and n < random() * 10 THEN 'E' ELSE 'F' END as metric, round(random() * 1000) as value FROM generate_series(1,11,1) as n JOIN ( SELECT day + interval '1 day' * round(random()*100) as date FROM generate_series('2019-01-01', '2019-01-31', interval '1 day') day ) d ON true ); While that statement is a great way to get a bunch of random sample data to play with, there is no guarantee that the values or the dates will be unique. In fact, there were several entries for the same metric on the same date: ...
In this post, we’re going to look at a techinque for finding the lastest full record for each member of a group. Now, it might not be obvious why this is an annoying problem, but I see people back into having this problem from two different directions. First, you know how to find the MAX date for each member in a group: metric | latest_metric --------+------------------------ A | 2019-04-30 00:00:00-04 B | 2019-05-08 00:00:00-04 C | 2019-05-08 00:00:00-04 D | 2019-05-08 00:00:00-04 E | 2019-05-08 00:00:00-04 F | 2019-05-08 00:00:00-04 (6 rows) But you need additional column data from the same row as that most recent date. ...