Pravin Ireri

now

building nest friends backend

distributed systems, api design

leading engineering team

architecture decisions, code reviews

learning what breaks at scale

the hard lessons only production teaches

work

Engineering Lead

problem

scaling a social platform backend without the usual chaos.

approach

keep the architecture boring. postgres, redis, typescript. no microservices until absolutely necessary.

impact

system handles 10x traffic with the same team size. deploys are uneventful (the best kind).

what i learned: most scaling problems are organizational, not technical.

what broke: tried to optimize too early once. learned patience.

AI Research

problem

language models fail in ways that are hard to detect.

approach

built evaluation pipelines that catch silent failures. focus on edge cases.

impact

reduced production incidents by 40%. team sleeps better.

what i learned: ai systems need more skepticism, not more features.

Instructor

problem

kids learn to code but not to think.

approach

start with problems, not syntax. let them struggle productively.

impact

students built projects they actually cared about.

what i learned: teaching clarifies your own understanding. explaining is debugging.

systems philosophy

if i can't explain it, it's probably wrong.

complexity is debt. every abstraction should earn its place. i prefer systems a new engineer can understand in an afternoon.

// bad: clever
data.reduce((a,b) => ({...a, [b.k]: [...(a[b.k]||[]), b]}), {})

// good: obvious  
const grouped = groupBy(data, 'category')

boring technology wins.

postgres over the new hotness. proven patterns over novel architectures. the best infrastructure is invisible.

// i like this stack:
// - postgresql (it does more than you think)
// - redis (for the things postgres shouldn't do)
// - typescript (types catch bugs before users do)

the best code is the code you delete.

every line is a liability. i regularly audit what we don't need. unused features are silent complexity.

// before: 2,400 lines
// after: 800 lines
// same functionality
// easier to change

i think about systems like gardens — they need regular pruning, not just new features. the goal is a codebase that feels smaller over time, not larger.

ownership log

jan 2026

realized most bugs are communication failures.

spent a week debugging what turned out to be a misunderstanding between two teams.

dec 2025

removed more code than i wrote. felt good.

deleted 1,200 lines of 'just in case' code. nothing broke.

nov 2025

started saying no to features. harder than expected.

every feature is a commitment. learning to protect the team's focus.

oct 2025

refactored the same thing three times. each time simpler.

first version: 400 lines. final version: 80 lines. same behavior.

sep 2025

learned that documentation is just delayed thinking.

if it's hard to document, the design is probably wrong.

aug 2025

hired someone smarter than me. best decision.

the team improved faster when i stopped being the bottleneck.

jul 2025

first on-call rotation where nothing happened.

boring is beautiful. systems should let you sleep.

skills & tools

typescript

python

postgresql

redis

node.js

aws

docker

terraform

kubernetes

rust

system design

pravin ireri

Nest Friends

Handshake

Code Ninjas