Alright, let’s talk about my whole mess figuring out these “always” and “never” statements thing. It started because I was getting seriously annoyed, like, every single day.
The Frustration Point
I kept seeing the same stupid stuff happening on projects. Stuff we knew would blow up later. Stuff like:
- Someone committing code without any test? Yep.
- Big features getting pushed without any kind of docs explaining it? Oh yeah.
- People just quietly deleting chunks of code like it was nothing? Absolutely.
And then, surprise! Things break, everyone points fingers, nobody knows why some old feature suddenly died, and we waste days digging through git history like detectives. Total nightmare fuel.
The “Duh” Moment
After the third fire drill in a month, I finally snapped. This felt way too much like letting toddlers play with matches and being shocked when the sofa caught fire. We needed actual rules. Clear lines you don’t cross. That’s when I stumbled into the “Always/Never Statement” idea.
My Clumsy First Attempt
My first go was super rough. I just grabbed a whiteboard during lunch (literally) and started shouting out things that made me angry:
- “We should ALWAYS write a test if we touch this critical payment module!”
- “We should NEVER merge into main without a peer review, EVER!”
- “We should ALWAYS update the damn wiki when we change an API!”
It felt good to yell it out, honestly. My teammates stared at me like I was nuts, but slowly… heads started nodding.
Making it Real (and Less Angry)
Yelling wasn’t gonna fix things. We needed to actually use this stuff. So, we sat down for a proper team chat:
- Brain dump time. Everyone threw out examples of things that consistently went wrong. Like, “Someone always pushes a config change that breaks staging.”
- Turn pain points into rules. That became: “ALWAYS validate config changes locally OR NEVER push directly to main/staging configs – use the deployment tool!”
- Keep it simple & action-focused. No fancy jargon. Stuff like “ALWAYS write a brief release note summary.” “NEVER delete database columns without an agreed-upon deprecation process.”
- Write them down and shout them out. We made a public doc – super basic, just bullet points. And we started sticking them right in PR templates and onboarding guides.
The First Test Run (Spoiler: There Was Fire)
It wasn’t smooth sailing. Of course not!
- Old habits die hard. Someone tried sneakily deleting old code (“It was dead anyway!”), broke a dependency, and someone else immediately pointed at the newly minted “NEVER delete code unless cleared through X, Y, Z process” rule. Mic drop moment.
- A new guy pushed a feature with zero docs. Team lead linked the “ALWAYS update feature documentation” rule. He fixed it fast.
Seeing the rules actually stop the predictable stupid stuff? Amazing feeling. Like putting up guardrails and watching people stop driving off the cliff.
Where We’re At Now
It’s still evolving. We add new rules as new pain points emerge. We debate them sometimes – if a rule is constantly ignored or feels dumb, we revisit it. But having that explicit list?
Pure gold. Fewer disasters. Less finger-pointing when things do go wrong because the rule break is obvious. New people onboard way quicker – they know the big no-nos right away. It’s not magic, it’s just finally being honest about the dumb stuff we kept doing and putting up a tiny sign that says “Seriously, Don’t.”
Still messy, still frustrating sometimes, but way, way less chaotic. Totally worth the initial lunchtime rage.
