I build things because I want to know how they work.
real projects · weird problems · performance · automation · backend
About · Featured · Stack · Philosophy · Workflow · Projects · Stats
I'm a developer who enjoys building real projects, solving weird problems, optimizing things that probably didn't need optimizing, and then finding out why everything broke.
I like working on software where the interesting part isn't just the UI. The stuff underneath matters too — caching, APIs, concurrency, resource usage, failure modes.
| 🔨 Build real things, not demos |
💥 Break on purpose, to learn |
🔍 Understand why it broke |
⚡ Optimize measure, then fix |
┌───────────────────────────────────────────────────┐ │ HOW I BUILD │ ├───────────────────────────────────────────────────┤ │ │ │ idea │ │ ↓ │ │ prototype │ │ ↓ │ │ break it │ │ ↓ │ │ understand why │ │ ↓ │ │ optimize │ │ ↓ │ │ test it │ │ ↓ │ │ ship it │ │ │ └───────────────────────────────────────────────────┘
I don't particularly care about writing the most code. I'd rather write less code that does less unnecessary work.
Backend systems that are lightweight, cached, and measured — not guessed.
caching → APIs → automation → infra → performance
I'm most interested in the stuff underneath the UI:
| System | What I work on |
|---|---|
| ⚡ Caching | Reducing unnecessary requests |
| 🔌 APIs | Connecting systems together |
| 🤖 Automation | Making repetitive work disappear |
| 🧠 AI / LLMs | Experimenting with useful AI workflows |
| 🖥️ Infrastructure | Keeping things lightweight and reliable |
| 📊 Performance | Measuring instead of guessing |
flowchart TB
REQ["Request / Job"] --> API["🔌 APIs"]
API --> CA["⚡ Caching Layer<br/>reduce repeat work"]
CA --> AU["🤖 Automation"]
AU --> INF["🖥️ Infra<br/>lightweight + reliable"]
INF --> PERF["📊 Performance<br/>measure, don't guess"]
PERF --> AI["🧠 AI / LLM Experiments"]
🧩 View as terminal map (same idea, text version)
Request / Job
│
▼
APIs (glue)
│
▼
Caching layer
(avoid repeat work)
│
▼
Automation + Infra
(lightweight + reliable)
│
▼
Performance + AI tests
(measure, then experiment)
⚙️ What “infrastructure” means here
Get it correct before making it fast — then make it cheap.
Caching sits in front of repeated work — if we already know the answer, don't recompute it.
Automation removes the repetitive glue so the system stays maintainable.
Measure real behavior — resource usage, failure modes, bottlenecks — instead of guessing.
A lightweight Python module that identifies the game associated with a YouTube video — without throwing a giant stack of dependencies at the problem.
| Step | Question it answers |
|---|---|
| 1. Problem | How do we detect a game without a browser, without an LLM, without bloat? |
| 2. Approach | Validate → check memory → check disk → fetch once → extract → store |
| 3. Architecture | L1 memory + L2 SQLite + single-flight HTTP |
| 4. Optimization | Coalesce callers, bound concurrency, TTL everything |
| 5. Testing | Automated tests + resource measurements |
| 6. Result | Predictable, lightweight, graceful under failure |
Problem ↓ Approach ↓ Architecture ↓ Optimization ↓ Testing ↓ Result
flowchart TD
VID["YouTube Video"] --> VAL["Validate ID"]
VAL --> L1{"L1 Memory Cache?"}
L1 -- "HIT" --> RET1["Return"]
L1 -- "MISS" --> L2{"L2 SQLite?"}
L2 -- "HIT" --> RET2["Return"]
L2 -- "MISS" --> HTTP["Single HTTP Request"]
HTTP --> EXT["Extract Game"]
EXT --> STORE["Store L1 + L2"]
STORE --> RET3["Return"]
📟 Same flow as terminal diagram
YouTube Video
│
▼
Validate ID
│
▼
L1 Memory Cache
│ │
HIT MISS
│ │
▼ ▼
Return L2 SQLite
│
┌────┴────┐
│ │
HIT MISS
│ │
▼ ▼
Return HTTP request
│
▼
Extract game
│
▼
Store result
│
▼
Return
| ✅ No browser automation | ✅ No LLM calls | ✅ Minimal dependencies |
| ✅ Two-level caching | ✅ SQLite persistence | ✅ Request coalescing |
| ✅ Bounded concurrency | ✅ TTL-based expiration | ✅ Graceful failures |
| ✅ Automated tests | ✅ Resource measurements | ✅ Predictable memory usage |
When multiple callers ask for the same video simultaneously, they shouldn't all independently hit YouTube.
Instead:
Caller 1 ─┐
Caller 2 ─┤
Caller 3 ─┼──► ONE HTTP REQUEST
Caller 4 ─┤
Caller 5 ─┘
│
▼
Shared result
That's the sort of optimization I enjoy finding — one request does the work, everyone shares the result, the cache makes the next call free.
🔬 Engineering decisions (expand)
No browser: launching a browser for something solvable with one HTTP request is waste.
No LLM: classification here doesn't need inference — it needs parsing + caching.
L1 + L2: memory for speed, SQLite for persistence across restarts.
TTLs: cached truth goes stale — expire it on purpose instead of serving lies forever.
Bounded concurrency: parallelism without a limit is just a slower DDoS against yourself.
Graceful failure: upstream fails → return something sane, don't take the whole system down.
Tests + measurements: RAM, behavior under concurrent load, weird IDs — tested, not assumed.
REST APIs · Async Programming · Caching Strategies · Request Coalescing Background Workers · Rate Limiting · Database Design · Error Handling Logging & Monitoring · CI/CD Pipelines
AI / LLMs · Cloud Infrastructure · Backend Architecture Performance Engineering · Automation · Distributed Systems Linux Internals · Developer Tooling · React Ecosystem Container Orchestration · Observability · Security Best Practices
I like solving problems that look something like this:
BEFORERequest arrives │ ▼ Do expensive thing │ ▼ Do expensive thing │ ▼ Do expensive thing │ ▼ Return result AFTER Request arrives │ ▼ Check memory │ ┌────┴────┐ │ │ HIT MISS │ │ ▼ ▼ Return Check DB │ ┌────┴────┐ │ │ HIT MISS │ │ ▼ ▼ Return One request │ ▼ Cache it │ ▼ Return
And when something does need to be complicated, I want to know why.
less code ↓ less complexity ↓ less work ↓ less resource usage ↓ fewer failure points
Can I avoid the request?
↓
Can I cache the result?
↓
Can requests share the same work?
↓
Can concurrency be bounded?
↓
Can failure be graceful?
How much RAM does this actually use?Not:
"It should be fine."But:
measure it
test it
stress it
find the limit
"It feels faster" isn't a measurement.
I like benchmarks because feelings don't scale. Numbers do — as long as you're measuring the right thing.
➜
➜
➜
➜
➜
➜
➜
flowchart TD
A["💡 IDEA"] --> B["🧪 PROTOTYPE"]
B --> C["💥 BREAK IT"]
C --> D["🔍 UNDERSTAND WHY"]
D --> E["📏 MEASURE"]
E --> F["⚡ OPTIMIZE"]
F --> G["🧪 TEST"]
G --> H["🚀 SHIP"]
📟 Terminal version of the loop
$ build --idea "clip youtube fast" [1/8] prototype ......... done [2/8] break it .......... done (of course) [3/8] understand why .... reading logs at 2am [4/8] measure ........... no guessing, numbers only [5/8] optimize .......... cache > repeat [6/8] test .............. weird cases included [7/8] ship .............. people can actually use it [8/8] repeat ............ more bugs, more learning
┌──────────────────────────────────────────────┐ │ 01 Measure before optimizing │ │ 02 Cache before repeating work │ │ 03 Fail gracefully │ │ 04 Keep dependencies intentional │ │ 05 Prefer simple systems │ │ 06 Test the weird cases │ │ 07 Understand the bottleneck │ │ 08 Don't optimize imaginary problems │ │ 09 Automate repetitive work │ │ 10 Ship things people can actually use │ └──────────────────────────────────────────────┘
Something nobody notices until you look closely.
For example:
"Why are we making 10,000 requests?""Why does this use 500 MB?"
"Why are five workers doing the same thing?"
"Why does this work until two users arrive?"
"Why are we launching a browser for something that could be solved with one HTTP request?"
Those are fun problems.
I use AI as a tool, not as a replacement for understanding the software.
My preferred workflow is roughly:
flowchart TD
A["Human idea"] --> B["AI-assisted exploration"]
B --> C["Prototype"]
C --> D["Read the code"]
D --> E["Break the code"]
E --> F["Understand the code"]
F --> G["Fix the architecture"]
G --> H["Test"]
H --> I["Ship"]
Human idea
↓
AI-assisted exploration
↓
Prototype
↓
Read the code
↓
Break the code
↓
Understand the code
↓
Fix the architecture
↓
Test
↓
Ship
The goal isn't to generate more code. The goal is to build better software faster — while still knowing how every important piece works, why it's shaped that way, and what happens when it fails.
| AI helps with | I still own |
|---|---|
| exploration + boilerplate | architecture decisions |
| debugging hypotheses | performance tradeoffs |
| test scaffolding | final code review |
| docs + automation | shipping responsibility |
| Project | What it does | Technology | Interesting technical detail |
|---|---|---|---|
| 🎮 Game Sorting | Lightweight YouTube game detection → cached result | Python · SQLite · Caching | L1 + L2 cache, request coalescing, bounded concurrency, TTLs — no browser, no LLM |
| 🌐 boink_2068 | Personal website / experimental web project | JavaScript · Web | Playground for trying web ideas fast and breaking them safely |
More experiments, tools and projects will keep appearing here as I build them.
|
📈 Stats |
🧠 Top Languages |
|
🔥 Streak |
|
I'm constantly working on becoming better at:
| Area | Why it matters to me |
|---|---|
| 🏛️ Software architecture | Bigger systems need cleaner boundaries |
| 🔧 Backend engineering | APIs, caches, workers, and databases |
| 🐧 Linux internals | Understand what the machine is really doing |
| ☁️ Cloud infrastructure | From laptop prototype → reliable service |
| ⚡ Performance optimization | Measure, cache, coalesce, repeat |
| 🤖 AI-assisted development | Better software, faster — without losing understanding |
| 🤖 Automation | Repetitive work should disappear |
| 🏗️ Building larger systems | Prototypes are easy, systems are hard |
| 🛠️ Maintaining projects | Software lives after the first commit |
| 🔁 Prototypes → reliable software | Turning experiments into things people can use |
AI / LLMs · Cloud Infrastructure · Backend Architecture Performance Engineering · Automation · Distributed Systems Linux Internals · Developer Tooling · React Ecosystem Container Orchestration · Observability · Security Best Practices
I'm still early in the journey, which means there is a lot left to learn.
There will be:
more projects more bugs more experiments more optimizations more terrible ideas more surprisingly good ideas
And hopefully, a lot more things worth showing here.
Curiosity + questionable amounts of debugging + probably too many optimizations.
