[{"content":" I burned forty minutes on a refactor claude could\u0026rsquo;ve shipped in four, and the gap wasn\u0026rsquo;t the model. It was everything around it. The casual user types prompts, takes the first suggestion, and treats claude like dressed-up autocomplete. I run it as a programmable agent: persistent memory, custom commands, parallel sessions spawning across worktrees, and a project layout that gets sharper every week I touch it. This guide assumes you\u0026rsquo;ve already typed claude into a terminal and seen what happens. We\u0026rsquo;re going past that…\nNow the fun part.\n1. Claude Code Beyond the Basics Stop treating Claude Code like a prompt-and-wait chatbot. Treat it like an autonomous agent that needs guardrails, and your whole workflow shifts. The core principle from Boris Cherny and the Anthropic team is simple, and it\u0026rsquo;s to give Claude a way to verify its own work. Without that loop, you\u0026rsquo;re the only feedback signal. With it, Claude iterates until the code actually runs. Boris pegs this single move at a 2-3x quality bump.\nA few patterns that shift how you operate day to day.\nExplore, then plan, then code. Hit Shift+Tab twice to drop into plan mode, which is read-only. Let Claude read files, trace flows, map the data model. Get a plan back. Then execute. Skip planning for small fixes. Use it the moment a change touches more than one file.\nTreat plan mode like a design doc. Have one Claude write the plan. Spin up a second Claude in a fresh session and ask it to review the plan as a staff engineer, no context bias, so it actually catches gaps. If the implementation goes sideways, go back to plan mode and re-plan with verification steps baked in.\nReference, don\u0026rsquo;t describe. Skip \u0026ldquo;look at the auth module\u0026rdquo; and type @src/auth/login.py. Skip pasting an error and pipe it instead with cat error.log | claude. Exact context beats approximate description every single time.\nDelegate, don\u0026rsquo;t pair-program. Cat Wu (Claude Code team) puts it plainly: \u0026ldquo;The model performs best if you treat it like an engineer you\u0026rsquo;re delegating to, not a pair programmer you\u0026rsquo;re guiding line by line.\u0026rdquo; Write a crisp brief upfront. Then let it run.\n: Press Ctrl+G to open Claude\u0026rsquo;s plan in your editor and tweak it before Claude proceeds. The plan is just text, so shape it before it becomes code.\n: When Claude makes a mistake, end your prompt with \u0026ldquo;Update CLAUDE.md so you don\u0026rsquo;t repeat this.\u0026rdquo; Boris calls Claude \u0026ldquo;eerily good at writing rules for itself\u0026rdquo; from its own failures. Do note, this one habit compounds harder than anything else in this guide.\n2. The .claude Directory, Properly Understood Most folks crack open .claude/, spot CLAUDE.md, and bounce. It\u0026rsquo;s a layered config system underneath.\nTwo scopes. Project scope sits in .claude/ inside the repo, committed so the team shares it. Global scope sits in ~/.claude/ and rides along on every project on your box.\nMental model. Project files describe the project, global files describe you.\nFile Scope Commit What it does CLAUDE.md Project and global Yes Instructions loaded every session CLAUDE.local.md Project only No, gitignore it Your private project notes settings.json Project and global Yes Permissions, hooks, env vars, model defaults settings.local.json Project only No Personal overrides, auto-gitignored .mcp.json Project only Yes Team-shared MCP servers skills/\u0026lt;name\u0026gt;/SKILL.md Project and global Yes Reusable prompts invoked with /name commands/*.md Project and global Yes Single-file slash commands agents/*.md Project and global Yes Subagent definitions rules/*.md Project and global Yes Topic-scoped instructions, optionally path-gated A typical layout.\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 my-repo/ ├── .claude/ │ ├── settings.json │ ├── agents/ │ │ ├── pr-review.md │ │ └── test-writer.md │ ├── skills/ │ │ └── api-conventions/SKILL.md │ └── rules/ │ ├── frontend.md # path-gated to src/frontend/ │ └── migrations.md # path-gated to db/migrations/ ├── CLAUDE.md # checked in, team-shared ├── CLAUDE.local.md # gitignored, personal └── .mcp.json # team-shared MCP servers A few easy misses.\nCLAUDE.md files cascade. In a monorepo, both root/CLAUDE.md and root/services/billing/CLAUDE.md load while you\u0026rsquo;re working the billing service. Handy when folder conventions diverge.\nrules/*.md is path-gated. Guidance specific to your migrations folder shouldn\u0026rsquo;t bloat every session through CLAUDE.md, rather it belongs in .claude/rules/migrations.md with a glob.\nSkills beat commands. Both .claude/commands/*.md and .claude/skills/\u0026lt;name\u0026gt;/SKILL.md register slash commands, but skills carry supporting files, disable-model-invocation, allowed tools, and agent overrides. I shipped a chunk of repo automation as loose commands/*.md last year and had to port the whole lot to skills/ once supporting files were needed. New work goes in skills/.\n: Run claude project purge ~/path/to/repo --dry-run to see exactly what local state Claude holds for a project, handy before handing off a laptop.\n3. CLAUDE.md, The Way Boris Writes It CLAUDE.md loads at the start of every session. Get it wrong, Claude keeps tripping on the same rake. Get it right, the same prompt suddenly produces output you\u0026rsquo;d actually ship.\nBoris cares about two things here, and the rest is noise once you\u0026rsquo;ve got these down. I spent a month writing increasingly elaborate context files before I came back around to his framing, and the elaborate versions were worse in every measurable way…\nKeep it short. Long files bury the rules that actually matter. For every line you write, run it through Boris\u0026rsquo;s filter and ask, \u0026ldquo;Would removing this cause Claude to make a mistake?\u0026rdquo; If the answer is no, cut it. Be ruthless. The file isn\u0026rsquo;t a knowledge base, it\u0026rsquo;s a guardrail.\nLet Claude write rules for itself. Any time Claude does something wrong, tell it to \u0026ldquo;Update CLAUDE.md so you don\u0026rsquo;t repeat this.\u0026rdquo; Claude is surprisingly good at distilling its own mistakes into precise rules. Do this for a couple of weeks and the file turns into a curated list of every gotcha your project has accumulated, written in the exact phrasing the model responds to. You stop guessing what to put in there because the model tells you.\n3.1 The Real CLAUDE.md From the Claude Code Team In one of his talks, Boris walked through the actual CLAUDE.md the Claude Code team checks into their own repo. The whole team contributes to it multiple times a week.\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 # Development Workflow **Always use `bun`, not `npm`.** # 1. Make changes # 2. Typecheck (fast) bun run typecheck # 3. Run tests bun run test -- -t \u0026#34;test name\u0026#34; # Single suite bun run test:file -- \u0026#34;glob\u0026#34; # Specific files # 4. Lint before committing bun run lint:file -- \u0026#34;file1.ts\u0026#34; bun run lint # 5. Before creating PR bun run lint:claude \u0026amp;\u0026amp; bun run test Read it again. Build commands Claude can\u0026rsquo;t guess, the exact order to run things, single-test invocations, the pre-PR ritual. No style preferences, no codebase tours, no platitudes.\nBoris also uses @claude in PR comments to have Claude commit a rule directly:\n1 2 nit: use a string literal, not a ts enum @claude add to CLAUDE.md to never use enums, always prefer literal unions He calls this \u0026ldquo;Compounding Engineering,\u0026rdquo; where every PR review becomes a CLAUDE.md improvement. The reviewer catches a mistake once, and Claude never repeats it.\nHere\u0026rsquo;s a fleshed-out template following the same philosophy:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 # Code style - Use ES modules (import/export), not CommonJS (require) # Workflow - Always use `bun`, not `npm` - Run `bun run typecheck` before claiming done - Never push to main directly. Always open a PR. # Architecture - All API routes go through src/api/middleware/auth.ts - New database queries go in src/db/queries/. No inline raw SQL. # Gotchas - `User` and `UserRecord` are distinct types. UserRecord is the DB row, User is the runtime object. - `formatCurrency` assumes USD. For international use `formatCurrencyByLocale`. Pay attention to the \u0026ldquo;Gotchas\u0026rdquo; section. Every entry there started as a real mistake Claude made on a real PR, captured the moment it happened. That sinking moment when you realize the model just shipped USD formatting to a French user? You write it down once, and it never happens again.\nSkip these in CLAUDE.md: standard language conventions, file-by-file codebase descriptions, long tutorials, API docs, anything that changes frequently.\n: Words like IMPORTANT or YOU MUST improve adherence. Use them sparingly so they carry weight.\nYou can import other files using @path syntax to keep CLAUDE.md short while pulling in details on demand:\n1 2 See @README.md for project overview and @package.json for scripts. @~/.claude/my-preferences.md Short file, huge payoff. Keep it tight.\n3.2 Popular CLAUDE.md Files Worth Studying Steal from people who\u0026rsquo;ve already done the work. These four are the ones I keep coming back to.\nmattpocock/skills CLAUDE.md : conventions for how skills should be written and tested anthropics/claude-code-action : Anthropic\u0026rsquo;s own repo, treated the same as internal tools awesome-claude-code : links to dozens of public CLAUDE.md files across language ecosystems claudelog.com : community-curated examples organized by stack Read three, then write yours.\n4. CLAUDE.local.md as a Daily Driver CLAUDE.local.md sits next to CLAUDE.md, loads the same way, and never leaves my machine. It goes straight into .gitignore.\nHere\u0026rsquo;s how I run it. After every PR, reviewers drop comments. Instead of trying to hold them in my head, I paste them into CLAUDE.local.md the second I read them. Over a few weeks it turns into a personal rule file tuned to the exact feedback I keep getting.\n1 2 3 4 5 6 7 8 9 10 11 12 13 # Personal review notes (private) # From PR feedback - New SQS consumers need a DLQ and alarms in the same PR - Use `Optional\u0026lt;T\u0026gt;` over null returns - Tests for new endpoints must include the auth-failure case - Prefer named tuples over plain dicts for return types with 3+ fields # My own quirks to correct - Stop using `console.log`; use the project logger instead - Always update the OpenAPI spec when adding endpoints Loaded every session. Claude now includes the auth-failure test and updates the OpenAPI spec without me asking. Nitpick comments on my PRs dropped within two weeks.\n: Keep two sections clearly separated: project-specific feedback and personal habits to correct. Mixing them makes the file harder to prune later.\n: Prune after a few weeks. Anything that\u0026rsquo;s become muscle memory can go. The file should capture what\u0026rsquo;s still in flux; the stuff that runs on autopilot can go.\n5. Skills, In Depth Skills are how you take Claude Code from \u0026ldquo;agent that can do anything\u0026rdquo; to \u0026ldquo;agent that does the three specific things your project actually needs, done the way your team does them.\u0026rdquo; They\u0026rsquo;re the unit of reusable expertise you\u0026rsquo;ll keep reaching for once you\u0026rsquo;ve written one or two\u0026hellip;\n5.1 What Skills Actually Are Last Tuesday I needed Claude to summarize my uncommitted diff the same way every time, so I dropped a folder into ~/.claude/skills/ and walked away. That folder is the skill. Inside lives a SKILL.md carrying frontmatter and instructions, and the folder name itself becomes the slash command you type at the prompt. Project-scoped ones sit under .claude/skills/\u0026lt;name\u0026gt;/, global ones under ~/.claude/skills/\u0026lt;name\u0026gt;/.\nHere\u0026rsquo;s the smallest version that earns its keep:\n1 2 3 4 5 6 7 8 9 10 11 --- description: Summarizes uncommitted changes and flags anything risky. Use when the user asks what changed, wants a commit message, or asks to review their diff. --- ## Current changes !`git diff HEAD` ## Instructions Summarize the changes in two or three bullet points, then list any risks: missing error handling, hardcoded values, tests that need updating. Save that to ~/.claude/skills/summarize-changes/SKILL.md and /summarize-changes shows up in every session you open after.\nThree things that make Skills powerful:\nProgressive disclosure. At session start Claude only reads the frontmatter descriptions, roughly 100 tokens apiece. The full SKILL.md and any helper files don\u0026rsquo;t get pulled in until the skill actually fires. Each skill lives as its own folder, so you can drop a templates/ directory alongside the SKILL.md, stash reference docs next to it, and keep scripts in the same tree. The SKILL.md is just the entry point you hand to Claude. Inline shell. Any line starting with ! runs the command at invocation time and splices the output straight into the prompt. The frontmatter itself carries a good amount of optional knobs:\n1 2 3 4 5 6 7 --- name: my-skill description: When to use this skill disable-model-invocation: true # only runs when user explicitly types /my-skill allowed-tools: Read, Grep, Bash agent: read-only --- : Use disable-model-invocation: true for skills with side effects. You want /ship to deploy only when explicitly typed, not when Claude decides it\u0026rsquo;s relevant.\nSet it once. Forget it forever.\n5.2 Writing a Real Skill: Go API Conventions Here\u0026rsquo;s a complete skill for a Go service team. It carries the conventions, the gotchas, and scaffolding for a fresh HTTP handler.\n1 2 3 4 5 6 .claude/skills/go-handler/ ├── SKILL.md ├── templates/ │ └── handler.go.tmpl └── examples/ └── healthz.go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 --- description: Scaffolds a new HTTP handler in our Go service following team conventions for routing, validation, error handling, and tests. Use when the user asks to add a new endpoint, a new handler, or extend an existing route group. --- # Go HTTP Handler Skill ## Stack - Go 1.22 with chi router - sqlc for typed queries, never write raw SQL strings in handlers - zap for structured logging, never fmt.Println - testify for assertions, table-driven tests preferred ## Gotchas - `chi.URLParam` returns `\u0026#34;\u0026#34;` for missing params, not an error. Always check. - Our `httperr.Wrap` doesn\u0026#39;t log. Log separately with `h.log.Error` before returning. - Auth middleware injects via `context.Value(authkey.User)`. Type-assert to `*models.User`. - sqlc nullable strings use `pgtype.Text`. Check `.Valid` before calling `.String`. - Tests must use `httptest.NewRecorder` and `httptest.NewRequest`. No real server. Do note what\u0026rsquo;s happening here. A new developer can ship a fully conventional endpoint on day one without spelunking through the codebase first.\n5.3 Popular Skills Worth Installing mattpocock/skills is the most popular skills repo, sitting around 100k stars. A few I keep loaded:\n/grill-me: interviews you about a plan before any code gets written /tdd: enforces red-green-refactor strictly /diagnose: disciplined debugging, reproduce, minimize, hypothesize, fix, regression test Install with npx skills@latest add mattpocock/skills.\nJeffallan/claude-skills ships 66 language-specific profiles like go-pro, python-pro, java-architect, typescript-pro, rust-engineer, sql-pro, and more. You compose them. A Next.js task pulls in nextjs-developer alongside typescript-pro.\nAnthropic\u0026rsquo;s official skills:\n/code-review: four parallel agents audit the diff, confidence-scored findings only /simplify: reviews recent code for reuse and efficiency /batch: fans out a migration to dozens of parallel agents, every one isolated in a worktree /webapp-testing: gives Claude Playwright control to test your local web app I used to write the same prompt three times a week before it clicked\u0026hellip;\n: If you do something more than once a day, turn it into a skill. Anything you repeat is a skill waiting to be written.\n: Check skills into git. They become institutional knowledge, and new engineers clone the repo and get the team\u0026rsquo;s accumulated practices for free.\n6. Building Custom Subagents Spin one up and it\u0026rsquo;ll chew through fifty files without bloating your main session, then hand back a tidy summary. Isolated context. Scoped tool permissions. Separate blast radius. I started reaching for them after watching a single debugging session torch my context budget chasing imports across a monorepo, and now I default to them.\nDrop a markdown file into .claude/agents/ for project scope, or ~/.claude/agents/ if you want it globally available. The frontmatter declares name, description, tools, and model. Five lines, full contract.\n6.1 Walking Through a /pr-review Agent Last Friday I almost shipped a PR with a missing null check, and that\u0026rsquo;s when I built this agent.\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 --- name: pr-review description: Reviews the current branch diff against main, looking for bugs, security issues, missed edge cases, and project-convention violations. Use proactively before opening a PR. tools: Read, Grep, Glob, Bash model: opus --- You are a senior staff engineer reviewing a pull request. Thorough, direct, goal is to catch issues before human reviewers do. ## Process 1. Run `git diff main...HEAD` 2. Run `git log main..HEAD --oneline` 3. Read full files, not just diff context 4. Cross-check against CLAUDE.md, CLAUDE.local.md, and .claude/rules/ ## Flag - Correctness bugs: off-by-one, null handling, error paths, race conditions - Security: injection risks, missing auth checks, secrets in code - Missing tests for new logic - N+1 queries - Convention violations from CLAUDE.md or rules/ ## Do NOT flag - Style preferences not in project rules - Refactoring suggestions for working code - Anything outside this diff ## Output Group by severity (Critical / High / Medium / Low). File + line + issue + suggested fix. End with a verdict: **SHIP**, **FIX FIRST**, or **REWORK**. I trigger it by typing Have the pr-review agent look at my current branch. into the session. The subagent does its work in an isolated context, and my main session doesn\u0026rsquo;t get cluttered with review chatter.\nA few choices worth calling out. The tools list is deliberately read-only, since a reviewer that can patch code starts rationalizing its own fixes instead of flagging them. I picked model: opus because catching a security bug before a human reviewer does is worth the cost. By the way, the \u0026ldquo;Do NOT flag\u0026rdquo; section is what actually makes the output usable. Without it I\u0026rsquo;d drown in nitpicks about variable naming.\nBuilt it in ten minutes. Saved me twice already.\n6.2 Popular Subagents Worth Stealing Straight from the Claude Code team\u0026rsquo;s own workflow, you\u0026rsquo;ll find build-validator, code-architect, code-simplifier, oncall-guide, and verify-app running daily.\nHere\u0026rsquo;s what the community keeps reaching for\u0026hellip;\nAgent What it does security-reviewer injection, auth, secrets, insecure deserialization test-writer generates tests, pairs with code-reviewer in a loop debugger traces failing tests to root causes performance-auditor profiles flows and queries migration-writer generates DB migrations matching project conventions release-notes-writer changelogs from commit history If you want curated collections, VoltAgent/awesome-claude-code-subagents ships with over 100 agents, and hesreallyhim/a-list-of-claude-code-agents curates another solid set.\n: Chain agents: Session A implements, then call Use the code-reviewer subagent to check the work. The reviewer evaluates in a fresh context with no implementation bias.\n: Add isolation: worktree to frontmatter to run the subagent in its own git worktree, especially powerful when fanning out a migration across dozens of parallel agents.\nSteal the patterns today, and tomorrow you\u0026rsquo;ll wonder how you ever shipped without them.\n7. Plugins and the Marketplace Plugins bundle skills, hooks, subagents, and MCP servers into one installable unit. Run /plugin to open the marketplace browser. Add community marketplaces with /plugin marketplace add owner/repo.\nDay-one installs:\n/code-review fires four agents in parallel. Two check CLAUDE.md compliance. One hunts bugs. One reads git blame for context. Output is confidence-scored. Signal stays high, noise stays low.\n/feature-dev is the most-installed skill on the official marketplace. Hand it a feature brief, get working code. Seven phases. Requirements, exploration, architecture, implementation, testing, review, docs.\nLanguage server plugin wires symbol-level navigation and on-edit diagnostics straight into your session. The team consistently flags it as the highest-leverage plugin you can install.\n/security-guidance is Anthropic\u0026rsquo;s official security skill. Surfaces concerns before they ship.\nPlugin categories worth knowing (1,000+ plugins across 75+ marketplaces as of mid-2026):\nGit workflow, code intelligence (LSP), documentation generators, testing, browser automation (Playwright), design system (Figma), observability (Sentry, Datadog) : A team-shared .mcp.json together with a few well-chosen plugins gets a new engineer productive within minutes of cloning the repo. Treat plugin choices as part of your onboarding story.\n8. Underused Claude Code Commands Most folks learn /clear, /compact, and /init, then stop exploring. The rest of the command surface is where the real productivity hides, and barely anyone touches it.\nCommand What it does /insights Analyzes your usage patterns; run once a month /compact \u0026lt;hint\u0026gt; Compresses session; hint controls what survives /copy Copies last response; interactive picker for code blocks /rewind Undo for your whole session, restoring code, conversation, or both /btw Side question that never enters conversation history /context Visualizes context usage /export \u0026lt;file\u0026gt; Dumps conversation to file /branch Forks your session to try something risky /batch Fans work out to parallel agents across worktrees /loop \u0026lt;interval\u0026gt; Schedules Claude to run on repeat, up to 3 days /schedule Cloud version of /loop, works even when your laptop is closed /teleport Moves a session between terminal and web /focus Hides intermediate tool calls, shows only final result /voice Voice input; Boris says he codes mostly by speaking --bare Up to 10x faster startup for non-interactive claude -p usage Let\u0026rsquo;s dig deeper into the two that I reach for daily…\n/compact vs /clear: if you\u0026rsquo;re starting a genuinely new task, hit /clear and write a fresh brief by hand. If the next task still leans on what you just did, run /compact with a hint about what should survive. /compact is a lossy LLM summary of the session. /clear is your own brief, written deliberately. I confused these for weeks and wondered why my sessions kept drifting. Once that distinction clicked, my context stayed cleaner for hours at a stretch.\n/rewind drops a checkpoint at every prompt, and those checkpoints stick around across sessions. So when Claude wanders down a wrong path, resist the urge to type \u0026ldquo;that didn\u0026rsquo;t work, try X.\u0026rdquo; Typing that just buries the bad attempt inside your context and the model keeps tripping over it. Rewind to before the mistake, then re-prompt with whatever you learned from watching it fail. Your context window will thank you.\n: Use ! as a shell escape. !git status or !npm test runs immediately with output landing in context.\n: Set CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000. Context rot kicks in around 300-400k tokens on the 1M model, so force earlier compaction to stay sharp.\nFan-out pattern: write the task list first, then loop over it. I migrated about two thousand component files this way last quarter. Generate the list, sanity-check three of them by hand, tighten the prompt until those three come back clean, then unleash it on the rest while you go get coffee.\n1 2 3 4 5 for file in $(cat files.txt); do claude -p \u0026#34;Migrate $file from React to Vue. Return OK or FAIL.\u0026#34; \\ --allowedTools \u0026#34;Edit,Bash(git commit *)\u0026#34; \\ --bare done 8.1 /goal, the Ralph Loop Built In Last Tuesday I typed one line, closed the laptop, ate dinner, came back to a green PR. /goal sets a completion condition, and Claude keeps grinding until that condition holds true. Every attempt to stop triggers a check against the transcript.\n1 /goal all tests in test/auth pass and the lint step is clean Real examples:\n1 2 3 4 /goal all integration tests in tests/api pass without flaking 3 runs in a row /goal the OpenAPI spec validates and matches the actual response shapes /goal docker compose up runs cleanly and the healthcheck endpoint returns 200 /goal coverage on src/billing/ is above 80% and all new tests are not placeholders Pick something verifiable and deterministic. Tie it to a test command, a CLI exit code, or some file state you can grep for. Write \u0026ldquo;the code is good\u0026rdquo; and you\u0026rsquo;ve already lost\u0026hellip;\nCompanions that pair well:\n/loop: repeat at an interval, burn down a backlog /schedule: run on a cadence in the cloud A Stop hook: gate on your own test suite or CI endpoint Auto mode: removes permission prompts so long goals don\u0026rsquo;t stall : Combine /goal + auto mode + /focus. Write a crisp brief, set the goal, walk away. Come back to a finished PR. This is the workflow Boris and Cat Wu push for Opus 4.7.\n9. MCPs as Power Tools MCP (Model Context Protocol) is the wire that turns Claude Code from a coding agent into a system-aware one. An MCP server exposes external tools (a database, a design canvas, your error tracker, your notes) to Claude through a standard contract, so the agent can call them like any other tool.\nWithout MCP, Claude reads files and runs commands. With MCP, it reads your Linear tickets, queries your Postgres, pulls up a Figma component, fetches live Sentry stack traces, or reads your Obsidian vault, all without you leaving the terminal.\nThe go-to MCPs for engineering work:\nMCP What it unlocks GitHub Repo management, PRs, issues, code search Context7 Live, up-to-date library docs; append use context7 to any prompt Sentry Real error context, stack traces, breadcrumbs Linear Read/create tickets, update status Playwright Browser automation via accessibility snapshots Figma Live design tree: auto-layout, spacing tokens, component refs Postgres / Supabase Query your dev DB directly Slack Read threads, summarize discussions, draft responses Local servers talk over stdio, vendor-hosted ones speak HTTP with OAuth:\n1 claude mcp add --transport http sentry https://mcp.sentry.dev/mcp Team-shared MCPs land in .mcp.json at the project root. Personal ones live in ~/.claude.json. Once it\u0026rsquo;s wired, the next prompt you write stops being about your repo and starts being about your whole stack.\n9.1 A Real Obsidian Workflow Obsidian and Claude Code click when you treat the vault as three tiers of memory. Skip that framing and you\u0026rsquo;re back to \u0026ldquo;Claude can read my files,\u0026rdquo; which misses the point.\nSetup: Install obsidian-claude-code-mcp in Obsidian. It exposes the vault over a local WebSocket on port 22360, and Claude Code finds it on its own. Drop a CLAUDE.md at the vault root so the agent knows your folder layout.\nFolder structure:\n1 2 3 4 5 6 7 8 9 10 11 vault/ ├── 00-Inbox/ # raw capture ├── 10-Daily/ # one note per day ├── 20-Projects/ # active project notes │ └── billing-v2/ │ ├── README.md # goal, status, open questions │ ├── decisions/ # ADRs │ └── sessions/ # one log per Claude session ├── 30-Decisions/ # cross-project ADRs ├── 40-Atoms/ # reusable knowledge, linked └── 90-Archive/ The three tiers:\nHot storage: daily session log. Every session I run writes a timestamped entry into 10-Daily/\u0026lt;today\u0026gt;.md. I wire a Stop hook so the append happens when the session ends. No copy paste.\nWarm storage: project notes. Each project lives under 20-Projects/. When I start a session, Claude reads the project README and the last two or three session logs before touching anything. Two weeks of context rehydrated in about 30 seconds.\nCold storage: decisions and atoms. Architectural calls get promoted into 30-Decisions/ as ADRs once they\u0026rsquo;ve stuck. Reusable knowledge gets distilled down into 40-Atoms/ with wikilinks so the same fact threads across every project that needs it.\nDaily workflows:\nWhat is in my inbox? Summarize and suggest where each item belongs. Check 30-Decisions/ for anything related to retry policies. Read the last 3 session logs for billing-v2. Tell me where I left off. : Resist installing every MCP. Each one expands the tool list Claude reasons over, and bloated tool lists hurt decision quality. Starter set: GitHub, Context7, and one or two domain-specific.\n: Run /mcp inside Claude Code to list every active server and its connection status. First place to check when something isn\u0026rsquo;t working.\n10. Optimizing Your Daily Workflow Morning. Open Claude Code in the project. Skim whatever the subagents and scheduled jobs churned through overnight. Once a week, run /insights and actually read it.\nNew feature. Start in plan mode, then edit the plan with Ctrl+G until it matches your head. Implement. Either invoke the /pr-review subagent or fire up a fresh Claude session to tear it apart.\nBug. Reproduce it before you touch anything. Pipe the error in with cat error.log | claude and ask Claude to write a failing test that reproduces the bug. Only after that test goes red do you ask for a fix. Skip this step and the fix is just a guess wearing a suit.\nMigrations or mass changes. Reach for /batch. It interviews you about what you actually want, then fans out to parallel agents, each in its own worktree, each running tests and opening its own PR. You become a reviewer instead of a typist.\nUnfamiliar code. Hand it to a subagent. Something like, \u0026ldquo;Use a subagent to investigate how our auth handles token refresh.\u0026rdquo; It chews through dozens of files inside its own context window and reports back with a tidy summary. Your main session stays uncluttered, which matters more than people realise once they\u0026rsquo;ve burned a 200k token window on spelunking.\nParallel sessions. Boris and the team call this the single biggest productivity unlock, and I agree only after kicking against it for a week. Three to five git worktrees, each running its own Claude session. Use the agent view (claude agents) as a control plane so you can see who\u0026rsquo;s doing what without alt-tabbing through six terminals.\nWriter/Reviewer pattern. Session A implements the change. Session B reviews it in a completely fresh context, no prior conversation baggage. Copy the review back into Session A, fix, repeat until Session B stops complaining.\nCompact at milestones. After you finish a logical chunk, run /compact Preserve the decisions made, files changed, and test commands. Do it before the context gets soupy, do it kindly, do it often.\n: Never let Claude claim success without evidence, whether that\u0026rsquo;s tests, screenshots, or real command output. The trust-then-verify gap is the single biggest source of bad output.\n11. Tips From the Anthropic Team The difference between people who get Claude and people who fight it comes down to maybe a dozen habits. Here\u0026rsquo;s what Boris, Cat Wu, Thariq, and the rest of the team actually do day to day\u0026hellip;\n\u0026ldquo;Give Claude a way to verify its output. Once you do that, Claude will iterate until the result is great.\u0026rdquo; Boris\u0026rsquo;s single most-repeated point.\nUse Opus with high or xhigh effort for almost everything. A smaller model that needs more correction ends up slower overall. That\u0026rsquo;s why Boris defaults to Opus.\nRun 3-5 sessions in parallel. Worktrees beat checkouts. Use claude --worktree or the Desktop app. The agent view ties them together.\nKeep a notes directory per project, updated after every PR. Tell Claude to write notes into a directory and point CLAUDE.md at it. Your codebase compounds in self-knowledge.\nBuild a /techdebt slash command. Run it at the end of every session to find and kill duplicated code.\nThe team\u0026rsquo;s CLAUDE.md is shared and edited multiple times a week. Whenever someone watches Claude get something wrong, they add a rule. Treat it as a living document.\nEsc twice opens rewind. Pair it with checkpoints, try something risky, find out it failed, rewind cleanly.\nFor UI changes, set up Playwright MCP. Boris reaches for the Chrome extension every time he touches web code. Claude opens a browser, clicks around, and verifies the result.\nInstall a language server plugin. You\u0026rsquo;ll catch type errors and unused imports after every edit. Highest-impact plugin you can install.\nUse /voice for prompting. You speak 3x faster than you type, and your prompts get way more detailed once you do.\nAuto mode + /focus + /goal. Write a crisp brief, set the goal, walk away. Come back to a finished PR.\nUse Ctrl+G to edit Claude\u0026rsquo;s plan in your editor before implementation. Faster than typing corrections into the chat.\nAsk Claude to draw ASCII diagrams of new protocols and codebases. Boris\u0026rsquo;s trick for understanding unfamiliar code fast.\n12. Resources Official docs\nClaude Code documentation Explore the .claude directory Best practices for Claude Code Memory (CLAUDE.md, rules, auto memory) Skills · Subagents · Plugins · MCP · Hooks Boris and the team\nHow Boris Uses Claude Code : 89+ s straight from the creator, pulled from his X threads Anthropic blog: Best practices for Opus 4.7 with Claude Code shanraisshan/claude-code-best-practice Skills\nmattpocock/skills : \u0026ldquo;Skills for Real Engineers\u0026rdquo; Jeffallan/claude-skills : 66 language-specific skills addyosmani/web-quality-skills : web performance and quality Anthropic skills cookbook Subagents\nVoltAgent/awesome-claude-code-subagents : 100+ sorted by category hesreallyhim/a-list-of-claude-code-agents Plugins and marketplaces\nChat2AnyLLM/awesome-claude-plugins : 1000+ plugins across 75+ marketplaces claudemarketplaces.com MCPs\nObsidian Claude Code MCP plugin Official MCP servers list claude.com/partners/mcp Closing Notes Claude Code clicked for me once I quit treating it like ChatGPT in a terminal. The mental model flipped from \u0026ldquo;I need to write this code\u0026rdquo; to \u0026ldquo;I need to set Claude up to write this code well.\u0026rdquo; Setup is the work. Execution is verification.\nA few things that have genuinely changed how I work:\nCLAUDE.md is compounding infrastructure. Every mistake Claude makes is a rule waiting to be written. After a few weeks of \u0026ldquo;update CLAUDE.md so you don\u0026rsquo;t repeat this,\u0026rdquo; the same prompts produce dramatically better output.\nCLAUDE.local.md captures PR feedback. Your reviewers are handing you free training data. Convert recurring comments into rules. Let Claude apply them next round.\nSkills are the unit of reusable expertise. If you\u0026rsquo;ve prompted the same instructions twice, you\u0026rsquo;ve got a skill waiting to be written.\nSubagents over kitchen-sink prompts. Separate the concerns, keep each context clean, and per-task quality goes up.\nParallel sessions are the unlock everyone underestimates. Three Claudes in three worktrees is a different kind of force multiplier. Try it for a day.\nMost people stop at the prompts. The real value sits past that, in the directory layout, skills, subagents, plugins, and MCPs. You train it, configure it, operate it. The output tracks the configuration.\nThese are my personal takeaways from how I\u0026rsquo;ve used Claude Code day to day, so your setup and mileage will look different. If you spot something off or have a sharper way to do any of this, feel free to reach out, I\u0026rsquo;d love to hear it :)\nClaude Code icon by LobeHub, used under the Apache 2.0 license.\n","permalink":"https://arps18.github.io/posts/claude-code-mastery/","summary":"A deep dive into Claude Code for daily users. Covers the .claude directory, CLAUDE.md the way Boris writes it, CLAUDE.local.md, Skills with real examples, custom subagents, plugins, underused commands like /goal and /insights, MCPs, and the workflow patterns the Anthropic team actually uses.","title":"Beyond the Prompt: Claude Code"},{"content":"You push a feature branch on Friday, and Monday morning the history looks like someone shuffled a deck of cards into it.\nThat\u0026rsquo;s when Git stops being a git commit + git push reflex and turns into something you actually sit with. A few months in, the commands aren\u0026rsquo;t what trip you up. The hard part is reading why the history landed the way it did, and knowing what to reach for when it tips sideways. Here\u0026rsquo;s what I\u0026rsquo;ve picked up.\n1. Understanding Git Internals Each commit holds a pointer to the full file tree at that moment and a pointer to its parent, chaining all the way back to the repo\u0026rsquo;s first commit. Diffs get computed on demand when you ask for them. HEAD points to wherever you currently are, and your working copy is derived from it. A branch label is a pointer to a commit SHA, so moving the label doesn\u0026rsquo;t touch any underlying objects.\nreflog is the one you\u0026rsquo;re probably underusing. Every time HEAD moves (commit, reset, checkout, rebase), Git writes an entry. Your stomach drops when a force-push wipes a ref you actually wanted, and reflog is why that isn\u0026rsquo;t a disaster. It\u0026rsquo;s local and never pushes anywhere, so the recovery window only exists on the machine that did the damage.\nSay you\u0026rsquo;ve committed D to feature when you meant main. cherry-pick replays the diff introduced by a specific commit onto wherever HEAD points now.\n1 2 3 D (HEAD -\u0026gt; feature) / A - B - C (main) 1 2 3 git checkout main git cherry-pick D git branch -d feature D lands on main as a brand new commit with a brand new SHA, while the original D on feature becomes unreachable and eventually gets garbage-collected. Commits don\u0026rsquo;t move; they get replayed as new objects with new identities…\nOnce that clicks, rebase, revert, and squash all stop looking like separate features and start looking like variations on the same replay primitive.\n2. Cleaning Up History 2.1 Interactive Rebase Five commits in and the feature still isn\u0026rsquo;t done. You\u0026rsquo;ve got \u0026ldquo;Fix login typo\u0026rdquo;, \u0026ldquo;Remove debug prints\u0026rdquo;, \u0026ldquo;Refactor login\u0026rdquo;, a pile of breadcrumbs from actually working through the problem. Reviewers don\u0026rsquo;t need any of it.\n1 git rebase -i HEAD~5 An editor opens:\n1 2 3 4 5 pick abc123 Add login function pick def456 Fix login typo pick ghi789 Add error handling pick jkl012 Refactor login pick mno345 Remove debug prints Change pick to squash and the commit folds into the one above it. Change it to drop and the commit disappears. Squash into the wrong base and you\u0026rsquo;re reaching for reflog to get out.\nAfter a squash, five commits collapse to one:\n1 2 Before Rebase: A - B - C - D - E 1 2 After Rebase (squashed): A - B - X X combines D and E into one commit. What lands in the PR is:\n1 Add login feature with error handling 2.2 Commit Amend You committed login.py and then noticed auth.py sitting there unstaged. Amend the first commit instead of stacking a second one:\n1 2 git add forgotten_file.py git commit --amend The previous commit gets rewritten to include the new changes. Fine locally. Once the branch is pushed, amending rewrites history, so a force push becomes necessary and your teammates\u0026rsquo; local branches now point to a commit that no longer exists on the remote.\n2.3 Reflog You run git reset --hard HEAD~3 and three commits vanish from git log.\nMost engineers read that as deletion. It isn\u0026rsquo;t. reset --hard only moves HEAD, and Git keeps the orphaned commits reachable through reflog until garbage collection runs (default 30 days for unreachable objects, 90 for reflog entries), which means every position HEAD has ever held is recoverable by SHA.\n1 git reflog Output:\n1 2 3 abc123 HEAD@{0}: reset: moving to HEAD~3 def456 HEAD@{1}: commit: added feature ghi789 HEAD@{2}: commit: initial commit def456 is right there. Grab it.\n1 git reset --hard def456 Commits are back.\n3. Branching and Collaboration 3.1 Feature Branch Workflow Two engineers committing to main at the same time is how you get a repo that neither of them recognizes by end of day. Branching isolates a unit of work behind its own ref so it can evolve without disturbing anything else on the trunk.\n1 2 3 4 git checkout -b feature/login # develop the login feature git commit -m \u0026#34;Add login\u0026#34; git push origin feature/login When it\u0026rsquo;s ready, you fold it back in:\n1 2 git checkout main git merge feature/login The picture looks something like this:\n1 2 3 4 main | |---- feature/login |---- feature/payment feature/payment never has to wait on feature/login. Each branch carries its own commit history from the point it diverged, so a commit on one branch doesn\u0026rsquo;t appear on the other until a merge actually integrates them. Reviewers benefit from the same property, because a PR against main covers one concern instead of a pile of unrelated changes arriving together.\n3.2 Rebase vs Merge You cut a branch off main, work on it for two days, and by the time you\u0026rsquo;re ready to merge, three other commits have landed on main. Now you\u0026rsquo;ve got to integrate those changes somehow.\nTwo options, and they produce very different histories.\nMerge keeps the timeline honest. It records exactly when things happened and drops in a merge commit to stitch the two branches together.\n1 2 3 4 5 6 Merge: A - B - C (main) \\ D - E (feature) \\ M (merge commit) Rebase replays your commits as if you\u0026rsquo;d started from the tip of main all along. Linear and clean, though those commits are new objects now; D' and E' aren\u0026rsquo;t the same as D and E. Same diff, different SHAs, different parents. That\u0026rsquo;s the part people miss until it bites them.\n1 2 Rebase: A - B - C - D\u0026#39; - E\u0026#39; (main) That rewrite is what makes rebase dangerous on shared branches. If a teammate based their work on your D and you rebase, their D becomes an orphan commit and their history diverges from yours in a way that\u0026rsquo;s painful to untangle later.\nSo the rule I follow: never rebase a public shared branch. Use rebase on your own private branch before you merge it back, and use merge for everything that other people are pulling from. No exceptions.\n1 2 git checkout feature/login git rebase main 4. Recovery and Debugging 4.1 Git Bisect I had a regression sitting somewhere in 500 commits between the last green release and HEAD, and no theory about which one did it. git bisect runs a binary search through that history. You mark where good ends and bad begins, Git checks out the middle commit, you run the repro and tell it which side of the split that commit sits on, then it halves the window again. 500 commits collapses into about 9 steps.\nHere\u0026rsquo;s where people quietly wreck their own bisect sessions. If you mark a commit good or bad without actually running the repro, bisect will happily converge on an innocent SHA, and you won\u0026rsquo;t notice anything was off until you\u0026rsquo;ve already shipped a bogus fix. The log is only as trustworthy as the verdicts you feed it, so run the real test every step. Bisect lands you on a single SHA, the one that introduced the regression. The commit itself.\nStart it like this…\n1 2 3 git bisect start git bisect bad git bisect good abc123 Run the repro. Mark it. Repeat.\n4.2 Git Blame Blame\u0026rsquo;s job is reconstructing why a line exists. When the test suite tells you something is broken, blame tells you who decided it should look the way it does.\n1 git blame auth.py Every line comes back annotated with who touched it last and which commit it came from. The word \u0026ldquo;last\u0026rdquo; in that output does a good amount of work, because if someone reformatted the file six months ago, blame will point at them and skip right past the person who actually wrote the logic. Treat blame output as a lead. The commit it points at might just be the formatter, with the actual decision-maker buried two reformats deep.\nSpot a weird conditional and run blame to get the commit hash. Then git show \u0026lt;hash\u0026gt; gives you the full diff and message around why that decision landed.\n4.3 Recover Deleted Branch 1 2 3 git reflog # find commit hash git checkout -b recovered \u0026lt;commit_hash\u0026gt; Deleting a branch only removes its pointer; the underlying commit objects stay in the store. Garbage collection won\u0026rsquo;t touch them for weeks by default, so your recovery window is wide open.\nreflog tracks every position HEAD has occupied locally. Find the hash from just before the deletion and check it out as a fresh branch. Most \u0026ldquo;destructive\u0026rdquo; Git operations aren\u0026rsquo;t actually destructive.\nThe branch is back.\n5. Stash and Worktrees 5.1 Git Stash Halfway through a login feature. Auth flow wired up, session logic half-done, then production throws an alert and you need main right now. Can\u0026rsquo;t commit half-baked code, can\u0026rsquo;t leave it either.\n1 2 3 4 5 6 git stash save \u0026#34;WIP login feature\u0026#34; git switch main # fix hotfix git commit -m \u0026#34;Hotfix\u0026#34; git switch feature/login git stash pop git stash parks your working tree on a temporary shelf. The tree goes clean, you jump to main, patch the fire, come back, and stash pop drops the WIP right where you left it. I got this wrong the first time and stashed without a message, then burned ten minutes guessing which stash held the auth work.\nStashes stay local. They don\u0026rsquo;t travel with the repo, so don\u0026rsquo;t treat them as backup.\n5.2 Git Worktrees The stash-and-switch loop falls apart once you\u0026rsquo;re juggling a half-finished refactor and somebody pings you to check a deploy config on main. Shelving messy work just to peek at another branch wastes minutes you don\u0026rsquo;t have.\ngit worktree checks out multiple working trees from the same repo at once. The feature branch sits in one folder, the hotfix sits in another, and a change in one folder is invisible from the other because the working copies are fully independent.\n1 git worktree add ../hotfix main This isn\u0026rsquo;t a branch switch under the hood. The object store (commits, blobs, refs) is shared across every worktree, while the checked-out files live in separate directories with separate HEAD pointers. One cd away from main, zero stashing, no context loss when an interrupt lands mid-refactor.\n5.3 Sparse Checkout Two files in frontend/ need a tweak, but Git pulls the whole monorepo, indexes every directory, and floods git status with churn from services you\u0026rsquo;ve never opened.\n1 2 git sparse-checkout init git sparse-checkout set frontend/ Only frontend/ lands on disk. Everything else stays in the object store, invisible to your working tree, so clones go faster and status output narrows down to code you actually touch. Pair this with worktrees once your monorepo crosses a few gigabytes, and the day you\u0026rsquo;d normally spend wrestling Git turns into a day you spend writing code.\n6. Cherry-Pick You\u0026rsquo;d been heads-down on feature/login for a week when someone shipped a critical auth fix to main. Two lines. Waiting for the eventual merge wasn\u0026rsquo;t an option; you wanted those two lines on your branch immediately.\ncherry-pick does exactly that.\n1 2 git checkout feature/login git cherry-pick \u0026lt;commit_hash\u0026gt; It doesn\u0026rsquo;t pull in the branch; it just replays the diff from that one commit onto wherever HEAD points, so you get the fix and nothing else. The commit hash on your branch ends up different, though the change itself is identical.\nLet\u0026rsquo;s dig deeper into the failure mode… if that commit touched a file you\u0026rsquo;ve also modified, you\u0026rsquo;ll hit a conflict. Resolution works like a merge conflict, except it tends to catch you off guard because you weren\u0026rsquo;t expecting friction from a single-commit operation.\nKeep your commits small and focused. cherry-pick replays one commit at a time, so a tightly-scoped commit transplants cleanly while a sprawling one drags unrelated changes along with the fix.\n7. Hooks and Automation Git fires hooks at well-defined lifecycle points; the two that matter most for guardrails are pre-commit and pre-push. The scripts sit in .git/hooks/ as plain shell, executable bit and all, so you can write them in whatever you\u0026rsquo;d write a shell script in.\npre-commit runs before Git writes the commit object. pre-push is its counterpart on the outbound side, gating whatever\u0026rsquo;s about to leave your machine. If either exits non-zero Git aborts, no commit object gets written and no ref gets updated, so the exit code is the entire contract you\u0026rsquo;re working against.\nOne gotcha worth internalizing before you ship a hook to your team. pre-commit sees the staged index, which can diverge from your working tree if you\u0026rsquo;ve staged half a file and left the rest dirty. Your tests run green against the staged version, you commit, you push, and the code you actually have on disk is something else entirely… the workaround is to stash unstaged changes inside the hook itself, run your checks against a clean index, and pop the stash on the way out. It\u0026rsquo;s ugly but it\u0026rsquo;s the only honest way to test what you\u0026rsquo;re really committing.\nHooks aren\u0026rsquo;t tracked by Git, which means a fresh clone has none of them. Check yours into scripts/hooks/ and have your setup script symlink them into .git/hooks/ so every contributor inherits the same guardrails on day one. Then drop something like this into .git/hooks/pre-commit:\n1 2 #!/bin/sh npm test || exit 1 8. Force Push Safely I finished a clean rebase, history finally reading top to bottom like a real story, and then git push came back with the diverged-branch error. My first instinct was --force, ship it, move on. That instinct is how teammates lose a morning of work.\nPlain --force doesn\u0026rsquo;t consult the remote at all. It steamrolls whatever\u0026rsquo;s sitting there, so if a teammate pushed a commit after your last fetch, their work is gone with no warning, silently overwritten while you sip your coffee. You won\u0026rsquo;t even know until someone pings you the next morning asking where their changes went.\nSit with that for a second, because it isn\u0026rsquo;t hypothetical. Teams have lost hours this way, and the person who force-pushed usually has no idea it happened. The push succeeds, everything looks fine on their end, and the damage only surfaces when someone else notices their commit missing from the remote.\n--force-with-lease checks whether the remote ref still matches what you last saw locally, so if a teammate snuck a push in while you were rebasing, your push fails loudly at the protocol level. That\u0026rsquo;s exactly what you want when you\u0026rsquo;re rewriting shared history. You still get the rewrite, you just don\u0026rsquo;t bulldoze anyone on the way there.\nDo note: plain --force skips that safety check entirely.\n1 git push --force-with-lease Use it by default.\n9. Diff and Log Magic --word-diff operates at the token level instead of the line level, so a one-character rename stops drowning in red and green noise. You see [-old-] replaced by {+new+} inline, and once you\u0026rsquo;ve seen a variable rename or a condition tweak land this way, line-level diffs lose the precision they used to have.\n1 2 3 git diff --word-diff # shows changes at the word level git diff main..feature # compare branches git log --graph --oneline --decorate --all # visualize commit graph git diff main..feature isn\u0026rsquo;t symmetric. Flip the order and you\u0026rsquo;ll get a different diff, and it\u0026rsquo;s a silent one to get wrong.\nStack --graph --oneline --decorate --all and the branch topology finally shows up on screen. No more guessing branch shape from PR titles or scrolling through linear logs that hide merges. One readable picture. The next time someone asks how a feature actually landed on main, the answer\u0026rsquo;s already on your terminal before they finish the question.\n10. Daily Professional Workflow Every morning, before touching a single file, run git fetch origin to sync your local view of what the remote actually looks like. Then git rebase origin/main on whatever feature branch you\u0026rsquo;re on. Do this religiously.\nAfter that, just work. Commit often and commit messily if you need to, because you\u0026rsquo;ll squash it later anyway. The point is to not lose context while you\u0026rsquo;re in the flow.\nBefore you open the PR, rebase interactively and clean up the history. Squash the wip commits, reword anything embarrassing, and make the diff tell a coherent story. Reviewers read history too.\nPush with --force-with-lease; reserve plain --force for situations where you\u0026rsquo;ve verified no one else has touched the branch. Never --force on a shared branch itself. Plain --force will silently overwrite a teammate\u0026rsquo;s commit if they pushed after your last fetch, whereas --force-with-lease refuses the push and aborts with a stale-ref error.\nOpen the PR, wait for review, merge, and clean up. Same loop tomorrow.\nClosing Notes reset --hard on the wrong branch is how Git actually clicks for most people. You read the docs, nod along, and then one day every command you half-remembered becomes very real, very urgent.\nThe commands here aren\u0026rsquo;t a checklist to memorize. git bisect won\u0026rsquo;t come up every week, but when a subtle bug is hiding somewhere in the last eighty commits, you\u0026rsquo;ll be glad you know it. Worktrees sound niche until you\u0026rsquo;re mid-refactor and a critical fix lands in your lap.\nWrite commit messages like you\u0026rsquo;re explaining them to yourself six months from now. Fix null pointer in auth middleware when session token is missing saves a full context reload, while Fix bug saves nothing. Spend the extra fifteen seconds.\nRebase before every PR, because a clean linear history keeps git log readable and makes reviewing faster, and while you\u0026rsquo;re at it, stop treating your local branch history as sacred. Use rebase -i to squash the typo commits, reorder the logical chunks, and drop the dead ends before it becomes someone else\u0026rsquo;s problem to review. By the way, the first time I taught myself this workflow I rebased a shared branch and force-pushed over a teammate\u0026rsquo;s commit at 11pm. I got this wrong in the loudest possible way, and that\u0026rsquo;s when --force-with-lease became muscle memory.\ngit reflog is your undo history. Git almost never deletes anything immediately, so before you start recreating work from scratch, check reflog first. It surfaces every HEAD move Git has recorded, including the ones that felt unrecoverable:\n1 2 git reflog git reset --hard HEAD@{4} ","permalink":"https://arps18.github.io/posts/git-mastery-intermediate-professional-workflows/","summary":"Notes on Git internals, history cleanup, branching strategies, and recovery techniques I rely on past the basics.","title":"Git Mastery: Intermediate and Professional Workflows"},{"content":"One of the most satisfying wins I had recently at work was taking an Oracle SQL query that was running in 8 seconds and getting it down to 500ms. That\u0026rsquo;s a 16× speedup, and it happened in an afternoon. Here\u0026rsquo;s the story.\nThe problem The query was part of a data processing pipeline running in production. Users were seeing noticeable delays, and the query was being called frequently enough that it was spiking database CPU during peak hours.\nThe original query looked something like this (simplified):\n1 2 3 4 5 6 7 SELECT t1.id, t1.name, t2.status, t3.amount FROM transactions t1 JOIN accounts t2 ON t1.account_id = t2.id JOIN payments t3 ON t3.transaction_id = t1.id WHERE t1.created_date \u0026gt;= SYSDATE - 30 AND t2.region = \u0026#39;US\u0026#39; ORDER BY t1.created_date DESC; Nothing unusual — but it was scanning millions of rows on every execution.\nStep 1: Read the execution plan The first thing I did was pull the execution plan with EXPLAIN PLAN. The output showed a full table scan on transactions, which has tens of millions of rows. That\u0026rsquo;s your signal: the optimizer isn\u0026rsquo;t using an index.\nStep 2: Add the right index The query filters on created_date and joins on account_id. A composite index on (created_date, account_id) lets the optimizer narrow the date range first, then the join happens on a much smaller set.\n1 2 CREATE INDEX idx_transactions_date_account ON transactions(created_date, account_id); Order matters in composite indexes. The column with the most selective filter should come first. created_date \u0026gt;= SYSDATE - 30 eliminates the bulk of rows up front, so it leads.\nStep 3: Verify with the optimizer After adding the index, I ran EXPLAIN PLAN again. The full table scan was gone, replaced with an INDEX RANGE SCAN. Query time dropped to ~500ms.\nTakeaways Always start with EXPLAIN PLAN. Guessing at optimizations without understanding what the DB is actually doing is a losing game. Composite index column order matters. Lead with the most selective predicate. Measure, don\u0026rsquo;t assume. Even after adding the index, I ran benchmarks with real production-like data volumes before calling it done. Small wins like this add up. When you\u0026rsquo;re running a query millions of times a day, 7.5 seconds per call translates to real infrastructure cost — and a much better experience for everyone downstream.\n","permalink":"https://arps18.github.io/posts/sql-optimization/","summary":"How I took a critical query from 8 seconds down to 500ms (a 16× speedup) through indexing, execution plan analysis, and a few hard-earned lessons.","title":"Optimizing Oracle SQL: From 8 Seconds to 500ms"},{"content":"I\u0026rsquo;ve been building REST APIs with Micronaut for about a year now, and I keep getting asked why I didn\u0026rsquo;t just use Spring Boot. Here\u0026rsquo;s the honest answer.\nWhat Micronaut does differently Micronaut does dependency injection and AOP at compile time, not runtime. That means:\nFaster startup — typically under a second, compared to 5-10s for equivalent Spring apps Lower memory footprint — critical when you\u0026rsquo;re running many microservices in Kubernetes No reflection overhead — better performance in steady state For container-heavy architectures where you\u0026rsquo;re scaling pods up and down constantly, those startup times matter a lot.\nA minimal example Here\u0026rsquo;s what a basic controller looks like:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 @Controller(\u0026#34;/api/users\u0026#34;) public class UserController { private final UserService userService; public UserController(UserService userService) { this.userService = userService; } @Get(\u0026#34;/{id}\u0026#34;) public HttpResponse\u0026lt;User\u0026gt; getUser(@PathVariable Long id) { return userService.findById(id) .map(HttpResponse::ok) .orElse(HttpResponse.notFound()); } @Post public HttpResponse\u0026lt;User\u0026gt; createUser(@Body @Valid UserRequest request) { User created = userService.create(request); return HttpResponse.created(created); } } If you\u0026rsquo;ve used Spring before, this will look familiar. The annotations are similar, the mental model is similar. The difference is all under the hood.\nWhere it shines Serverless — cold starts are dramatically shorter Microservices on Kubernetes — faster pod readiness means quicker rollouts GraalVM native images — Micronaut was designed with this in mind from day one Where Spring still wins Ecosystem. Spring has a library for everything. Micronaut is catching up but it\u0026rsquo;s not there yet. Team familiarity. If your team already knows Spring inside and out, retraining has a cost. Stack Overflow answers. Still much more for Spring problems. My take Pick Micronaut when startup time, memory, or native compilation matters. Pick Spring when ecosystem depth or team familiarity matters. There\u0026rsquo;s no universally right answer — and that\u0026rsquo;s fine.\n","permalink":"https://arps18.github.io/posts/micronaut-intro/","summary":"Why I picked Micronaut over Spring Boot for microservices, and what I learned along the way.","title":"Building REST APIs with Micronaut: A Practical Introduction"},{"content":"After a year of orchestrating microservices on Kubernetes in production, I\u0026rsquo;ve collected a set of lessons, some earned painfully. Here they are.\n1. Resource limits are not optional Early on, we ran pods without CPU and memory limits. It \u0026ldquo;worked\u0026rdquo; — until one noisy neighbor ate an entire node\u0026rsquo;s resources and took down the services around it.\nNow every pod has explicit requests and limits:\n1 2 3 4 5 6 7 resources: requests: memory: \u0026#34;256Mi\u0026#34; cpu: \u0026#34;250m\u0026#34; limits: memory: \u0026#34;512Mi\u0026#34; cpu: \u0026#34;500m\u0026#34; Requests guarantee the scheduler places your pod somewhere with capacity. Limits cap bad behavior. Both are worth the five minutes it takes to set them.\n2. Readiness probes matter more than liveness probes A liveness probe tells Kubernetes when to restart a pod. A readiness probe tells it when to start sending traffic. People often conflate these.\nIf your readiness probe is missing or wrong, you\u0026rsquo;ll route requests to pods that aren\u0026rsquo;t actually ready to serve them — and see mysterious 502s during deployments.\n1 2 3 4 5 6 readinessProbe: httpGet: path: /health/ready port: 8080 initialDelaySeconds: 10 periodSeconds: 5 Expose /health/ready that checks DB connections, cache warmup, etc. — not just \u0026ldquo;am I alive.\u0026rdquo;\n3. ConfigMaps and Secrets — separate them Configuration values go in ConfigMaps. Anything sensitive (API keys, DB credentials, tokens) goes in Secrets. Don\u0026rsquo;t bake either into images.\nAnd enable encryption at rest for etcd. Kubernetes Secrets are base64-encoded by default, not encrypted.\n4. Horizontal Pod Autoscaling is worth the setup HPA scales pods based on metrics. It\u0026rsquo;s a small config file and it\u0026rsquo;s saved us during unexpected traffic spikes:\n1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: api-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 5. Invest in observability early Prometheus, Grafana, centralized logging. Set these up before you need them. When something breaks at 2 AM, you\u0026rsquo;ll want the data already flowing.\nKubernetes has a steep learning curve, but the operational leverage once you\u0026rsquo;re past it is real. Start small, get the basics right, and the rest follows.\n","permalink":"https://arps18.github.io/posts/kubernetes-lessons/","summary":"A year of running microservices on Kubernetes: what worked, what didn\u0026rsquo;t, and what I\u0026rsquo;d do differently.","title":"Kubernetes for Microservices: Lessons Learned"},{"content":"This weekend, I did something slightly reckless: I decided to write my own programming language. Not the next Rust or C#, but a tiny language with a Read–Eval–Print Loop (REPL) that I could hack on over weekends. I called it Andromex, because naming things is half the fun. I named it after my favorite galaxy, Andromeda, something vast, mysterious, and inspiring, just like the world of compilers.\nI\u0026rsquo;ve always been curious about what happens under the hood when code runs. Compilers sit right at that intersection of theory and systems engineering, i.e, lexers, parsers, Abstract Syntax Tree (ASTs), symbol tables, and optimizations. It\u0026rsquo;s like peeling back the curtain on how programming itself works. I once asked my professor whether a compiler is created first or the language itself, much like the classic chicken and egg problem, and his explanation inspired me to explore this fascinating cycle hands-on by building one myself.\nGo felt like the right tool: it\u0026rsquo;s simple, fast to build with, and lets me focus on compiler concepts without drowning in boilerplate. While many people associate Go with web APIs and microservices, I see it as a capable systems language; after all, projects like Docker and Kubernetes prove it can handle complex, low-latency workloads. Its speed, concurrency model, and built-in data structures make it a great fit compared to heavier options like Java or Python, or more memory-heavy ones like C. Of course, nothing is perfect; Go has its trade-offs, but for me, the pros far outweigh the cons, which is why I chose it for Andromex.\nThe Andromex compiler will follow a structured pipeline similar to traditional language systems. Source code written in Andromex first passes through the lexer, which converts raw text into tokens. These tokens are then fed into the parser, where the language\u0026rsquo;s grammar rules organize them into a structured form like Reverse Polish Notation (RPN) or an Abstract Syntax Tree (AST). Next, the semantic analysis phase (planned for future versions) will validate types, scopes, and logical consistency. The validated structure is then translated by the compiler into an intermediate representation, which the assembler converts into efficient bytecode. Finally, the virtual machine executes the bytecode, producing the program\u0026rsquo;s output.\nYou might wonder why a virtual machine is needed here — unlike languages like C++ that compile directly to machine code, Andromex first translates code into bytecode to ensure platform independence, simplify execution, and make future features like optimization, debugging, and JIT compilation easier to implement. Go, as the implementation language for the Andromex compiler and VM, handles all the infrastructure: reading source code, tokenizing it (lexer), parsing it into RPN or AST, performing semantic checks, compiling to bytecode, and running that bytecode inside the VM. Its fast compilation, memory safety, and strong standard library make Go ideal for building Andromex\u0026rsquo;s core components efficiently and reliably. This modular flow makes Andromex both extensible and easier to enhance with features such as type checking and eventual native code generation, while Go acts as the host language that brings the entire system to life.\nThe adventure started with something simple: installing Go. I hadn\u0026rsquo;t used it much before, so I kept the docs open on the side and decided to learn it on the fly while building Andromex. I wanted a clean setup, so I reached for the trusty Homebrew:\n1 brew install go Quick, painless, done. That\u0026rsquo;s why Homebrew exists.\nOnce Go was installed, I created the project module:\n1 go mod init github.com/myname/andromex If you\u0026rsquo;re coming from a Java world, think of go.mod like pom.xml. It\u0026rsquo;s a single file that declares the identity of your project, including the version of Go it expects and the dependencies it requires. No node_modules, no endless XML, just a lean definition.\nYou can check out the source code here .\nOur First REPL The very first program was nothing fancy. It just printed a welcome message and exited. But I wanted to pretend at least it was a REPL.\n1 fmt.Println(\u0026#34;Andromex REPL (ctrl+c to exit)\u0026#34;) That\u0026rsquo;s it. It didn\u0026rsquo;t read input yet, but it gave me the feeling of having booted up a shell of my own.\nGo enforces a strict rule: no unused variables or imports. If you import os but never touch it, your program won\u0026rsquo;t compile. That\u0026rsquo;s why I added this line:\n1 _ = os.Args The blank identifier _ is Go\u0026rsquo;s way of saying, \u0026ldquo;I know this exists, I\u0026rsquo;m just not using it right now.\u0026rdquo; A neat trick while scaffolding code :)\nRun vs Build In these early experiments, go run main.go was my best friend. It compiles and executes in one go, perfect for quick iteration. But when you want to ship something standalone, go build gives you a binary you can run without Go installed:\n1 2 go build -o repl ./repl The workflow feels natural: run while developing, build when you want something that lasts.\nDesigning a Language The real fun began when I thought about how Andromex should look. I wanted it tiny and explicit, something like a calculator language at first.\nBut there\u0026rsquo;s a classic problem: grammar ambiguity. Take 2 + 3 * 4. Should it be (2 + 3) * 4 = 20 or 2 + (3 * 4) = 14? Without operator precedence, both parses are valid.\nThe solution is to bake precedence into the grammar itself:\n1 2 3 expression ::= term ((\u0026#39;+\u0026#39; | \u0026#39;-\u0026#39;) term)* term ::= factor ((\u0026#39;*\u0026#39; | \u0026#39;/\u0026#39;) factor)* factor ::= NUMBER | \u0026#39;(\u0026#39; expression \u0026#39;)\u0026#39; Now multiplication and division bind tighter than addition and subtraction, just like you\u0026rsquo;d expect.\nThis isn\u0026rsquo;t just theoretical. If your REPL can\u0026rsquo;t parse expressions unambiguously, it\u0026rsquo;ll happily give you wrong answers with a straight face :p\nTokens Before parsing comes lexing. The lexer\u0026rsquo;s job is to take raw source code and split it into tokens — the basic words of the language. Numbers, operators, identifiers, semicolons. Tokens are the alphabet of a language.\nFor example, let x = 42; becomes:\n1 [LET] [IDENT:x] [ASSIGN:=] [INT:42] [SEMICOLON] I built a token package with two simple types:\n1 type TokenType string 1 2 3 4 type Token struct { Type TokenType Literal string } Readable, printable, and flexible. Strings make debugging friendlier than integer enums at this stage.\nLexer The lexer is where things start to feel alive. It\u0026rsquo;s basically a scanner that walks through the input string one character at a time and decides what token to emit.\n1 2 3 4 5 type Lexer struct { input string pos, readPos int ch byte } The trick is managing state. You need to know your current character, the next one (lookahead), and when to stop. For example, is = just an assignment, or is it part of ==? Without looking ahead, you can\u0026rsquo;t know.\nHere\u0026rsquo;s how that logic looks:\n1 2 3 4 5 6 if l.ch == \u0026#39;=\u0026#39; { if l.peekChar() == \u0026#39;=\u0026#39; { return Token{Type: EQ, Literal: \u0026#34;==\u0026#34;} } return Token{Type: ASSIGN, Literal: \u0026#34;=\u0026#34;} } This one-character lookahead is what makes the lexer work for both single- and multi-character tokens.\nLet\u0026rsquo;s put it together. For the input:\n1 let x = 42 + 10; The lexer produces:\n1 2 3 4 5 6 7 8 {LET, \u0026#34;let\u0026#34;} {IDENT, \u0026#34;x\u0026#34;} {ASSIGN, \u0026#34;=\u0026#34;} {INT, \u0026#34;42\u0026#34;} {PLUS, \u0026#34;+\u0026#34;} {INT, \u0026#34;10\u0026#34;} {SEMICOLON, \u0026#34;;\u0026#34;} {EOF, \u0026#34;\u0026#34;} That\u0026rsquo;s the raw vocabulary your parser will consume to build a syntax tree and eventually run code.\nDocumentation Now that we\u0026rsquo;ve built our lexer, it\u0026rsquo;s time to make it professional with proper documentation. One thing I love about Go: documentation is built in. Write a proper comment above a package, type, or function, and godoc will pick it up. It feels like Javadoc without the ceremony.\n1 2 // Lexer represents a lexical analyzer for Andromex. type Lexer struct { ... } Now you can check the docs locally:\n1 2 3 4 5 6 7 8 9 # View package documentation go doc github.com/arps18/andromex/lexer # View specific function go doc github.com/arps18/andromex/lexer.New go doc github.com/arps18/andromex/lexer.Lexer.NextToken # View with source code go doc -src github.com/arps18/andromex/lexer.NextToken And get clean, structured docs for free. Run godoc -http=:8080 and you\u0026rsquo;ve got a local documentation server in your browser. It makes your toy language feel like a real project.\nIf you want something like Javadoc hosted over a web server, then:\n1 2 3 4 5 6 7 8 9 10 # Install godoc tool (if not already installed) go install golang.org/x/tools/cmd/godoc@latest # Start local documentation server godoc -http=:8080 # Open browser to: # http://localhost:8080 # Navigate to your package: # http://localhost:6060/pkg/github.com/arps18/andromex/lexer/ What\u0026rsquo;s Next Currently, Andromex can tokenize input and pretend to be a REPL. Next up is parsing those tokens into an abstract syntax tree and actually evaluating expressions. Eventually, I\u0026rsquo;d love for it to support variables, functions, and maybe even conditionals.\nBut the journey so far has been the fun part: installing Go, setting up modules, designing grammar, and building a lexer. Every little step turns abstract compiler theory into something tangible on my screen.\nRight now, it\u0026rsquo;s still very early, so instead of evaluating 2 + 3 * 4 = 14 I just got the tokens. But honestly, seeing your language spit out anything at all feels magical.\nRoadmap:\nParser: Build an Abstract Syntax Tree (AST) from tokens. Semantic Analysis: Add symbol tables and type checking. Intermediate Representation (IR): Generate a lower-level form for analysis/translation. Optimization: Constant folding, dead code elimination, peephole optimizations. Code Generation: Output to a virtual machine or target assembly. Error Handling: More helpful syntax and runtime error messages. Control Flow: Support for if, while, for, etc. Functions: User-defined functions with parameters and return values. Data Structures: Arrays, structs, and beyond. Object-Oriented Features: Classes, methods, and inheritance. ","permalink":"https://arps18.github.io/posts/andromex-and-beyond/","summary":"This weekend, I did something slightly reckless: I decided to write my own programming language.","title":"Andromex and Beyond"},{"content":"I was out walking the other day, headphones on, letting Spotify shuffle through my playlists. After a few skips, a curious question started buzzing in my head: why does Premium feel so much smoother than a free tier when you skip songs? I\u0026rsquo;d also recently watched the Netflix series The Playlist (the dramatized story of Spotify) and a Netflix tech documentary that showed how streaming companies have to reinvent how data moves across the internet. Those two dots connected, and I started thinking about the engineering behind Spotify\u0026rsquo;s skips.\nPrefetching: The Secret to Instant Skips On the surface, skipping a song is trivial: stop one stream, start another. But at scale, it\u0026rsquo;s a performance and cost problem. For a seamless experience, the app needs to buffer — while Song A is playing, it begins fetching Song B (and maybe Song C or D) so that when you hit the Next button, the audio starts instantly. This is called prefetching. Netflix and YouTube do a similar thing with video segments, so you never see a blank screen.\nHere\u0026rsquo;s where the business model intersects with the engineering. Premium users pay; they get unlimited skips and on-demand playback. For that to feel instant, Spotify can justify preloading several tracks ahead. The client downloads chunks of upcoming tracks into your local cache so you can skip rapidly without gaps. It\u0026rsquo;s bandwidth hungry, but it\u0026rsquo;s a perk you\u0026rsquo;re paying for.\nFree users are different. They\u0026rsquo;re limited to a handful of skips per hour, can\u0026rsquo;t always choose tracks, and hear ads. For Spotify, that means it\u0026rsquo;s wasteful to preload three or four trending songs you\u0026rsquo;re unlikely to hear. Every second of a track streamed, even if skipped, costs money in CDN bandwidth and in royalties. By preloading less aggressively on free, Spotify saves those costs and gently nudges you toward upgrading. The difference you feel isn\u0026rsquo;t just policy — it\u0026rsquo;s a deliberate technical trade-off.\nThe Evidence There\u0026rsquo;s some proof that this isn\u0026rsquo;t just speculation. Spotify\u0026rsquo;s own engineering blog has detailed posts on their playback architecture, caching layers, and how the client handles prefetch buffers. Even more telling, Spotify holds patents around media content caching and state prediction (Patent US20190324940A1 — Media content caching and state prediction), which describe techniques to preload media items based on predicted playback behavior. They also filed patents for queue and buffer control that imply smart scheduling of which tracks to load next.\nIn layman\u0026rsquo;s terms, the system tries to guess what you\u0026rsquo;ll listen to next and pulls it down in advance. They don\u0026rsquo;t explicitly say \u0026ldquo;Premium gets more prefetching than Free,\u0026rdquo; but the pieces line up: more prediction and caching make skips instantaneous, while a leaner version keeps Free users functional but limited.\nThe Obsession with Latency The connection to Spotify\u0026rsquo;s own story makes this even clearer. In the Netflix series The Playlist, one episode shows how Daniel Ek and the early Spotify team obsessed over latency and instant playback. Their mission wasn\u0026rsquo;t just to get music online; it was to make it feel faster than piracy. If people had to wait, they\u0026rsquo;d just download illegally. That urgency led them to engineer a playback system that buffered tracks aggressively, experimented with peer-to-peer streaming, and bent traditional internet delivery models to achieve near-instant starts.\nThis idea echoes what Netflix later did in their own way — engineers describe how they had to \u0026ldquo;break the old rules\u0026rdquo; of the internet and build their own CDN (Open Connect), caching entire seasons of shows directly with ISPs. Different media, same principle: caching and prefetching to hide network delays and make content feel immediate.\nThe Layered Architecture Spotify\u0026rsquo;s scale is smaller per stream, but more volatile — songs are short, skips are frequent, and user behavior is unpredictable. That\u0026rsquo;s why the Premium vs. Free split matters so much. Premium revenue funds the aggressive prefetching that makes skips buttery smooth, while the Free tier gets a thinner pipeline.\nUnder the hood, Spotify\u0026rsquo;s playback pipeline looks more like a miniature distributed system than a simple music player. The client app maintains a prefetch buffer, fetching small audio chunks from edge servers while tracking network conditions. A Premium user\u0026rsquo;s buffer might quietly hold two or three songs ahead, while a Free user\u0026rsquo;s buffer is kept lean. Behind that, CDNs serve compressed chunks in bursts, and Spotify\u0026rsquo;s backend prediction models decide which tracks are worth preloading. Each layer — client, edge, core API — balances latency, bandwidth, and licensing cost. The smoothness you feel is the result of these layered optimizations.\nClosing Thoughts Once you start to look at it this way, Spotify Premium\u0026rsquo;s seamless skips aren\u0026rsquo;t just a UX perk. They\u0026rsquo;re the surface of a whole set of architectural decisions: aggressive prefetching on the client, smart caching on CDNs, and economic incentives aligned with engineering constraints. That walk made me realize the \u0026ldquo;magic\u0026rdquo; in my headphones isn\u0026rsquo;t magic at all — it\u0026rsquo;s careful systems design tuned to a business model.\nRecommended reading from the Spotify Engineering Blog:\nHow Spotify aligned CDN services for a lightning-fast streaming experience Expected Latency Selector Part 1 ","permalink":"https://arps18.github.io/posts/spotify-skips-engineering/","summary":"Exploring the engineering decisions behind Spotify\u0026rsquo;s skip functionality and its business implications.","title":"From Buffer to Business Model: The Engineering of Spotify Skips"},{"content":"When I was first learning data structures, I remember being confused about the \u0026ldquo;stack\u0026rdquo; I encountered in my data structure class and a similar one in my CPU class. I was hesitant to ask about it because it seemed like a simple question. But as I delved deeper into software, this question resurfaced, and now, while studying the CPU in detail, I\u0026rsquo;ve realized that they are not the same thing.\nTL;DR — The stack in software is a data structure, while the stack in hardware is that data structure applied.\nTo break it down, the stack in the CPU is a blend of both the theoretical data structure (the LIFO stack) and practical optimizations required for CPU operations.\nA stack, as we know, is a linear data structure that follows either FILO (First In Last Out) or LIFO (Last In First Out).\nKey Operations of a Stack Peek: Retrieves the top element without taking it out of the stack. Push: Insert an element at the top of the stack. Pop: Removes the element at the top of the stack. IsEmpty: Determines whether the stack is empty. IsFull: Determines whether the stack has reached its capacity. We use stacks in Depth-First Search (DFS), recursion, and practical applications such as Undo/Redo functions, and function calls.\nThe Hardware Aspect of the Stack The CPU has dedicated registers, like the Stack Pointer (SP) and others, that are designed to manage stack operations. CPUs have instructions like PUSH, POP, CALL, and RET which directly interact with the stack pointer and other registers to manipulate memory.\nWhile the hardware provides the mechanism to manage the stack, the operating system (OS) plays a significant role in determining how it is used. The OS allocates a specific memory region for the stack when a program begins execution, with its size and location determined by both the OS and the program. The software, especially compilers, structures the stack into frames, giving each function call its own dedicated section for local variables, arguments, and return addresses. Compilers generate code that uses the stack implicitly based on the structure of the code.\nIn Summary The concept of a stack is a blend of both worlds — hardware and software. It works closely with the CPU and memory to manage data and control flow, integrating theory with practical optimizations.\n","permalink":"https://arps18.github.io/posts/is-stack-software-or-hardware/","summary":"Clarifying the confusion between data structure stacks and hardware stack concepts.","title":"Is Stack a Software or a Hardware?"},{"content":"If you are new to Swift and find yourself encountering those annoying \\n characters after each statement in multiline code, fret not. While they indicate a new line, there\u0026rsquo;s a simple trick to remove them and still maintain clean code formatting.\nBy adding a backslash (\\) at the end of each line, you can effectively break multiline statements without the unwanted line breaks:\n1 2 let greeting = \u0026#34;Hello, \u0026#34; + \u0026#34;world!\u0026#34; However, keep in mind that Swift doesn\u0026rsquo;t allow a backslash at the end of the last line in a multiline statement. So, remember to avoid that to prevent any errors.\nThat\u0026rsquo;s it for this quick tip! Stay tuned for more exciting Swift insights.\n","permalink":"https://arps18.github.io/posts/swift-multiline-magic/","summary":"A Swift syntax technique for managing multiline strings without unwanted characters.","title":"Swift Multiline Magic: Say Goodbye to Annoying Line Breaks!"},{"content":"Python is one of the most popular languages to play around with different things and I like experimenting with the command line. The command line is still one of the best tools for a developer to play around with.\nSo, I was building a project which worked on CLI, built with Python. While I was almost done finishing my project, I thought there was something missing, something cool.\nI wanted to display a welcome message with a bit of enlarged text so a user feels welcome. And while browsing, I came across a wonderful Python module called Pyfiglet . It is a Python module for converting strings into ASCII text with artistic fonts and can be modified into various patterns as well. Check out http://www.figlet.org/ for more.\nIt is very simple to use. First, install it:\n1 pip install pyfiglet Then use it in your script:\n1 2 3 4 import pyfiglet result = pyfiglet.figlet_format(\u0026#34;Welcome!\u0026#34;) print(result) This will render your welcome message as large ASCII art in the terminal — a small touch that makes CLI tools feel a lot more polished.\nDo share your thoughts on the same, feedbacks appreciated!\n","permalink":"https://arps18.github.io/posts/building-welcome-message-in-cli/","summary":"Python CLI customization for building welcome messages using PyFiglet.","title":"Building Welcome Message in CLI"},{"content":"Hello Folks!\nHope you are doing well during this quarantine and make sure you stay indoors. So apparently Quarantine is a big boredom to a lot of people. But according to me, it\u0026rsquo;s a very good time to learn new skills, work on your hobbies, spend time with family and whatnot.\nDumbledore rightly said:\n\u0026ldquo;Happiness can be found, even in the darkest of Times\u0026rdquo;\nThe Opportunity Amidst this, I came to know about this exciting event called Hack Quarantine. It\u0026rsquo;s a people-focused hackathon bringing people together to use their skills to help combat the issues the world is facing with the COVID-19 pandemic — and it was completely digital. It was very good to see such initiatives being carried out which help to improve one\u0026rsquo;s skills.\nFirstly, I would like to congratulate the entire team of Hack Quarantine for hosting such a great event in a very short span of time. It had both the flavour of uniqueness as well as innovation and being conducted on a digital platform, it provided a great extent to its essence.\nInitially, when I heard about Hack Quarantine (HQ), I went through their amazing website and came to know they are accepting CFP as well. I always wanted to give a remote talk and looked at this as an opportunity and applied.\nI proposed my lightning talk on Flutter. Currently, I am exploring it and thought — why not address people about it too!\nThe Recording Process I decided to pre-record my talk and be available on the live stream for Q\u0026amp;A. The decision of pre-recording made me realise one thing for sure: recording and editing is not an easy job. But to be honest, I loved doing it. It was a bit tricky but it had its fun. Sometimes listening to your voice has its fun. It helped me develop confidence as well!\nAfter many retakes and basic editing, I ended up making the final video of my session.\nTalk Content I covered topics like What is Flutter, its functionalities, and a hands-on session. I also tried to cover the basics of Flutter like Widgets, Stateless and Stateful, etc. I stated a few important links as well so that beginners can get a proper walkthrough of the topic.\nIn the hands-on session, I showed how to create an app suggesting names and an infinite scroll. I used the following package for the English words:\n1 import \u0026#39;package:english_words/english_words.dart\u0026#39;; It suggested different names generated every time one scrolls down with a set of English words. Pretty interesting!\nThe Live Event On April 27, my session was live on Twitch and for me, it was a great experience. I got a few questions as well. It was very good to see a lot of folks had shown up and I hope it helped them.\nTips for Remote Talks Here are a few tips that I learnt which helped me:\nMake a list of topics you want to cover. Note down necessary links and references. Just go through areas of a topic once before recording — it might help to avoid chances of retakes! Just be yourself while delivering your session. If you are using some stuff from the Internet, it\u0026rsquo;s better to give credits to it. Provide links to your slides/code. Also, want to add that team HQ had been very supportive throughout the event. Kudos to them!\nConclusion This experience brought me a lot of new ideas and improvements. Team HQ has uploaded my session on their YouTube channel — you can find it here .\nThank you very much and make sure you take care of yourselves and everyone else. I\u0026rsquo;ll see you around!\n","permalink":"https://arps18.github.io/posts/my-first-remote-talk/","summary":"A personal reflection on delivering my first remote presentation at Hack Quarantine.","title":"My First Remote Talk"},{"content":"As always we are surprised by our mozmeet location, so was this time. The mozmeet was organized at our Mozmeet Rep Pranshu\u0026rsquo;s friend\u0026rsquo;s apartment.\nAnd this time we had a good amount of people gathered for the mozmeet. The room was compact but somehow we managed!\nThe main motive for the mozmeet is to discuss the upcoming events, arrangements, and all the techy and non-techy talks. So the meet began with the introduction of some new fellas. They also spoke about their domain of interest. After a brief introduction, Pranshu Bhaiya took over. He explained the need of the community — how one learns as well as helps to learn others, and what role it plays in an individual, how it helps to enhance oneself.\nThe clock passed by, so did the discussion. Pranshu Bhaiya explained about the upcoming Mozilla Web Browser called Mozilla Preview. From there onwards he started explaining about the upcoming Mozilla event — the Mozilla Preview BugHunter, scheduled for the upcoming week. He shared about the event objectives and highlights.\nSome of the highlights of Mozilla Preview:\nFaster than ever: Firefox Preview is up to 2x faster than previous versions of Firefox for Android. Fast by design: With a minimalist start screen and bottom navigation bar, Preview helps you get more done on the go. Stay organized: Make sense of the web with Collections, a new feature that helps you save, organize, and share collections of sites. Quickly save and return to tasks like your morning routine, shopping lists, travel planning and more. Tracking Protection on by default: Everyone deserves freedom from invasive advertising trackers and other bad actors, so Firefox Preview blocks trackers by default. The result is faster browsing and fewer annoyances. The discussion moved further, and talks started on the latest tech topics — Firefox Focus, Google Stadia, Fuschia OS, Huawei, and all the stuff. The best part of the Mozmeet is that everyone loves to share their opinions, knowledge, and ideas. This is the reason I just love this community. When the meet ended we realized that we had nearly 7 hours of discussion!\nThat\u0026rsquo;s all Folks, for now. See you soon.\n","permalink":"https://arps18.github.io/posts/mozapartment/","summary":"A recap of a Mozilla community meetup gathering and discussions on Firefox Preview.","title":"MozApartment"},{"content":"OS Fest is a celebration of Open Source Resources and technologies which are often overlooked. It\u0026rsquo;s everything for a student who wants to gain experience and cherish the opportunity if they are Content Writers, Programmers, Developers, or even Designers. The Open Source movement is the reason that technology has developed at such a breakneck pace for the past few decades.\nHence a festival is celebrated dedicated specially for Open Source — to teach the fundamentals to the newbies who are setting their way in this competitive world and contributing to the Open Source Community. This will help the world remain Open for all generations, and the generations to come.\nDate \u0026amp; Time: April 19, 2019 — 1000 to 1600 Hours\nVenue: Babaria Institute Of Technology, Vadodara\nAttendees: 80 Students\nDevBytes, the Campus Club of Babaria Institute of Technology (B.I.T.S), collectively organized this wonderful joint gathering fest which led to gathering many innovative minds eager to contribute to Open Source.\nBefore this event, we discussed various aspects of the Fest and the necessities it carries. On the day of the event, when we reached the location, we realized that the organizers had kept their word for the preparations. We explored the campus too and had our coffee and breakfast.\nOpening The event kicked off with a brief introduction of their club DevBytes by one of their club co-founders Jainal, who described the salient features and motto of their club. The interaction session began with a few questions like:\nWhat is Open Source? What are the advantages of Open Source? What is GitHub? Pranshu Khanna welcomed everyone and explained more about OS Fest and introduced the audience with the speakers.\nMastering Git \u0026amp; GitHub Firstly we had our two GitHub Campus Experts Daniel \u0026amp; Harshil who discussed Mastering Git \u0026amp; GitHub. Since OS is all about collaboration, they decided to collaborate on this one as well! Participants were provided various cheatsheets of git commands so that it could be easily grasped. Being Campus Experts, they also shared their experience and all the advantages Git \u0026amp; GitHub offers to a Developer.\n\u0026ldquo;GitHub is a web-based hosting service for version control using Git. It offers distributed version control and source code management functionality.\u0026rdquo;\nBrowser Extensions After the wonderful session on Git, it was time for Browser Extensions — taken by Pranshu Khanna, who is a Mozilla Representative.\n\u0026ldquo;An extension adds features and functions to a browser using HTML, CSS, and JavaScript with access to specialized APIs.\u0026rdquo;\nHe taught the participants how to build a browser extension and how to do a pull request on GitHub. We received a lot of pull requests!\nFlutter After an amazing session, it was lunch! A further session was carried out by our Flutter Expert Parth, who is also a co-organizer at GDG Gandhinagar. He went on explaining the basics of Flutter and how easy it is to develop with.\n\u0026ldquo;Flutter is an open-source mobile application development framework created by Google for Android, iOS, and Google Fuchsia.\u0026rdquo;\nThere were some amazing memes up his sleeves so the audience liked his session too.\nMachine Learning The further session was taken by our Machine Learning Expert Pratik, who taught the audience about Machine Learning, its importance, TensorFlow, and a lot more. He went on explaining how a machine can identify objects using the training model.\nMeanwhile, among all these sessions, some participants were awarded swags and stickers for answering questions!\nOpen Source Contribution \u0026amp; GSOC The fest advanced and it was time again for Pranshu Khanna. He went on explaining the importance of community, what its goals and advantages are, how one can contribute to Open Source, and how it can be helpful for learning and career growth. He also shared his amazing experience as a Mozilla Rep.\nLater I and my friend Harsh went on explaining the audience about GSOC (Google Summer of Code) — how one can participate in it and what the advantages are.\nClosing The Fest ended with the felicitation of the winners in many categories.\nIt was a curtain for the event, but an ignition to a lot of innovative minds. That\u0026rsquo;s what an OS Fest aims — to ignite the young minds.\nThat\u0026rsquo;s all Folks! I\u0026rsquo;ll see you around!\n","permalink":"https://arps18.github.io/posts/os-fest/","summary":"OS Fest is a celebration of Open Source Resources and technologies — a recap of the event at Babaria Institute of Technology.","title":"OS Fest"},{"content":"Flutter is Google\u0026rsquo;s portable UI toolkit for building beautiful, natively-compiled applications for mobile, web, and desktop from a single codebase. Flutter apps are written in the Dart language and make use of many of the language\u0026rsquo;s more advanced features.\nDate \u0026amp; Time: June 16, 2019 — 1000 to 1500 Hours\nVenue: Navrachana University, Vadodara\nAttendees: 50 Students\nFlutter Bootcamp Vadodara was a collaboration of DSC SVIT \u0026amp; DSC PU. The motto of the Bootcamp is to make coding fun by introducing the audience to new technologies like Flutter.\nWe are extremely thankful to our mentors Harshil Agarwal \u0026amp; Ayush Bherwani who allowed me and my co-mate Pranit Brahmbhatt to share the stage for Day 1 at the event.\nDart Fundamentals Pranit introduced the participants to Dart with some amazing memes! He started by talking about why Flutter loves Dart, and moved on to programming concepts like data types, conditional statements, loops, methods, exception handling, and gave a brief about OOP.\nWe had a quick networking session after the break, where attendees introduced themselves — with memes.\nOOP Deep Dive It was my first experience as a speaker and I was pretty excited. I continued the session by explaining the following Dart/OOP concepts:\nInheritance Getters and Setters Abstraction Generics Safety Operators Async I constantly interacted with the audience and they were responsive too. (We also awarded them with cool swags!)\nQuiz Time After the two sessions, it was time for some fun. We had an amazing time testing the knowledge of the participants with a small quiz hosted on Kahoot! — always a crowd favourite.\nPrivacy Campaign We talked about data protection law, its importance, and the participants happily joined the campaign initiated by Mozilla.\nNetworking The day ended with a great networking session. People interacted with each other, many of them got new friends as well.\nWhat\u0026rsquo;s Coming Next So Week 1 ended on a high note and participants gave some fantastic feedback! But it\u0026rsquo;s not over yet. The expedition continues:\nWeek 2 will cover: Stateless Widget, Stateful Widgets, Navigation in Flutter \u0026amp; a lot more.\nWeek 3 will be special — Pooja Bhaumik (First woman Google Developer Expert in India) will be joining us and enlighten us with her knowledge \u0026amp; experience. Topics: API calls, NoSQL vs SQL, Firestore with Flutter \u0026amp; advance topics about Flutter.\nWeek 4 will be a Hackathon, with many mentors joining us.\nStay tuned!\n","permalink":"https://arps18.github.io/posts/flutterbootcamp-vadodara-2019-week1/","summary":"Week one overview of the Flutter development bootcamp in Vadodara, covering Dart fundamentals and OOP concepts.","title":"FlutterBootCamp Vadodara 2019 (Week 1)"},{"content":" Hello, I\u0026rsquo;m Arpan I\u0026rsquo;m a Software Developer Engineer at Credit Acceptance , based in Austin, TX. I build backend services and APIs, work with distributed systems, and obsess over making things faster.\nI graduated with a Master of Science in Computer Science from Northeastern University in December 2024, where I focused on scalable and distributed systems and programming design paradigms. Before that, I earned my B.E. in Information Technology from Sardar Vallabhbhai Patel Institute of Technology.\n\u0026ldquo;Stay hungry, stay foolish.\u0026rdquo; — Steve Jobs\nWhat I do I care about building software that holds up under pressure. Not just software that works in a demo, but systems that stay correct under concurrency, stay fast under load, and stay debuggable when things go sideways at 2am.\nMost of what I find interesting lives close to the metal: how memory is laid out, why a syscall takes longer than it should, what the scheduler is doing while you wait. I also spend a fair bit of time thinking about applied AI, specifically how language models fit into real production systems as useful primitives rather than bolted-on features.\nEarlier in my career, I co-founded Scudo Systems LLP, where we built real-time GPS tracking from the hardware layer up through the software stack. Shipping something that had to be accurate in the physical world, on constrained hardware, taught me more about what reliability actually means than any textbook did.\nTech I work with Programming Languages: Java, Python, C++, SQL, Swift, Go, TypeScript, JavaScript Networking \u0026amp; Protocols: TCP/IP, UDP, DNS, TLS/SSL, RPC, HTTP/HTTPS, REST AI \u0026amp; Data Platforms: LangChain, Vector Databases (Pinecone, Milvus), Redis Semantic Cache, Ollama Tools \u0026amp; Debugging: GDB, Valgrind, tcpdump, Git, Jenkins, Shell Scripting, Linux Internals Distributed Systems: Kafka, Spark, Hadoop, Kubernetes, Docker, Microservices, AWS, GCP Development: Node.js, Micronaut, Django, MySQL, MongoDB, Android, ReactJS Beyond the code I was the Chapter Lead of the Mozilla Campus Club at my undergraduate campus, co-organized Flutter Vadodara, and served as a trusted Mozilla Rep. I\u0026rsquo;ve contributed to open-source projects, including the Flutter Shortcut Widget via the \u0026ldquo;Adopt a Widget\u0026rdquo; campaign on GitHub, and co-authored a research paper titled \u0026ldquo;Parkup\u0026rdquo; published in the International Research Journal of Engineering and Technology. Dev Setup Hardware \u0026amp; OS\nMacBook Pro M2 13\u0026quot; macOS Sequoia 15.x Editor \u0026amp; Terminal\nIntelliJ IDEA — primary for Java/backend VS Code — the one that has a plugin for everything, including my indecision iTerm2 + zsh + Oh My Zsh Arc VS Code Extensions\nGitLens — git blame and history inline Error Lens — errors and warnings inline, no hovering needed REST Client — test APIs without leaving the editor Docker — container management from the sidebar Remote SSH — dev on remote machines without friction Apps\nRaycast — launcher, clipboard history, quick calculations AltTab — proper window switching on macOS Docker Desktop — container management Notion — where every great idea goes to become a perfectly formatted, never-finished document Day One — daily journal Claude Code — AI in the terminal Spotify — the real IDE, been shipping focus playlists since 2017 Few Interesting Pages Resume / CV : My professional background and experience Projects : Things I\u0026rsquo;ve built across distributed systems, IoT, and open source Posts : Writing on backend engineering, distributed systems, and lessons learned Shelf : Books, papers, and articles I find worth reading Resources : Useful websites, tools, and references I keep coming back to Get in touch I\u0026rsquo;m always up for a conversation about distributed systems, backend architecture, or just a good book recommendation.\nEmail: arpanpatel.contact@gmail.com LinkedIn: linkedin.com/in/arpanpatel18 GitHub: github.com/arps18 Views expressed here are my own and do not represent my employer or any organization I am associated with.\n— unique visitors have dropped by ","permalink":"https://arps18.github.io/about/","summary":"about","title":"About"},{"content":"A curated list of things I\u0026rsquo;ve built — across distributed systems, systems programming, and IoT. Most of these started as experiments and grew from there.\nProject Andromex — Minimal Compiler in Go active A minimal compiler written in Go to understand how programming languages are tokenized, parsed, and evaluated.\nTech: Go · Compilers · Lexer · REPL · AST\nLexer that converts source code into a well-defined token type system Interactive REPL for real-time experimentation with the language Extensible architecture planned for AST parsing, semantic analysis, and code generation Paxos — Fault-Tolerant Distributed Key-Value Store A fault-tolerant, replicated key-value store using the Paxos consensus algorithm, resilient against replica failures.\nTech: Java · Paxos · Java RMI · Distributed Systems · Consensus\nFull Paxos implementation with Proposer, Acceptor, and Learner roles based on Lamport's work Supports GET, PUT, DELETE operations with multiple replicas and dynamic client requests Simulated acceptor thread failures to demonstrate fault tolerance QuickLauncher — Social Media Browser Extension A simple, customizable browser extension for one-click access to all your social media profiles.\nTech: HTML · CSS · JavaScript · Browser Extension · Chrome · Firefox\nOne-click access to multiple social media profiles from the browser toolbar Fully customizable by swapping in personal images and custom links Cross-browser compatible (Chrome, Edge, Firefox) with simple load-unpacked install Crypto-Track — Real-time Cryptocurrency Tracker A real-time cryptocurrency price tracker web app for tracking prices on the go.\nTech: JavaScript · HTML · CSS · REST APIs\nReal-time cryptocurrency price monitoring with automatic updates on refresh Clean web-based interface built with vanilla JS, HTML, and CSS Live demo deployed on Netlify Gym Management — DBMS Demonstration A DBMS demonstration script showcasing structured data management with Python, modeled on the Marino Center Gym.\nTech: Python · SQL · Triggers · Functions · CRUD\nDemonstrates core DBMS concepts: triggers, stored functions, and constraints Full CRUD operations with an interactive command-line interface via demo.py Educational resource for learning SQL and database management principles PageRank — Spark \u0026 Hadoop MapReduce PageRank algorithm implemented in both Apache Spark and Hadoop MapReduce to demonstrate distributed computation paradigms.\nTech: Scala · Apache Spark · Hadoop · MapReduce · AWS EMR\nSpark implementation using RDD-based API with dangling page handling Comparative Hadoop MapReduce implementation for performance analysis Supports standalone Hadoop, pseudo-distributed, and AWS EMR execution environments Twitter Follower Count — Distributed Processing Distributed data processing pipeline using Hadoop MapReduce and Spark for large-scale follower count analysis.\nTech: Scala · Hadoop · Apache Spark · MapReduce · AWS EMR · Maven\nHadoop MapReduce and Spark implementations for distributed follower data processing Supports standalone, pseudo-distributed, and AWS EMR execution environments Makefile-driven build and deployment pipeline with Maven dependency management Market Radar — Automated Daily Stock Screener An automated daily stock screening service that delivers curated investment opportunities to your inbox every weekday morning at 7 AM Central.\nTech: Python · GitHub Actions · SMTP · yfinance · Anthropic Claude API · RSI · Moving Averages\nTwo-tier screening: 10 blue-chip movers and 10 under-the-radar picks from 500+ stocks, diversified across 5+ sectors Optional LLM enhancement via Claude or OpenAI for AI-synthesized news context alongside technical signals (~$0.003/day) Fully automated via GitHub Actions on a weekday schedule — zero manual intervention required iOS Demo App A Swift-based iOS demo application built as an early exploration of iOS development patterns.\nTech: Swift · iOS · Xcode · UIKit\nStandard Xcode project structure with unit tests and UI tests Demonstrates foundational iOS app architecture patterns Distributed Key-Value Store Server A distributed key-value store with client-server communication supporting both UDP and TCP protocols.\nTech: Java · UDP · TCP · Socket Programming · Multithreading\nSupported both UDP and TCP protocols, achieving a 98% success rate for seamless client-server interaction Utilized hash maps for efficient storage and retrieval of up to 10,000 key-value pairs, with average access time of 5ms Implemented multithreading for concurrent client handling Unix-like File System A POSIX-compliant file system implementation in C with inode-based metadata management.\nTech: C · POSIX · System Calls · Pointers · Linked Lists\nImplemented file creation, deletion, reading, writing, and directory traversal Designed modular structures for readdir, read, and write operations, reducing implementation complexity by 30% Inode-based metadata management for efficient file tracking Scudo Systems — Real-time GPS Tracking Co-founded venture building IoT tracking hardware and the software that powers it.\nTech: Python · Raspberry Pi · IoT · REST APIs\nDeveloped a custom software system for real-time tracking with 90% accuracy Restructured GPS algorithm to provide 10-meter radius accurate location Conducted extensive testing for production readiness with 40% faster response times Parkup — Smart Parking System Research project for an intelligent parking management system, published in IRJET.\nTech: IoT · Sensors · Cloud · Research\nCo-authored and published in the International Research Journal of Engineering and Technology Focused on real-time parking slot availability using sensor networks Flutter Shortcut Widget Open-source contribution to Flutter's widget ecosystem through the \"Adopt a Widget\" campaign.\nTech: Flutter · Dart · Open Source\nContributed documentation, examples, and bug fixes for the shortcut widget Helped other Flutter developers adopt the widget more easily Want to see more? My GitHub has the full collection.\n","permalink":"https://arps18.github.io/projects/","summary":"A curated list of my personal projects","title":"Projects"},{"content":"A growing collection of websites, tools, and references I keep coming back to. Bookmarking individual links gets messy fast, so this page is my source of truth for the corners of the internet worth remembering. Updated as I find them.\nLearning \u0026amp; Tutorials Semicolony : My favorite and go to developer\u0026rsquo;s space with study paths, simulators, visualizations, and deep dives across the whole CS stack. One of the most thoughtfully built learning sites out there. Three corners I keep coming back to: Postmortems : Annotated write ups of real infrastructure outages, config failures, data disasters, networking meltdowns, with the operational lessons pulled out cleanly. Better than any textbook on what actually breaks in production. Love it! ELI5 : Complex technical concepts stripped down to their simplest form. The kind of clarity you wish more writing had. Decide : A tool for navigating technical decisions trade-offs surfaced and options compared so you\u0026rsquo;re not choosing blind. Go by Example : Hands-on introduction to Go with annotated, runnable example programs. The fastest way to get productive in Go if you already know another language. The Rust Book : The official Rust learning resource. Comprehensive, well-paced, and the standard starting point for the language. Rustlings : Small exercises that get you used to reading and writing Rust. The companion drill book to The Rust Book. Crafting Interpreters : Bob Nystrom\u0026rsquo;s book on building two interpreters from scratch. Even if you\u0026rsquo;ll never write a compiler, it makes you a sharper programmer. Operating Systems: Three Easy Pieces (OSTEP) : A free OS textbook that\u0026rsquo;s actually fun to read. The standard recommendation for learning OS fundamentals. Build Your Own X : A massive index of \u0026ldquo;build your own database / git / shell / regex engine\u0026rdquo; tutorials. Pick a project, learn by reconstructing. The Missing Semester of Your CS Education : MIT\u0026rsquo;s short course on the tools every developer uses but no one teaches: shell, tmux, vim, debuggers, version control. Teach Yourself CS : A curated, opinionated reading list to build CS fundamentals on your own. One book and one course per topic. Full Stack Open : University of Helsinki\u0026rsquo;s free, no-nonsense React + Node course. One of the best free resources for modern web development. Learn X in Y Minutes : A whirlwind tour of any language\u0026rsquo;s syntax on a single page. Perfect for \u0026ldquo;I know how to program, just show me the syntax.\u0026rdquo; Beej\u0026rsquo;s Guide to Network Programming : The classic, friendly intro to sockets in C. Still the best starting point for low-level networking. MIT 6.5840 (Distributed Systems) : Robert Morris\u0026rsquo;s distributed systems course. Free lectures, paper list, and labs that build a fault-tolerant Raft-backed KV store. Practice \u0026amp; Challenges Coding Challenges : John Crickett\u0026rsquo;s weekly challenges to rebuild real-world tools from scratch (wc, cut, JSON parser, Redis clone, and more). Far more satisfying than grinding interview problems. Advent of Code : Eric Wastl\u0026rsquo;s December puzzle calendar. Two new problems a day, increasingly devious, and a perfect excuse to try a new language each year. Project Euler : Math-heavy programming problems that force you to think about complexity and clever number theory, not just data structures. Exercism : Mentored coding exercises across 70+ languages. The mentor feedback on submitted solutions is what really sets it apart. System Design Primer : Open-source guide and question bank for system design. Comprehensive, frequently updated, and the canonical free resource. Protohackers : Network programming challenges where you implement TCP/UDP servers against a real grader. Brilliant if you want to actually feel sockets. Codewars : Bite-sized kata across many languages. Good for short bursts of practice and comparing your solution to others. Cryptopals : Eight sets of cryptography challenges that take you from \u0026ldquo;what is XOR\u0026rdquo; to breaking real ciphers. Genuinely brilliant. OverTheWire : Linux and security wargames played over SSH. Bandit is the best intro to working in a Unix shell I know of. pwn.college : A free, structured infosec curriculum from Arizona State, run as a hands-on dojo of binary exploitation and systems security challenges. Frontend Mentor : Real design files and challenges for practicing frontend. Great if you learn by recreating production-looking UIs. Monkeytype : Minimal, customizable typing test that has become the dev-community standard for benchmarking raw keyboard speed. Surprisingly addictive once you start chasing a higher WPM. Git \u0026amp; Version Control Pro Git Book : The free, official Git book by Scott Chacon and Ben Straub. The single best resource for actually understanding Git\u0026rsquo;s model rather than memorizing commands. Oh Sh*t, Git!?! : Plain-English fixes for the most common Git messes. Bookmark it now, you\u0026rsquo;ll need it. Learn Git Branching : An interactive, visual tutorial that builds real intuition for branches, rebases, and merges by letting you watch the graph evolve as you type commands. Atlassian Git Tutorials : Clear, diagram-heavy explanations of every Git workflow. Often the first hit when you Google how a command works, and usually the best. How to Write a Git Commit Message : Chris Beams\u0026rsquo; seven rules for writing useful commit messages. The reason most well-maintained repos look the way they do. Conventional Commits : A simple specification for commit messages that machines and humans both find readable. Pairs naturally with semver and automated release tooling. In my opinion, now AI handles most of the format and conventions pretty well, yet these are still worth a read :)\nCloud \u0026amp; DevOps AWS Well-Architected Framework : AWS\u0026rsquo;s six-pillar framework (operational excellence, security, reliability, performance, cost, sustainability) for evaluating cloud architectures. The vocabulary every cloud engineer ends up using. Google Cloud Architecture Center : Reference architectures, best practices, and case studies across GCP. Useful even if you\u0026rsquo;re not on GCP. Azure Architecture Center : Microsoft\u0026rsquo;s equivalent, with a notably good catalog of cloud design patterns. Google SRE Book : The book that gave the industry the language for SLOs, error budgets, and toil. Free online. The SRE Workbook : The follow-up, focused on putting the ideas into practice. Read after the SRE Book. DORA / State of DevOps : Home of the four DORA metrics and the annual State of DevOps report. The closest thing the industry has to measurable evidence of what works. CNCF Landscape : A map of every cloud-native project in existence. Overwhelming on purpose, useful when you need to figure out what tool fits a niche. Roadmap.sh : Community-curated learning paths for DevOps, backend, SRE, and dozens more. A solid \u0026ldquo;where do I even start\u0026rdquo; reference. Architecture \u0026amp; System Design Martin Fowler : The reference site for software architecture, refactoring, microservices, and enterprise patterns. Decades of clear, durable writing. Microservices.io : Chris Richardson\u0026rsquo;s catalog of microservice patterns, with diagrams, trade-offs, and real-world context. AWS Builders\u0026rsquo; Library : Long-form articles where senior AWS engineers explain how they actually build and run services. One of the most underrated technical resources online. C4 Model : A lightweight notation for diagramming software architecture at four levels (context, container, component, code). Simple enough to actually use. Architectural Decision Records : A template and toolkit for capturing the why behind architectural choices in your repo, before the reasoning gets lost. Awesome Scalability : A massive, well-maintained reading list of scalability, availability, and performance case studies. ThoughtWorks Technology Radar : A twice-yearly snapshot of which technologies, techniques, and platforms are worth adopting, trialling, or avoiding. InfoQ Architecture \u0026amp; Design : News, articles, and conference talks on software architecture. Good for staying current on what the industry\u0026rsquo;s actually doing. Engineering Practices \u0026amp; Guides Google Engineering Practices : Google\u0026rsquo;s public code review developer guide, including how to review code and how to write the CL you submit. The single best document on giving and receiving code review feedback. Google Style Guides : Google\u0026rsquo;s open-source style guides for C++, Python, Java, Go, JavaScript, Shell, and more. Even if you disagree, knowing where they land is useful. Google Developer Documentation Style Guide : Detailed conventions for writing developer-facing docs. The closest thing to a published \u0026ldquo;house style\u0026rdquo; for technical writing. Microsoft Writing Style Guide : Microsoft\u0026rsquo;s writing guide, broader in scope than Google\u0026rsquo;s and arguably the gold standard for technical writing in English. The Twelve-Factor App : The cleanest statement of how cloud-native apps should be built. Old, short, still right. Semantic Versioning : The MAJOR.MINOR.PATCH spec. If you publish anything anyone else consumes, follow this. Keep a Changelog : A simple, durable format for writing changelogs. Saves you from \u0026ldquo;various bug fixes\u0026rdquo; entries forever. Choose a License : A GitHub-curated, plain-English guide to picking an open-source license. Stops you from doing the wrong thing in five minutes. Diátaxis : A four-quadrant framework (tutorials, how-tos, reference, explanation) for organizing documentation. Adopted by Django, NumPy, and many others. Contributor Covenant : The most widely adopted code of conduct for open-source communities. The default if you\u0026rsquo;re not sure where to start. References \u0026amp; Wikis The Algorithms : Open-source implementations of classic algorithms and data structures across many languages. Great for cross-language comparisons and as a quick refresher. OSDev Wiki : The canonical reference for anyone writing an operating system from scratch. Bootloaders, paging, scheduling, drivers, it\u0026rsquo;s all here. MDN Web Docs : The authoritative reference for HTML, CSS, JavaScript, and web APIs. If a browser does it, MDN documents it well. cppreference : The reference for C and C++. Far better organized and more accurate than the official standard library docs. DevDocs : Unified, offline-capable docs browser for dozens of languages and frameworks. One search bar across everything. man7.org Linux man pages : Michael Kerrisk\u0026rsquo;s well-maintained mirror of Linux man pages. Cleaner to read on the web than man in a terminal. Compiler Explorer (Godbolt) : Paste code in any of 30+ languages, see the assembly the compiler actually emits. Indispensable when you want to see what your high-level code becomes at the instruction level. Refactoring Guru : Design patterns and refactoring techniques explained with diagrams and examples in multiple languages. Use The Index, Luke : Markus Winand\u0026rsquo;s free, vendor-neutral guide to SQL indexing and query performance. Will change how you write SQL. Database of Databases (dbdb.io) : CMU\u0026rsquo;s encyclopedic catalog of every database system ever, with comparable specs and history. A delight to browse. Regex101 : Interactive regex tester with explanations of every token. The first tab I open whenever I\u0026rsquo;m writing a non-trivial pattern. Explainshell : Paste a shell command, get every flag and pipe explained. Indispensable for parsing someone\u0026rsquo;s incomprehensible one-liner. Blogs \u0026amp; Creators Martin Kleppmann : Author of Designing Data-Intensive Applications, researcher in distributed systems and local-first software. His writing is uniformly excellent. Dan Luu : Data-driven essays on software, hardware, hiring, and why so many things in this industry are worse than they should be. Julia Evans (jvns.ca) : Friendly, illustrated deep dives into how computers actually work: networking, debuggers, the Linux kernel. The zines are gold. Aphyr / Jepsen : Kyle Kingsbury\u0026rsquo;s blog and the Jepsen distributed-systems testing reports. The bar for \u0026ldquo;is this database actually correct?\u0026rdquo; Brendan Gregg : Performance engineering, profiling, flame graphs, eBPF. If something is slow in production, his site has the technique to find out why. Eli Bendersky : Patient, deeply-researched posts on compilers, Go, low-level systems, and CS fundamentals. Russ Cox : Former Go language lead, now at Google Research. His personal site is an index of projects, papers, and talks spanning Plan 9, regex theory, and systems research going back to the early 2000s — the kind of depth you don\u0026rsquo;t find anymore. His blog covers Go internals, language design, supply chain, and more, and is among the clearest technical writing today. Marc Brooker : AWS principal engineer writing about distributed systems in practice. Excellent on the gap between theory and operating a service. Arpit Bhayani : System design and database internals explained with depth and clarity. Approachable deep dives into how production systems actually work, well-loved in the backend community. Ben Kuhn : Engineering management, productivity, and decision-making essays from Anthropic\u0026rsquo;s CTO. Short and consistently sharp. Kalzumeus / Patrick McKenzie : Long-form essays on software business, careers, and how the world works behind the scenes. See also Bits about Money . Joel on Software : Joel Spolsky\u0026rsquo;s archive. Two decades of essays on shipping software that mostly still hold up. Paul Graham : Founder-focused essays from the Y Combinator co-founder. Aimed at startups, often applicable far beyond. High Scalability : Long-running aggregator and originator of \u0026ldquo;X stack at company Y\u0026rdquo; architecture write-ups. The genre\u0026rsquo;s home page. Cloudflare Blog : Easily the best big-company engineering blog. Deep, frequent posts on networking, performance, and edge infrastructure. Have a link worth adding? Email me , always looking for more.\n","permalink":"https://arps18.github.io/resources/","summary":"A curated collection of websites, tools, and references worth bookmarking","title":"Resources"},{"content":" Arpan Patel Software Developer Engineer • Austin, TX\nEmail • LinkedIn • GitHub • Download PDF Software Developer Engineer with a Master\u0026rsquo;s in Computer Science from Northeastern University and hands-on experience building scalable backend systems, REST APIs, and microservices. I focus on distributed systems, cloud infrastructure, and database performance. Currently building services at Credit Acceptance while continuing to contribute to open-source.\nKey Focus Go \u0026amp; concurrent services — goroutines, channels, building lexers/REPLs and small backend tools in Go Distributed systems — Paxos-style consensus, replication, fault tolerance, Kafka, Kubernetes orchestration Backend \u0026amp; APIs — REST, microservices, Micronaut/Django, performance tuning Database performance — Oracle/SQL optimization, indexing, execution plans (8s → 500ms wins) Applied AI — LangChain, vector DBs, semantic caching as production primitives Open source — Flutter Shortcut Widget contributor, builder of small useful tools Experience Software Developer Engineer Credit Acceptance • Jan 2025 – Present • Austin, TX (Remote)\nTech: Micronaut, Docker, Kubernetes, SQL, REST APIs, Microservices, GitHub Actions, Tomcat\nDeveloped and maintained REST APIs, enhancing system interoperability by 30%. Built an internal service that streamlined data processing workflows, reducing query response time by 40%. Optimized a critical Oracle SQL query from 8s to 500ms through indexing and execution plan analysis — a 16× speedup. Orchestrated microservices on Kubernetes, improving scalability and resource management. Software Developer Intern Credit Acceptance • May 2024 – Aug 2024 • Southfield, MI (Remote)\nTech: Django, Python, Java, Docker, Kubernetes, REST APIs, Microservices, GitHub Actions\nMigrated legacy codebase to Django and Python, reducing technical debt and improving maintainability. Containerized 20+ applications using Docker, improving deployment speed and system efficiency. Implemented GitHub Actions for CI/CD, cutting manual intervention by 50%. Software Developer Lead Intern Sanrel LLC • Jul 2023 – Dec 2023 • Worcester, MA\nTech: SQL, Node.js, Docker, Agile, Microservices\nLed software team projects, achieving 20% faster project completion through coordination and collaboration. Integrated a server with four hardware devices, ensuring seamless communication. Implemented a SQL-based inventory system using SnipeIt, boosting accuracy and efficiency by 30%. Designed a SQL database for product inventory and shipping, reducing processing time by 40%. Co-founder and Software Developer Scudo Systems LLP • Jul 2019 – Jul 2022 • Ahmedabad, India\nTech: Python, Raspberry Pi, IoT, REST APIs\nBuilt a custom software system for real-time device tracking with 90% accuracy. Restructured the GPS algorithm to deliver 10-meter radius location accuracy. Conducted extensive testing and debugging, achieving 40% faster response times. For more detail, visit my LinkedIn profile .\nSide Projects A few highlights — see the full list on the Projects page .\nProject Andromex — Minimal Compiler in Go Go • Compilers • Lexer • REPL • AST\nA minimal compiler written in Go — lexer with a typed token system, an interactive REPL, and an extensible architecture for AST parsing and code generation. Built to understand how programming languages get tokenized, parsed, and evaluated end-to-end.\nPaxos — Fault-Tolerant Distributed KV Store Java • Paxos • Java RMI • Consensus • Replication\nA replicated key-value store implementing the Paxos consensus algorithm with Proposer, Acceptor, and Learner roles. Supports GET/PUT/DELETE across multiple replicas, with simulated acceptor failures to validate fault tolerance.\nDistributed Key-Value Store Server Java • UDP • TCP • Sockets • Multithreading\nA distributed KV store over UDP and TCP, handling 10,000+ pairs with a 98% request success rate, ~5ms average access time, and concurrent client handling via multithreading.\nPageRank — Spark \u0026amp; Hadoop MapReduce Scala • Spark • Hadoop • MapReduce • AWS EMR\nPageRank implemented in both Spark (RDD-based) and Hadoop MapReduce to compare distributed computation paradigms. Runs across standalone, pseudo-distributed, and AWS EMR environments.\nUnix-like File System C • POSIX • Inodes • Linked Lists\nPOSIX-compliant file system with inode-based metadata, supporting file creation, deletion, read/write, and directory traversal — written to understand how filesystems lay out and track data on disk.\nScudo Systems — GPS Tracking Python • Raspberry Pi • IoT • REST APIs\nReal-time GPS tracking platform built from the hardware layer up through backend APIs, achieving 10-meter location accuracy on constrained hardware.\nPublications Parkup: Smart Parking System Co-authored research paper published in the International Research Journal of Engineering and Technology (IRJET).\nCommunity \u0026 Leadership Chapter Lead — Mozilla Campus Club at SVIT Ahmedabad Co-organizer — Flutter Vadodara community meetups Mozilla Rep — Represented Mozilla as a trusted volunteer at campus events Open-source contributor — Flutter Shortcut Widget (\u0026ldquo;Adopt a Widget\u0026rdquo; campaign) Education Master of Science — Computer Science Northeastern University • Sep 2022 – Dec 2024 • Boston, MA\nRelevant coursework: Programming Design Paradigm, Building Scalable and Distributed Systems.\nBachelor of Engineering — Information Technology Gujarat Technological University • Jul 2017 – Jul 2021 • Ahmedabad, India\nRelevant coursework: Analysis and Design of Algorithms, Software Engineering, Database Management Systems.\nTechnical Skills Languages Go Java Python C++ SQL Swift TypeScript JavaScript Distributed Systems Kafka Spark Hadoop Kubernetes Docker Microservices Paxos / Consensus AWS GCP Networking TCP/IP UDP DNS TLS/SSL RPC HTTP/HTTPS REST AI \u0026 Data LangChain Pinecone Milvus Redis Semantic Cache Ollama Tools \u0026 Debugging GDB Valgrind tcpdump Git Jenkins Shell Linux Internals Backend \u0026 Web Micronaut Node.js Django MySQL MongoDB Android React ","permalink":"https://arps18.github.io/cv/","summary":"My professional resume","title":"Resume"},{"content":"A running collection of things I\u0026rsquo;ve read and found worth keeping around books that shaped how I think, papers that sharpened my technical depth, and articles I return to. Updated as I read.\nBooks Currently Reading Designing Data-Intensive Applications — Martin Kleppmann The book on distributed systems. Replication, partitioning, consistency models, stream processing, explained in a way that actually sticks. If you build backend systems, this is non-negotiable. Finished \u0026amp; Recommended Clean Code — Robert C. Martin Dated in places, dogmatic in others, but the core instincts around naming, function size, and commenting are habits that stayed with me.\nThe Pragmatic Programmer — David Thomas, Andrew Hunt Timeless. \u0026ldquo;DRY,\u0026rdquo; \u0026ldquo;orthogonality,\u0026rdquo; broken-windows theory applied to code — concepts I reach for constantly.\nGrokking Algorithms — Aditya Bhargava The best visual introduction to algorithms I\u0026rsquo;ve found. Gave to a friend learning to code and they finished it in a weekend.\nAtomic Habits — James Clear Not a tech book, but the framing around small, compounding changes shaped how I approach long projects.\nProject Hail Mary — Andy Weir My favourite book. A lone astronaut wakes up millions of miles from Earth with no memory, tasked with saving humanity. Wildly fun, scientifically clever, one of those books that makes you genuinely excited about science again.\nAstrophysics for People in a Hurry — Neil deGrasse Tyson The universe in under 200 pages. Dense with wonder, light on jargon. Best read on a commute or right before bed when your brain still wants to be amazed.\nWings of Fire — A.P.J. Abdul Kalam The autobiography of India\u0026rsquo;s missile man and 11th President. A story of humility, curiosity, and relentless scientific ambition. Hard not to come away inspired.\nThe Psychology of Money — Morgan Housel Wealth isn\u0026rsquo;t about spreadsheets, it\u0026rsquo;s about behaviour. Short chapters, enduring lessons on how money and human psychology intersect in ways most finance books never touch.\nTo Read Database Internals — Alex Petrov System Design Interview (Vol. 1 \u0026amp; 2) — Alex Xu The Phoenix Project — Gene Kim, Kevin Behr, George Spafford Site Reliability Engineering — Betsy Beyer et al. (the Google SRE book, free online) Magazines \u0026amp; Series Tell Me Why — Manorama A monthly magazine series I grew up reading obsessively. Each issue covered one topic: Universe, Computers, Festivals, Psychology. Just enough depth to leave you wanting more, and I\u0026rsquo;d read the Universe and Computers ones cover to cover more than once. A big part of why curiosity stuck. Papers Research papers that taught me something durable about systems.\nThe Google File System (Ghemawat, Gobioff, Leung, 2003) The ancestor of HDFS and, indirectly, most modern distributed storage. Reading the original is worth the hour.\nMapReduce: Simplified Data Processing on Large Clusters (Dean, Ghemawat, 2004) Alongside GFS, this is the paper that gave us the big-data era.\nDynamo: Amazon\u0026rsquo;s Highly Available Key-Value Store (DeCandia et al., 2007) Consistent hashing, vector clocks, eventual consistency. The foundation for Cassandra, Riak, and DynamoDB.\nBigtable: A Distributed Storage System for Structured Data (Chang et al., 2006) The design still shows up everywhere. Reading this clarified a lot about how HBase and Cassandra actually work underneath.\nIn Search of an Understandable Consensus Algorithm (Raft) (Ongaro, Ousterhout, 2014) Consensus, finally explained so a human can follow it. If Paxos left you confused, read Raft.\nParkup: Smart Parking System (Patel, co-author, IRJET 2021) My own contribution, an IoT-based parking management system published in the International Research Journal of Engineering and Technology.\nArticles Short-form writing I\u0026rsquo;ve bookmarked and returned to.\nEngineering \u0026amp; Systems How Discord Stores Trillions of Messages — a great real-world Cassandra-to-ScyllaDB migration story. The Twelve-Factor App — old but still the cleanest statement of how cloud-native apps should be built. Latency Numbers Every Programmer Should Know — Jeff Dean\u0026rsquo;s classic. Memorize at least the orders of magnitude. Google\u0026rsquo;s Site Reliability Engineering Book — free online, endlessly referenced. Career \u0026amp; Craft Things You Should Never Do, Part I — Joel Spolsky on rewrites. Two decades later, still right. What I Wish Someone Had Told Me — Sam Altman\u0026rsquo;s distilled advice. Short, dense, good. Do Things That Don\u0026rsquo;t Scale — Paul Graham, aimed at founders but applicable to engineers too. Distributed Systems Deep Dives Notes on Distributed Systems for Young Bloods — Jeff Hodges. Opinionated, practical, quotable. Fallacies of Distributed Computing Explained — the eight fallacies every distributed-systems engineer eventually re-discovers the hard way. Have a recommendation? Email me — always taking suggestions.\n","permalink":"https://arps18.github.io/shelf/","summary":"Books, papers, and articles worth your time","title":"Shelf"}]