
Vector Databases Compared for Production RAG Systems
Evaluate Pinecone, Weaviate, Qdrant, pgvector, and Milvus for your production RAG pipeline. Technical comparison of algorithms, scaling strategies, and cost tradeoffs.
Work
ProjectsCase studies, shipped work, and prototypes.Open SourceGitHub, npm, PyPI, and public packages.Hackathons & CompetitionsHackathons, contests, and rapid-build work.Depth
JourneyCareer timeline, roles, and education.AchievementsScholarships, rankings, and milestones.Courses & CertificationsStructured learning, courses, and credentials.SkillsTechnical capability map.Writing · 02
I write when a problem keeps returning: a slow query, an AI workflow nobody trusts, a codebase that fights its team, or a technical decision that deserves a more honest explanation.
Zero-downtime deploys on a cheap VPS
Field notes
495 published articles. Essays written here open in place; older tutorials take you back to the site where they first appeared.

Evaluate Pinecone, Weaviate, Qdrant, pgvector, and Milvus for your production RAG pipeline. Technical comparison of algorithms, scaling strategies, and cost tradeoffs.
Cloud / DevOpsTrunk-based development, feature flags, and progressive deployment strategies enable teams to ship faster while managing risk. Here's how to structure a CI/CD pipeline that scales with velocity.
Cloud / DevOpsBuild a disaster recovery plan your startup can actually execute. Skip the enterprise theater—focus on backups, failover, and testing that matter.
Cloud / DevOpsEvaluate Pinecone, Weaviate, Qdrant, pgvector, and Milvus for your production RAG pipeline. Technical comparison of algorithms, scaling strategies, and cost tradeoffs.
Web DevMost teams don't have clear standards about what needs review versus what to automate. Real code review standards move fast together—they define what actually matters, who signs off, and how long it takes.
CareerStop drowning in technical debt. Triage it by impact and effort. Learn the framework teams use to prioritize fixes that actually unblock shipping.
Web DevADRs aren't optional. They're how teams preserve architectural context and prevent costly decisions made in isolation.
CareerMost teams that stall between 10 and 20 people blame communication. The real problem is structure. Here's how to scale without velocity death.
CareerA systematic framework for evaluating a startup's technology: assess codebase health, technical debt, key-person risk, scalability, and security—with a structured review process.
Web DevAI systems fail differently. Learn the testing strategies—golden datasets, LLM-as-Judge, prompt regression—that catch what traditional tests miss.
Web DevMost 10-person teams choose microservices and regret it. Here's why a modular monolith often wins—and when distributed systems actually make sense.
CareerMost wikis are stale by design. Learn why pairing beats documentation, shipping beats reading, and how to measure onboarding progress that actually matters.
FinTechA software engineer's guide to algorithmic trading fundamentals: how markets work, why most retail traders fail, and whether this is worth your time.
Web DevLearn how to ship code safely with feature flags. From percentage-based rollouts to kill switches, discover the patterns that separate controlled releases from chaos.
CareerA practical checklist for assessing open-source maintainer health and package reliability before adding it to your dependency tree.
FinTechA practical guide for engineers entering quantitative finance: the math you actually need, Python tooling, backtesting workflows, and when structured learning matters.
FinTechHow a formal certificate in quantitative finance reshaped how I think about uncertainty, causation, and structured problem-solving as a software engineer.
FinTechHow to architect a backtesting engine that avoids common pitfalls: look-ahead bias, slippage blindness, and overfitting. Lessons from building systems that actually predict live trading outcomes.
FinTechFintech's obsession with money creates unforgiving constraints. Learn the five practices that keep billions secure—and how they make any system more reliable.
FinTechAgentic AI is reshaping quant trading research and operations. But real value lies in research automation and human-in-the-loop workflows, not autonomous execution.
FinTechDesign patterns for high-throughput time-series pipelines: from tick ingestion to storage engine selection across TimescaleDB, InfluxDB, and kdb+.
FinTechMost financial engineers optimize for speed before checking if speed matters. Learn when latency actually constrains value and when correctness comes first.
CareerNot an even trim. Cuts follow the accounting shape of the work, not its importance — which is why the reliability team can disappear while a customer-facing feature team barely notices, regardless of which one the company needed more.
FinTechBuilding a portfolio analytics dashboard that survives production requires discipline: choosing which metrics actually matter, balancing real-time against batch, and designing data flows that don't crack under load.
CareerMore than 80% of reorgs fail to deliver what they promised, by the estimate of the people who study them for a living, and companies keep running them anyway. The reason isn't that leaders ignore this. It's that a reorg is solving a different problem than the one it announces.
FinTechGeneric engineers build features. FinTech engineers ship money-moving systems. Here's why regulatory awareness and risk literacy aren't nice-to-haves—they're foundational.
CareerThe label your finance department attaches to engineering isn't a technicality. It decides which budget line gets cut first in a bad quarter, who has to justify headcount every year, and whether a project needs a growth story to get funded at all.
CareerNot in the architecture review. By the time a decision reaches a meeting with a decision on the agenda, the org chart has usually already made it — Conway's Law describes why, and it's older and stranger than the paraphrase you've heard.
CareerTeam Topologies gives platform teams a name for what they're supposed to be — a service, not a favor. Whether that framing helps or quietly makes things worse depends on one thing most platform teams never decide on purpose: their actual interaction mode with the teams they serve.
FinTechA single data error in finance doesn't degrade a model—it corrupts decisions with real money. Why financial data quality demands engineering rigor most other domains ignore.
CareerThe leap from software engineering to a PhD in quantitative finance isn't traditional—but it's increasingly viable. Here's what the path actually looks like.
A working notebook
“Some ideas belong here because they connect directly to projects and services.
Older tutorials still live on Medium, where people first found them. This page keeps the trail intact without pretending everything was published in one place.
How I choose a topic
I would rather publish one useful explanation from lived work than five summaries of things everyone already knows.
Step 01
A topic usually starts as the second or third time the same engineering, product, hiring, or research question lands on my desk.
Step 02
I look for a shipped system, a measured result, a failed approach, or a public artifact that keeps the argument honest.
Step 03
Most technical choices touch something else. The useful links are the ones that help a reader follow that chain without opening fifteen tabs.
Step 04
Some pieces belong on this site; others already have a life elsewhere. I keep the original destination and publishing history intact.
Topics covered
The recurring technical and strategic themes represented across this archive.
A quick orientation
The practical details behind this mixed archive.
Those pieces were published there first. I would rather send you to the original article—with its date, responses, and history—than create a duplicate here.
Thirty-five posts are enough to become noisy. The filters separate original essays from outside tutorials, and permanent page links make it easier to pick up where you left off.
Usually. The essays here tend to connect a technical decision to the project, service, or research context behind it. External posts are often narrower, practical guides.
Please do. Real questions are where the best pieces start. Send the context, what you have already tried, and the part that still feels unclear.
Next step
You do not need a polished brief. A bottleneck, an uncertain architecture decision, or a product idea that refuses to become concrete is enough to start.