About
I’m a backend engineer drawn to one specific problem shape: systems that can report, honestly, on their own state. Not a dashboard bolted on afterward: logging, metrics, and provenance built in as part of the system’s job, not an afterthought to it. A retrieval pipeline that can report its own latency. A knowledge store that can say when it last measured itself. That instinct is the whole thesis of this site: every number on it carries the method and the date it was measured, because a system I can’t interrogate isn’t one I’d trust in production either.
At Accenture, between 2025-02-24 and 2026-08-05, work came in at a median of Methodmedian count of work items assigned per calendar month, 2025-02-24 to 2026-08-05 (19 months). Mean is 5.1 tickets/month, but two months at 13 and 16 skew it upward, so the median is the representative figure. Same private Azure DevOps export, no public URLDateSample sizen = 19. I was assigned Methodcount of Azure DevOps work items ever assigned to me, 2025-02-24 to 2026-08-05: 52 Task, 37 Bug, 8 User Story. Private Azure DevOps export, internal client system, no public URLDate work items over that stretch and personally resolved or closed Methodof the 97 work items ever assigned to me (see accenture-work-items-assigned), count whose state I personally transitioned to Resolved or Closed at least once. Same private Azure DevOps export, no public URLDateSample sizen = 97 of them, at a median of Methodmedian of assignment-to-resolution calendar days across the 20 of 51 resolved-or-closed items (see accenture-work-items-resolved) that have a usable timestamp on both ends. The other 31 are excluded: the export stamps an unusable placeholder date on one side of the interval for those, so this is measured on 39% of the eligible 51, not all of them. p25 1.7 days, p75 7.4 days, p90 9.2 days, max 13.8 days. Same private export, no public URLDateSample sizen = 20 from assignment to my own close. That figure’s own method says exactly how much of what I resolved it covers, and why the rest doesn’t, and I’d rather you read the caveat than not know it exists. I authored pull requests too, and Methodpull requests I authored, 2025-02-24 to 2026-08-05, whose state is Merged: 19 of 20 authored. The 1 remaining is still open with a merge conflict. Same private Azure DevOps export, no public URLDateSample sizen = 20 of them merged; one is still open with a conflict.
None of those five numbers link anywhere. The export behind them is a private client system with no public URL, so for once you have my stated method and not a receipt to click through and check yourself. Here’s what that same discipline looked like on one ticket that had already been closed twice before the third close held.
Decision record
ADR-001
Mapping every approval check at once, instead of resubmitting and hoping
Context
A relocation event updated one internal location field on a record but left a paired field on its old value. An automated integration resubmitted the correct value once a day, and once a day an internal approval rule engine silently rejected it with a generic not-permitted error and no indication of which check had failed. The ticket had already been closed twice by the time it reached me, each close treating the rejection as one bad update rather than a symptom of something structural, one of 97 work items assigned to me over that period (see accenture-work-items-assigned).
Options considered
- Treat the rejection as an isolated bad value and resubmit it again, the way both earlier closes had.
- Escalate to the rule engine's owning team without first reproducing which of its checks was actually failing.
- Map all three of the rule engine's independent approval checks myself, test each one against the record directly, and reconstruct the record's full timeline before proposing a fix.
Decision
I mapped all three approval checks and tested each one against the record directly. All three failed for the same underlying reason: the destination was approved for the account, but filed under a different internal business grouping than the one the record's project used. I reconstructed the record's history and found the mismatch had sat unvalidated for over a year, surfacing only because an unrelated policy change had started evaluating old records against current rules.
Consequences
- The first two closes had each treated the rejection as one failed update and resubmitted the same value; the daily integration hit the same silent rejection again and the ticket reopened both times.
- The third close held, because it closed off every alternate explanation at once instead of one at a time; there was nothing left for a fourth reopen to attach to.
What I'd change
I'd push for the business-grouping metadata to be validated at creation time, so a mismatch like this surfaces in days instead of sitting unvalidated for over a year. Whether that happened, I can't tell you: the export I'm working from ends at my recommendation, with no confirmation of what was changed or whether it held.
Outside work, the same instinct shows up at a different scale and for a different audience: Synapse, tldr, and claude-jarvis are agent infrastructure built for anyone who clones the repository and reads the code, not for an internal audience taking the system on trust. Different scale, different audience, same discipline.
Background, briefly: a Claude Certified Architect – Foundations credential from Anthropic, a Reinvention with Agentic AI credential from Accenture, and a B.Tech in Computer Science and Engineering from Techno International New Town (2020–2024). None of it is the headline here; the code and the numbers are.
I’m based in Kolkata, India, and open to remote work. Status: immediate joiner (the same words this site opens with, because they’re still accurate). You can also book a 30-minute call (opens in new tab) with me directly.