u/Motor_Ordinary336

yes it has persistence. yes you can technically store data in it and have it survive a restart. no that does not make it your source of truth and im tired of pretending the AOF/RDB thing makes this an actual debate

watched a team lose a few hours of user sessions last year because someone decided redis was the session store, no postgres behind it, nothing. box got restarted during a routine deploy, the snapshot was however many minutes stale, everyone got logged out mid-checkout. the postmortem treated it like some freak event and not the completely predictable result of using an in-memory cache as your only copy of something you cared about

the thing is redis is genuinely incredible at what its for. caching, pub/sub, rate limiting, ephemeral counters, a leaderboard, a lock. its so good at being fast that people start reaching for it for everything and forget the fast comes from it living in memory, which is the exact property that makes it a bad place to keep the only copy of anything

and i get why it happens. its right there, its already in the stack, adding a real write to postgres feels like more work than just SET and moving on. but durability isnt a feature you bolt on later when it bites you, its the whole reason databases are annoying to work with in the first place. the annoying parts are the point

persistence is not durability. a snapshot every few minutes is not a transaction log. eventual-on-a-good-day is not the same as committed

use it for what its great at. put the stuff you cant lose somewhere that was built to not lose it. this isnt even a hot take its just what the docs have been saying the whole time and somehow we;re still here

yes it has persistence. yes you can technically store data in it and have it survive a restart. no that does not make it your source of truth and im tired of pretending the AOF/RDB thing makes this an actual debate

watched a team lose a few hours of user sessions last year because someone decided redis was the session store, no postgres behind it, nothing. box got restarted during a routine deploy, the snapshot was however many minutes stale, everyone got logged out mid-checkout. the postmortem treated it like some freak event and not the completely predictable result of using an in-memory cache as your only copy of something you cared about

the thing is redis is genuinely incredible at what its for. caching, pub/sub, rate limiting, ephemeral counters, a leaderboard, a lock. its so good at being fast that people start reaching for it for everything and forget the fast comes from it living in memory, which is the exact property that makes it a bad place to keep the only copy of anything

and i get why it happens. its right there, its already in the stack, adding a real write to postgres feels like more work than just SET and moving on. but durability isnt a feature you bolt on later when it bites you, its the whole reason databases are annoying to work with in the first place. the annoying parts are the point

persistence is not durability. a snapshot every few minutes is not a transaction log. eventual-on-a-good-day is not the same as committed

use it for what its great at. put the stuff you cant lose somewhere that was built to not lose it. this isnt even a hot take its just what the docs have been saying the whole time and somehow we;re still here

we started with a giant one nobody read. 20+ items, half obvious, half too vague to mean anything. "test coverage adequate" was on there, which sounds useful until you realize every reviewer interprets it differently and mostly just skips it. we scrapped it and started over

so current version has three sections. automated stuff: tests pass, lint clean, Coderabbit, Bugbot, Claude and Codex final reviews all come back clean, build succeeds. that part is basically just "did CI not explode." then author stuff: description filled out, ticket linked, screenshots for UI changes. reviewer stuff: business logic correct, error handling checked, edge cases considered, no N+1 queries (we got burned on that enough times it gets its own line now)

the thing that actually changed how reviews went was telling reviewers explicitly not to comment on style. thats what automation is for. sounds obvious but we had people leaving formatting nitpicks when they should've been thinking about whether the thing actually works

shorter checklist gets followed. the comprehensive one we had before, people would skim it in 10 seconds and move on. current one is short enough that each item requires a real answer

we keep it as a PR template so it auto-populates. probably the most useful change honestly, having it there by default means the author can't "forget" to fill it out

what does yours look like, do you separate author vs reviewer responsibilities or just one list

i keep seeing twitter arguments about whether next.js 16 or remix or tanstack start is the future, meanwhile im just shipping stuff in django and nobody talks about it

the admin alone has saved me probably a month of work this year across like 3 small projects. nobody else has anything close to it. you get a working backoffice for free, real auth, real permissions, real CRUD, the moment you define your models. it isnt sexy and nobody screenshots it on twitter but its incredible

the ORM gets clowned for being "opinionated" or "magic" but in practice it just stays out of the way. ive been writing django apps for years and i still find query patterns that work first try. compare that to fighting prisma or drizzle migrations at 11pm trying to figure out why the relation isnt generating

async support is finally in a place where i dont have to think about it. every async question on django used to be answered with "well it depends." now its just working

last month i shipped a small saas mvp in like three weeks. django + htmx, no build step, no node_modules folder eating my SSD, no vite config, no tailwind compile pipeline, just python rendering html. felt almost illegal how little setup it needed

the lack of hype is actually a feature at this point i think. nothing new to learn every 6 months, patterns that worked in 2018 still work, you can google (if you still do at least) something and answer from 7 years ago is still correct. boring tech is its own kind of productivity

idk maybe everyone else is right and im missing out on something fundamental, but every time i try to start a project in some modern js stack i lose half a day to tooling before writing a single line of business logic

we've had a few new grads join in the last year and i keep watching them hit the same wall around month 3. they can build things from scratch just fine. what they cant do, at least not without struggle, is open a 5 year old codebase with 12 contributors who all named things differently and figure out where to make a one-line change

and like, that is the job. for most engineers at most companies, building something new is maybe 20% of the work. the rest is reading code other people wrote, figuring out why a function does something that doesnt make sense (it made sense in 2021), tracking down which of the 4 helper functions named almost the same thing is the one actually used in production

every CS class i remember had you writing things from zero. clean slate, fresh repo. all good exercises but they teach one half of the job and not even the bigger half

what would actually help is a class where on day 1 the professor hands you a github repo someone wrote 3 years ago, inconsistent naming, partial test coverage, a few comments that contradict the actual behavior. your job for the semester is to add a feature, fix a bug, write better tests. thats it.

