Personal showcase Issue 001 on the wire Base season
Appearance

SRIRAM V

the low-friction generalist / software engineer

Useful things,
made to endure.

I work across backend systems, infrastructure, data, databases, Android, and the odd idea that will not leave me alone.

My mission is to build robust, scalable applications and reduce system entropy. I like to understand the inner workings of tools that we take for granted every day. I like to form novel ideas, morph them and apply them to the business. There is never a change made without a reason. Even with AI.

I am serious about my work; every deliverable is an expression of my craft. I consistently meet and exceed expectations. As expected from a Neovim user, by the way.

Professional record / 2023-now

Reducing system entropy
in production.

SDE at Vue.ai, worked across the api-gateway, data pipelines, multi-cloud infrastructure and AI-DLC (a Claude skill with guardrails against agent slop), while driving adoption of our products in the new parent company.

60%more request throughput in internal Locust benchmarks, after refactoring the internal api-gateway and RBAC service.
01

Moving data with opensource ecosystem

Built an Airbyte data ingress and egress connector spanning Delta, SQL, files, and Elasticsearch. It reads the container's cgroup memory limit to size record batches before writing to object store, capped at the cloud provider's recommended upper limit, so it avoids out-of-memory failures.

02

Abstracting repeating complexity

Maintaining and extending capabilities of our internal multi-cloud library - a package supporting operations across AWS, Azure, GCP, OCI and bare metal while preserving full backward compatibility. Used by 8+ services within the company.

03

Research, studies and iteration

POCs laying the foundation for new product capabilities such as data visualization (Superset), observability (Linkerd) and a federated query engine (Trino). Documenting feature benefits, integration cost & complexity, product compatibility and benchmarking.

LanguagesGo · Python · Kotlin · Lua · C · SQL · Bash
PlatformsLinux · Kubernetes · Docker · AWS · GCP · Azure · OCI
Data & operationsKafka · Redis · Delta Lake · Airbyte · Grafana · Argo CD · Keycloak · Trino · Superset · Envoy · Linkerd
ToolsNeovim · tmux · Herdr · Claude Code · Tailscale · Helm Charts
EducationB.Tech, Information Technology · SVCE · 3.9 / 4.0

Exhibit / four specimens

Things I have made.

Expanding the horizon: built with curiosity, lots of educational experiments across different disciplines within tech.

01

Go / network protocol

HTTP server from scratch

HTTP/1.1 built from the RFC 9112 standard: request parsing, response construction, larger-file transfer, and concurrent serving with error handling. Not a single line from net/http is used.

  • Manual TCP connection-per-goroutine handling
  • Efficient parsing of request line, headers and body
  • Supports fixed-length and chunked-encoded responses
  • Response construction and serialization, also covered by Go tests
02

Python / local nltk tooling

revdict

A REPL CLI offering an offline dictionary and reverse dictionary with text auto-complete. Describe your vague thoughts and revdict suggests matching definitions along with sentiment tagging, connotation, confidence, and examples.

  • NLTK WordNet and SentiWordNet, merged with Wiktionary data
  • Native live TUI plus scriptable plain-text output
  • Local embedding/reranking models and indexed search
  • Separate chat interface with LLMs. Supports Anthropic, OpenAI, Gemini and Ollama models
revdict terminal UI searching for closely woven cloth, with percale selected and its definition, sentiment, confidence, stress, and example shown in a preview pane
The TUI: results, preview, filters, confidence, sentiment, and stress in one frame.
03

TypeScript / publishing infrastructure

fwiki

A collaborative, Markdown-native wiki where Git is the database and the moderation system. Pages live in a git repository; saves are commits; revisions are branches; publishing opens a real pull request.

  • Static client with no application server
  • GitHub, GitLab, Gitea/Forgejo, Bitbucket, and local backends
  • Search, history, templates, categories, themes, and responsive layout
  • Conflict recovery and offline-first editing experience

A private repo; the source is not public yet.

Fwiki showing a dark Steins;Gate article with page navigation, editing controls, and an infobox
One content repository, a complete reader and editorial workflow.
04

Kotlin / Android

SAO

Share Arts by Overlay is a native Android application for finding, browsing, saving, and sharing various media through one continuous media carousel. It accompanies you across apps with an unobtrusive floating icon.

  • MVVM, Coroutines, Flow, Retrofit, Coil, and Hilt
  • Unified static and animated-media handling
  • MediaColumns, FileProvider Media3 API integration
  • Features the new Material 3 carousel and work contributed back to google material design
SAO Android application category selection screen Artwork from SAO being shared into Telegram
Scroll, choose, keep, share.
62 public repositories and assorted experiments Browse the less curated shelf

Dispatches / from the shelf

New discoveries,
kept open.

Short notes, useful links, and things I want to remember - properly categorized. A small collection of discoveries across software, systems, career and life outside.

Trace the timeline, follow a thread, or explore the map. Oh, you could also get dispatches delivered to you by RSS (coz mailing lists are just noise).

About / beyond the résumé

A fullstack person,
if you want me to be.

I am the happiest person when the boundaries blur: apps and infrastructure, building features and micro-optimizing APIs, backend and frontend, data and visualization.

Working style 01 / field notes

How I navigate in an unfamiliar land

Handed an unseen tool or service, I learn what it was built for before I judge whether it fits. I test my guesses cheaply and write down what I find so someone else can also decide.

  1. 01Start from what it was built for.History, conference talks, demos; then check that against our actual problem. Changelogs, issue trackers and HN tell me how it fails. For open-source tools these days I read the source code with an LLM alongside (R.I.P. sourcegraph). Then I start thinking about building.
  2. 02Kill assumptions cheaply.One example here: after a lot of proxy configurations, I assumed every query to our federated query layer went through the api-gateway. A few seconds of packet capture in a debug pod said no, so I stopped suspecting the network running on free cloud credits.
  3. 03Separate inherent costs from fixable ones.Costs that come with the workload's nature, I accept. And I chase the fixable ones. I only ever go into micro-optimizations when we're actually adopting the feature.
  4. 04Hand over a decision.I discovered a way to push resource filter construction off the api-gateway. I wrote up what it solves, what integrating it means, and how it can stay optional. Product can decide now.
  5. 05Review AI like a stranger's PR.Does it follow the codebase's practices, reuse what already exists, and survive partial failures? If it feels hacky, it goes back for a revision.

Homelab

Own the machinery.

A headless Ryzen PC for self-hosting, my lab for experiments, and learning what OSS services normally conceal.

Reading

Extremely long stories, plus light novels.

Japanese light novels and web novels, consumed at a volume that occasionally resembles a background service.

Current desk

EndeavourOSFifine K688Womier RD75 ProRyzen 7 7700 64GB/2TBTruthear Zero:REDzero caffeine

End of page / beginning of a connection

Have an interesting
problem?