who am i?

hey, you found this.

i don't write often. this isn't a blog and it's not a portfolio piece — it's more like an honest answer to a question i keep getting asked. who are you, actually. so here's the attempt.

how i think

i think in systems, not in features. whenever i look at something new — a protocol, a codebase, a team — my first instinct is to map the failure modes before i understand the happy path. that reflex came from building backend infrastructure where something breaking at 3am is entirely your problem.

building and thinking are the same motion for me. i don't finish the spec before i start writing code. the implementation always knows something the document doesn't. i'd rather have something running and wrong than something theoretically perfect and not yet real. i'm a purist about the outcome, not the path.

i obsess over the details that matter. the trick is figuring out which ones those are and ignoring the rest. that distinction takes longer to learn than any technical skill.

how i got here

i didn't plan any of this. chaidex was my first real bet — build the entire backend for a decentralized exchange from scratch, on a chain with barely any tooling. i said yes before i fully understood what that meant. that's been the pattern.

every role i've had started with: this is too complex, i don't know all of it yet, i'll figure it out. turned out that's actually a strategy. developer relations made sense because i was already the person who had read every doc, broken every integration, and could still explain it calmly to someone who hadn't. it wasn't a career pivot. it was just what i was already doing.

no plan. no networking strategy. just following what was hard and seeing where it went. one thing opened a door. the door led to another one. at some point you stop calling it luck.

what feeds it

curiosity about why people get stuck. not the technical kind of stuck — the kind where the abstraction is wrong and you don't have the words for it yet. the gap between what the docs say and what you actually need to know is where most of my work lives. closing that gap is more interesting to me than the code itself.

clear writing. i've gotten more leverage out of a well-written README than most features i've shipped. a good doc reduces the number of people who have to ask the same question. that compounds. i take it seriously.

the builders i've worked with. every protocol, every integration, every late-night debug session was someone trying to make something real. that part doesn't get old. i take in a lot outside of code too — philosophy, history, systems thinking — and most of what i know about building good software came from understanding people, not compilers.

...

work in progress. intentionally.

— shreyas