// project
Field notes from an engineer who writes: one war story, four channels, one branded card.
The brief
The Loopdown is the writing side of the same discipline the rest of this site argues for: a lesson is pulled from a real production incident, written once, and adapted, never re-derived from scratch, for every place it will be read. 17 lessons across 8 series sit alongside a 10-piece back catalogue from before the code, all versioned in one repo with the same public/private split a codebase gets: the engine and what's published are tracked, drafts and personal notes are gitignored.
What shipped
// case study
The problem
A lesson pulled from real production work is only worth writing once if it can reach LinkedIn, dev.to, Hashnode and Medium without being rewritten by hand four times, in four different voices, from scratch.
The decision
Build the adaptation as the product: one lesson goes in, four channel-shaped posts come out, each with its own generated branded SVG card, checked against a voice profile derived from the existing archive by a lint step rather than trusted on read.
The result
6 of the 17 lessons are out across all four channels so far, with the rest drafted and channel-adapted (status: ready). The engine produces four-channel output every time; the publishing backlog is the honest, unfinished part.
6 lesson published across all four channels so far
17
lessons · 8 series
4
channels per lesson · dev.to, LinkedIn, Medium, Hashnode
10
archive pieces · from before the code
6
lesson published across all four channels so far
// design notes
A lesson is written once and adapted to LinkedIn, dev.to, Hashnode and Medium, each with its own generated branded SVG card. The adaptation is the product, not the writing. A dev.to post reads like a dev.to post and a LinkedIn post reads like a LinkedIn post, from the same source material.
Every series traces back to a specific piece of shipped work, not a generic topic: "Sensors Who Lie" is field notes from Doori's location engine, "The Coroutine Court" from the −80% crash-reduction work, "The Night Shift" from the 50%→95% GPS accuracy work, "Ghosts in the Recomposition" from the ~87% Compose migration, and "One Brain, Two Bodies" from PaymentsLab-KMP's expect/actual split across targets. The writing has somewhere real to point back to.
"Sensors Who Lie" runs longest at 5 episodes; "Chain Of Custody" runs 4; the rest are shorter. By pillar, data-integrity carries the most lessons (9 of 17): Kalman-filtered sensors and Room migrations produce more "the data lied to you and here's the invariant that catches it" moments than any other pillar the archive covers.
The generated drafts are checked against a voice profile derived from the existing archive rather than trusted on read. A lint step, not a style guide nobody reads, so a draft that sounds like a language model wrote it fails before it reaches a channel.
11 of the 17 lessons are drafted and channel-adapted (status: ready). Actually out across all four channels so far: 6, "collectAsState is quietly leaking your work", from the ghosts-in-the-recomposition series. The engine is built to produce four-channel output per lesson; the publishing backlog is the honest, unfinished part.
A consolidated back catalogue from Books Before Bros, the original blog: campus lore and short fiction predating the engineering work, 6 pieces of short fiction, 2 essays and 2 humor pieces, kept in the same repo as the lessons rather than left to rot on an old WordPress install.
The whole archive is framed as an engineer stuck in a time loop, filing field notes on the same lying systems each pass: the sensor that reports a position it cannot back up, the coroutine that outlives the screen that launched it. The conceit gives every lesson the same voice without flattening what each one is actually about.
Each recurring character personifies one failure mode rather than one lesson, so continuity builds across entries instead of resetting every post: The Concussed Witness (GPS, or any sensor that reports with total confidence and zero reliability) leads the bestiary at 5 tracked appearances, alongside The Archivist (provenance and the audit trail), Doze the Jailer (Android's background-execution limits) and The Messenger (CancellationException, forever mistaken for an assassin). A living bestiary indexes who's appeared and who's still waiting in the wings, the same continuity discipline a codebase gets from a changelog.
// under the hood
frequently asked
SDE-2, Android & Product Owner at Dice.tech (June 2023 - Present), platform owner of the app behind 50k+ monthly active users (22k+ daily, platform owner at Dice.tech). See the source.
Took GPS accuracy to 95%: up from 50%, by predictive dead reckoning. See the source.
80% crash reduction: Crashlytics + structured concurrency fixes. See the source.
~87% of the UI layer: 455k of 523k UI-layer LOC, verified screen by screen against the legacy XML. See the source.
B.Tech, Computer Science & Engineering, NIT Bhopal (MANIT) (2017 - 2021). See the source.
Consulting Engineer, Platform & AI at Neev Consulting (April 2026 - Present). Built the LLM assistant layer of an ERPNext/Frappe consulting ERP: business-context resolution, capability discovery, and an AI capability gate that defaults OFF with a test proving it. Models client to project to PO to milestone to GST invoice to payment end to end. See the source.
Doori: Offline-first mileage, travel & expense tracker on one Kotlin codebase across Android, iOS, Wear OS, watchOS & Desktop. See the source.
Gaddi: A Hinglish social-deduction bluffing game of power, satire & second chances. Gaddi ke liye kuch bhi karega. See the source.
PaymentsLab-KMP: An Integration Lab for the Android payments ecosystem: every gateway behind one abstraction, with a live look at what actually happens on each transaction. See the source.
Candidai: A native, multiplatform AI career-intelligence engine, and the open-source project it's built on. See the source.
Yes: The Loopdown, his field-notes writing hub, where the recurring bug characters are named after real production incidents. See the source.
Answered by his own teammates, not by him: see the EB Profiles, one question per member, in their own words. See the source.
Open to remote (worldwide / India) and hybrid in Pune / Bengaluru. Email siddharthpandalai990@gmail.com. See the source.
Shared Kotlin Multiplatform libraries used across his own apps, plus merged upstream pull requests on career-ops: see the repos and the running count. See the source.
Yes: see the Play Store shelf for the apps that are actually live and installable, not just source. See the source.
Every route on the site, as a tile you can open: 3D builds, labs and canvases, not screenshots. See the source.