iiinova — where your digital self keeps evolving

you can model "I don't know" all day. doesn't matter. the first time someone gets burned for admitting they were lost, the whole team learns to go quiet for months. safety isn't saying you value it. it's never once punishing it.

000

writing made me a better engineer, not just a more visible one. you can't explain a messy idea simply until you actually understand it. forcing yourself to write it down clearly is the same muscle as shipping a small PR...you have to understand the shape of the thing before you can make it small.

000

wow, they made a lot of Saw movies 🍿

000

most decisions stuck in "pending alignment" for weeks are reversible. that's the part everyone forgets. you can ship the simple 80% version behind a feature flag, see if it's on track, and kill it if it's not. planning paralysis is usually a reversible decision treated like a one-way door.

100

fighting the code teaches you how systems break. owning what you shipped and getting burned teaches what's worth protecting. AI mostly takes the first away. the sneaky risk is it takes the second too...code shipped so fast nobody really owns it, so neither lesson ever lands.

020

"fire fast, attitude over talent" is dangerous in the wrong hands. a leader who isn't good at healthy conflict can't tell a toxic person from a valuable one who pushes back. so the slogan purges the dissenters. firing fast is easy. telling toxic apart from uncomfortable is the real skill.

110

Last week I showed my risk filter flagging a dark-theme CSS change as touching auth, billing, and secrets. Wrong, for a dumb reason...it decides what's "sensitive" by matching file paths against sensitive-sounding names. So how should it actually know? 🧵

100

"nobody's buying it" is two completely different problems wearing the same face. one is "they don't want it." the other is "they don't know it exists." marketing only fixes the second...if nobody wants the thing, better distribution just helps more people find out faster.

110

alert fatigue is silent failure wearing a different mask. instrument everything and the one alert that matters gets scrolled past with the other 200. nobody saw it break...not because it was quiet, because it was buried. too loud and too silent lose the signal the same way.

110

moving fast tells you "if quality slips, we fix it next sprint." that works for the misses you can see. the dangerous ones don't wait for next sprint though...they show up as an incident, on their own schedule. the corner you cut and the bill for it rarely land in the same week.

000

a feature flag's default flipped a dead feature back on, and we didn't catch it...a user did. nothing was watching for a code path that hadn't run in a year suddenly running. you don't need much. just something that raises a hand when dormant code wakes up.

000

Browse and read books in an interactive 3D bookshop.

this is super cool, a digital bookstore you can actually “walk around” and discover books like you do in an actual store 😍📚 comparisontabl.es/3d-bookshop

comparisontabl.es

3D Bookshop

122

Jake Lundberg @jakelundberg.dev · 25/06/2026

the clearest signs of real engineering discipline live at the edges of the work. how did a team decide to build this at all? and after shipping, did they check how it got used and iterate? clean code is cheap now. the decision going in and the follow through coming out are the hard parts to fake.

000

Jake Lundberg @jakelundberg.dev · 25/06/2026

1/ Someone on my team deleted a feature flag that had been off for over a year. It looked completely safe to remove. It turned a feature back on. How "cleanup" became an accidental deploy 🧵

100

Jake Lundberg @jakelundberg.dev · 25/06/2026

watched a junior i mentored years ago go from second guessing everything to fully trusting their judgement. most of that shift is evidence...they make calls, the calls work, the proof stacks up. but not all of it. it's a lot easier to trust yourself when someone you respect already trusts you first.

000

Jake Lundberg @jakelundberg.dev · 24/06/2026

The "safe" engineering choice is often the riskier one. Weeks of dual writes, backfills, and cutover machinery is a huge pile of moving parts, each one a place to be wrong. Sometimes a planned 10-minute lock is genuinely lower risk. Complexity you added to avoid risk is still risk.

000

Jake Lundberg @jakelundberg.dev · 24/06/2026

