Re:Engineering dogmas it's time to retire
by disintegrator on Monday December 22, 2025 @05:23AM
(#46352904)
I generally think most of the points made in the article are a little too extreme. Even feature flags are valuable if you’re trying to get something up for certain key customers to give feedback on while you iterate as an example. There is some hygiene required around maintaining and removing flags but I think that’s in the same bucket as writing tests, updating dependencies and refactoring code: worthwhile effort that additionally unlocks testing in production.
Re:Engineering dogmas it's time to retire
by philipallstar on Monday December 22, 2025 @05:44AM
(#46353032)
> I generally think most of the points made in the article are a little too extreme. Even feature flags are valuable
From the article:
> I definitely think you should use feature flags - just not abuse them.
Re:Engineering dogmas it's time to retire
by AntonZ234 on Monday December 22, 2025 @09:52AM
(#46354555)
I don't think the right solution is to have the opposite of them - all of them have some value. The point of the article is to not follow them blindly.
Re:Engineering dogmas it's time to retire
by justincormack on Monday December 22, 2025 @05:27AM
(#46352924)
SOC 2 is in theory not that dogmatic about how reviews happen, and I do know people who do reviews after merge and deployment for example with soc2. You need to have compensating controls and work with your auditor. Most people just go with the default of reviews pre commit.
Re:Engineering dogmas it's time to retire
by disintegrator on Monday December 22, 2025 @06:42AM
(#46353389)
Yep, no dispute here. It's just that my and other people's experience is that SOC2 controls are usually passed down by edict and whether you review before or after merge, there's typically (from my experiences at SaaS/Fintech) some form of reviews happening. I've done both styles in the same company for different reasons.
The remarks about code comments are little too extreme in my opinion. Some code can be difficult to understand at face value. Like I’m writing a Vite plugin and it has code like this:
Unless you’ve written Vite/rollup plugins, which many folks haven’t, you’re going to appreciate a comment that at least points to some docs.If anything, succinct code comments that explain obscure conventions or describe relevant critical requirements are worth their weight in gold because they are valuable tokens for a coding assistant.