so apparently the police don’t allow people to file Protection from Abuse (PFA) requests until the weekdays…🙄

nothin like a little Mario Kart 64 out in the front yard with the neighbors

a founder never feels "tech debt." it's engineer-speak. what they feel is the checkout down at peak, or the senior who just quit. half of getting buy-in to fix it is translating the cost out of engineer terms into the thing they already lie awake about. it's a skill plenty of us are still learning.

the two ways to fail as a new EM are opposites: become an IC with extra meetings, or vanish into calendars with no technical air cover. but they aren't equally likely. the gravity only pulls one way, back toward the keyboard, because that's where the fast feedback is.

"Reduce friction" is half a sentence. Two kinds. Accidental friction...env setup, hunting for docs, chasing permissions...kill it, no argument. Essential friction...the "wait, should we?" before you touch auth or billing...that's the cheapest insurance you have. The skill is telling them apart.

"I'll just build it instead of paying $29 a month" wins almost every argument, for one reason: the ops cost never shows up as a line item. the build is visible. the years of owning it aren't. so it always looks cheaper than it is. you didn't save $29...you hired yourself.

"keep criticism private" is right for the person and wrong for the work. critique of someone, always private. critique of the idea has to happen out loud, or you quietly teach the team that challenging anything is rude. you can protect people without making the work un-challengeable.

a paved road is a risk sorter. automate the common path and the 80% that stays on it is probably fine...not guaranteed, just better odds. which means almost all your real risk now sits in the 20% that left the road, the novel work with the least automation around it. point your attention off-road.

a PR that has sat as a "draft" for 25 days with failing CI and no activity is not work in progress. it is a stale PR wearing a draft label as camouflage. draft is a status someone set once, not proof the thing is still being worked on.

you can tell within weeks which new manager you got. the ones who show up certain they already know what's broken...everything feels on fire. the ones who show up asking questions, things just run smoother. the team always knew the real problems. listening was the only thing that unlocked them.

everyone says the boring layer is a moat because AI fumbles it. that's not quite it. deploy, data, migrations, security...that's where risk actually concentrates, so it's where ownership and judgment matter most, because it's where things break. boring is a moat because it's where the risk lives.

Startups list a dozen traits they want in engineers...comfort with ambiguity, self-direction, speed over perfection. They're all the same trait wearing different hats: can you make a good call when nobody hands you the call. Judgment in the absence of instruction. That's the whole job.

nobody drifts toward more management. new managers slide back to code because it has a fast feedback loop...it compiles, it ships, you did something today. management's payoff is slow and murky, so you retreat to what pays off by end of day. balance isn't a point you find, it's a pull you fight.

line count tells you how long a PR review will take, not how much damage the change can do. a 2,000-line refactor is a long read. a 200-line change in billing or a migration is a blast radius. keeping PRs small is certainly helpful, but it's not a silver bullet to reducing risk.

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.

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.

wow, they made a lot of Saw movies 🍿

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.

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.

"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.

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? 🧵

"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.

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.

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.

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.

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

3D Bookshop

Browse and read books in an interactive 3D bookshop.

comparisontabl.es

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.

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 🧵

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.

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.