"make it work, make it right, make it fast." everyone warns about jumping to "make it fast." but the step that actually gets skipped is "make it right." it works, it ships, the team chases the next thing, and "right" never comes. shipping it half-done is the quiet killer, not optimizing too early.

000

Jake Lundberg @jakelundberg.dev · 23/06/2026

you catch quiet disengagement by watching the person's delta. the person who always pushed back suddenly going quiet is the signal...and it causes zero problems for weeks, which is exactly why managers miss it. we're trained to triage noise, not to notice silence.

000

Jake Lundberg @jakelundberg.dev · 23/06/2026

"why pay $29/month when i can build it?" the $29 was never for the build. it was for someone else owning the wiped database, the security hole, the 2am page...forever. build it yourself and you don't save the money. you just become the vendor for something that isn't even your product.

000

Jake Lundberg @jakelundberg.dev · 22/06/2026

being willing to ruin someone's day with a hard truth matters. but it's only half the job. what makes that truth land as care instead of an attack is whether they already trust you're in their corner. the same hard words land completely differently depending on the trust you built beforehand.

000

Jake Lundberg @jakelundberg.dev · 22/06/2026

deleting a feature flag doesn't delete the feature. it hands the decision to whatever your code falls back to when the flag is gone. years ago we deleted one that had been off for a year...the code defaulted to true, and a dead feature switched itself back on. "cleanup" was a deploy.

000

Jake Lundberg @jakelundberg.dev · 20/06/2026

how much autonomy you give an AI agent shouldn't be a label you pick when you write the plan. it should track the blast radius of the actual change. the diff that bites you usually looks boring...config only, CI green, so it gets a merge it never really earned

010

I have a new found respect for new founders. the time it takes to not only build the product, but to also handle marketing, user research, and sales is crazy!

000

an LLM won't stop and ask what a good senior asks before writing anything...is this the right approach for where this is heading? what cheap groundwork should we lay now while it's simple? it just builds what you asked, scoped to today. the forward-looking judgment has to come from you now

000

slow builds did quiet work nobody credited them for. shen writing code took real effort, you'd feel a bad design halfway in...this is dragging, the abstraction's wrong, back up. the build was a brake on bad decisions. AI took the brake off, so now you can build the wrong thing fast and all the way

000

Jake Lundberg @jakelundberg.dev · 17/06/2026

TDD protects the moment a test is born. writing the test first genuinely constrains the code...you can't ratify what isn't written yet. but the next update edits them to match the new behavior, and you're back to a test that ratifies the change instead of guarding against it

000

teach your juniors that "i don't follow why this works" is a real code review comment, maybe the most useful kind. confusion is signal...it flags code that might be too complicated, and it opens a teaching moment. juniors stay quiet because they think review means catching a senior's mistakes

000

Jake Lundberg @jakelundberg.dev · 17/06/2026

even in crunch i keep at least 30 minutes a week with each person on my team, no matter what's on fire. it's not a reward for a calm week...it's the first thing i protect, because support doesn't get impossible under pressure, it just quietly stops being a priority

000

Jake Lundberg @jakelundberg.dev · 17/06/2026

the best interview signal i've found is whether they can go "off script" or not. someone who actually knows the work can have a real conversation about it. someone who memorized it falls apart the moment you ask a follow up that's not a "standard" interview question they didn't prepare for

000

AI didn't kill the way juniors learn in code review. that loop was already weak. by the time comments land, the dev has moved on, they've got a dozen PRs open, and most feedback is "do it this way" with no why. AI just made it obvious the loop was barely running

000

under a tight deadline, the first work to get cut is the work whose absence doesn't show up in a demo. tests, edge cases, "what happens when this fails" thinking. nobody decides to skip it. you just can't see what you didn't do, so it quietly loses every time the clock is the constraint

000

"Just have someone familiar with the code review it" assumes familiarity is fixed. It isn't...it fades over time the code you wrote six months ago is effectively someone else's code now. a familiar reviewer is a moving target, not a permanent property of a person

000