not a dunk on new grads, theyre often sharper than i was. its more that we set them up to feel competent in school and then drop them into something that requires a totally different skill nobody taught them. takes most of them 6-12 months to build it, which is rough on them and on the team

every senior i know has this same observation and we all kind of shrug. but if i could change one thing about the curriculum it would be that

incident last tuesday took about 2 hours page to resolved, the actual code change to fix it was 4 lines, like 15 minutes tops. the other 1h45 was just figuring out what was broken

walked through it the next day because i was curious. page at 11pm, payment service p99 spiking. opened datadog, nothing obvious. checked recent deploys, nothing. searched slack for "payment" and found a thread from earlier about a config change in a different service, had to read like 30 messages to piece it together

back to datadog, checked upstream deps, found one of them had been quietly degraded for 40 minutes. checked THAT service's deploys, found the offending PR, read the diff, fixed it. 8 tool switches. whole 90 minutes of context-piecing before the actual coding part even started

and this is just every incident now. the fixing is easy. the HUNTING is the job. theres no playbook, you just have to know which threads to pull. the more services you have the worse it gets, every incident might involve any 3 of 30 services and you dont know which 3 until you've already spent an hour. its insane

our setup right now is pagerduty for alerts, datadog for traces, github for deploy history, slack for everything else. recently added the coderabbit agent in slack which pulls from datadog and github together so the "what shipped recently to this service" question is one message instead of three tool switches. helps with the deploy-archaeology part. doesnt solve the cross-service stuff which is where most of the hunting time goes

post-mortem the next day takes another hour to write and nobody reads it. the knowledge from each incident just EVAPORATES and the next on-call does the same hunt from scratch

(on-call rotation hasn't been adjusted in 18 months despite adding like 12 services, separate rant)

the actual problem-solving part of being an engineer used to be most of the job. now it feels like 20%. the rest is investigation across tools that were never designed to talk to each other and im honestly not sure how this is sustainable for another 5 years

so we're team of 5, did the math on our ai tooling spend last month and i think i finally crossed from "rounding error" into "actually i should care about this"

cursor teams for everyone, claude team plan ($100/seat), coderabbit on every PR, codex, plus random one-offs people expensed during 2 week excited phases. just the four core tools came out to about $945/month. like $189 a HEAD which is more with some extra tools we have. team of 5

i sat with that number for a minute because it didnt feel real. in my head we were spending maybe $300-400, the actual figure was way past that, claude team plan alone is half the bill which i dont think most people clock until they look at the invoice. like literally $500/month just on claude

so i started tracking which tools get used every single day vs which ones are basically subscription tax for peace of mind. results were not what i expected:

cursor, used constantly, obvious keep. claude, also used constantly so obvious keep. coderabbit runs on every PR automatically, kept. codex, this one is the most replaceable honestly, two people on the team use it heavily and the other three barely touch it. probably should be 2 seats not 5 if im being real. the random expensed stuff (some api costs, extra analytics tool), basically zero ongoing use after the initial novelty wore off

ok anyway what i actually realized is the question isnt really "which tool is best." everyone benchmarks and argues gpt-5.5 vs opus 4.7 vs new chinese model. the real question is which tools you actually integrate into your daily workflow vs which ones you bought because of FOMO and a coworker said it was good once

cursor and claude are ride-or-die because we built the actual workflow around them. coderabbit runs without anyone needing to remember to use it codex is half-used and we havent right-sized the seats yet. everything else is basically marketing tax

the bigger thing tho, costs are sneaking up across the whole stack and nobody at most companies is tracking it. i bet 80% of companies running AI subs have at least 30% waste just from people signing up during a 2 week excited phase and never canceling

next quarter im doing the same audit on observability tools because i suspect that line item is even WORSE

this is not a complaint post exactly. Cursor is the best editor experience i've had in years, i'm not going back to vscode, etc. All the usual stuff

But i had a moment yesterday that's been stuck in my head. I was building out a feature in Cursor, switched to Claude Code in the terminal to run a migration, came back to Cursor, opened a PR, Coderabbit reviewed it, then i used Codex in a different repo later that evening. Four tools. Zero of them had any idea what the other ones had just done

for exampile the migration i ran in Claude Code directly affected the PR i was opening. Coderabbit had no context that the schema changed, so it flagged stuff that was intentional. Cursor itself didn't know why certain types looked weird because the migration context lived somewhere else entirely. I spent more time re-explaining what i'd already done than actually doing new work for like an hour

And this is with tools that are individually great. That's the weird part. Each one of them does its job well. The friction isn't inside any single tool, it's in the gaps between them (at least it what happens most of the time)

I don;t know what the fix looks like. Some kind of shared context layer i guess. Probably nobody wants to build that because it means trusting your context to five different vendors at once which is a whole other can of worms

I keep noticing how much of my AI workflow is actually me being the glue between tools that don't know each other exists

Two juniors on my team. Both ship fast. Both grew up on Cursor and Claude Code basically

last week one of them pushed something that broke in staging and I watched them paste their own function back into Claude going "what does this do." code they wrote on monday. THEIR OWN CODE. that they merged

I know how I sound. every senior ever has complained about juniors not knowing X and I swear I'm trying not to be that guy. but when I came up you had no choice but to sit with broken shit for hours and slowly build a map of the system in your head, and that part sucked but it's also where the actual learning lived (for me anyway). now you don't have to suffer through it. you just ask.

(not an anti-AI post btw, I use it constantly)

year 1 is fine, year 1 they ship features. it's year 5 I keep thinking about. one of them on call at 2am, prod doing something insane, AI confidently wrong, and they need to reason through an unfamiliar codebase under real pressure. I don't know what that looks like for someone who never built the muscle