3 ms·

> Much of the time I’m using flags so I can commit unfinished code There are two interpretations of this, and I find one of them horrifying 1. I'm working on

by wrsh07 3y ago

> Much of the time I’m using flags so I can commit unfinished code There are two interpretations of this, and I find one of them horrifying 1. I'm working on a feature, I need to update multiple components, so I make small changes for each component and feature flag those (this is fine! Totally normal) 2. I commit code that doesn't work because I'm unwilling to use or understand git The second of these scares the crap out of me. Why? Doesn't it feel like a bit of a footgun to have broken code deployed? However, I like most of the other comments of the essay - deploys should be easy! That makes rollbacks safe and easy. Using bool flags is fine too - imo feature flagging systems are best at de risking expensive deploys. If you have an expensive deploy (thinking at least 20m to deploy prod) and you have staging which mirrors prod (probably also 15-20m to deploy staging), then any commit you want to deploy to fix or revert a change in prod is going to cost you a lot of time or hassle. Feature flags give you a mechanism to instantly rollback. But it sounds like you already have that - it's called your normal deploy.

WorldMaker 3y ago
"Broken code" "deployed" inside an `if (false) {}` (or even an `#if FALSE #endif` depending on your language of choice) isn't that much more of a footgun than a git branch hundreds of commits behind and full of merge issues. It's something of a "different strokes" preference and it's something of a question of how fast the main branch is moving and how hard to keep up with it. Most language compilers and JITs eliminate the unreachable code within a constant false branch sooner or later and the code isn't even technically "deployed" even though it exists in source control for that deployment.
- wrsh07 3y ago
  I would strongly recommend learning git basics! My branches are never more than a day behind main (rebase does wonders!) Code inside an if false block might as well be commented, and commented code is the fastest to bitrot - I would strongly recommend against!
  - WorldMaker 3y ago
    There's still a difference between commented code because it is dead and bitrot and code-in-progress. I am among the first people to delete commented code and send anyone looking for it to git tutorials, but I've also kept git branches short by keeping code behind if flags (that are false in builds/production) while working on it so that I can still give that code the benefit of other refactors or compile errors and so that other developers are aware of that partially complete code. It's not a dichotomy, it's an orthogonal spectrum. Of course it is hugely useful to be good at source control. Of course it is still sometimes useful to have code compiling in CI/CD that "isn't ready yet" but prone to cross-fire in other on going work and refactoring. (Plus source control is greatly useful for answering "Why is this flag false right now? Who was last working on it and for what project?" and keeping that code honest that it isn't just bit rot.)

by wrsh07 3y ago

WorldMaker 3y ago

"Broken code" "deployed" inside an `if (false) {}` (or even an `#if FALSE #endif` depending on your language of choice) isn't that much more of a footgun than a git branch hundreds of commits behind and full of merge issues. It's something of a "different strokes" preference and it's something of a question of how fast the main branch is moving and how hard to keep up with it. Most language compilers and JITs eliminate the unreachable code within a constant false branch sooner or later and the code isn't even technically "deployed" even though it exists in source control for that deployment.

wrsh07 3y ago
I would strongly recommend learning git basics! My branches are never more than a day behind main (rebase does wonders!) Code inside an if false block might as well be commented, and commented code is the fastest to bitrot - I would strongly recommend against!
- WorldMaker 3y ago
  There's still a difference between commented code because it is dead and bitrot and code-in-progress. I am among the first people to delete commented code and send anyone looking for it to git tutorials, but I've also kept git branches short by keeping code behind if flags (that are false in builds/production) while working on it so that I can still give that code the benefit of other refactors or compile errors and so that other developers are aware of that partially complete code. It's not a dichotomy, it's an orthogonal spectrum. Of course it is hugely useful to be good at source control. Of course it is still sometimes useful to have code compiling in CI/CD that "isn't ready yet" but prone to cross-fire in other on going work and refactoring. (Plus source control is greatly useful for answering "Why is this flag false right now? Who was last working on it and for what project?" and keeping that code honest that it isn't just bit rot.)