Original Summary

Spent last night nearly shipping a sentence that was wrong in the most embarrassing way available: my own two scripts disagreed about a number and I believed the one that told the better story. Setup. I run a paper trading desk and a morning job counts how many option contracts from an expired batch are still sitting open. At 09:00 it said 96. At 16:00 it said 96. At 20:00 a different script said 80. Sixteen had cleared on a Saturday. I wrote the card. "The queue is draining." It was a nice little progress post. Then instead of counting the survivors a fourth time, I asked the data when it moved: sql select exit_date, count(*) from positions where last_exp = '2026-09-18' and status = 'closed' group by exit_date; Not one row carried Saturday's date. The last exits in that batch were dated Friday. Nothing had settled at all. The entire drain was two scripts disagreeing about one unchanged thing. The root cause, and this is the bit worth stealing. I had assumed a contract symbol is one symbol. For a single leg it is. For a multi-leg position mine looks like this: OCC|put_spread|opt:sell:put:1:AAPL260911P00302500|opt:buy:put:1:AAPL260918P00292500 Two expiry dates in one string. The morning script did re.search(r'(\d{6})[CP]\d{8}', sym) and took the first match, which is the near leg, 09-11. So a live spread whose real expiry is the 18th got filed as an eight-day-old straggler. The evening script used max() over re.findall of the same pattern and got the real final expiry. One of them was counting a different set of positions than the other. Neither was random, neither threw an error, and both looked completely reasonable in the log. Tools, since the sub asks: Postgres for the book, plain Python for the counters, and an AI assistant wrote the first draft of both scripts. The first-match regex was mine to approve, and I approved it without reading what a spread symbol actually looks like. Two things I took away. When a count of something static moves, don't recount it, ask the data when it moved. A second count is a second opinion. A timestamp is falsifiable. That one query killed a false story in about ten seconds after two scripts and three hours failed to. A success-shaped bug is the dangerous kind. If the evening script had said 112 I'd have gone looking immediately. It said 80, which looked like progress, so I reached for the keyboard instead of the query. The bugs that flatter you are the ones that ship. Anyone else got a parser that silently read the wrong field out of a packed string. I want to know how you found yours, because I only found mine by accident.   submitted by   /u/QuanTradin [link]   [comments]

  • 情报分类：工作与职业机会
  • 分类依据：内容涉及招聘、求职或职业发展
  • 信息来源：Reddit · SideProject
  • 发布时间：2026/9/20 21:22:01