DEV Community

Working Code

018: Feature Flags (Finally!)

For Ben and his team, few things have fundamentally changed the product development life-cycle as much as LaunchDarkly, a feature flag management platform. Feature flags allow software engineers to separate the "deployment" of code from the "releasing" of code. Which means safer deployments; instantaneous roll-backs; smaller Pull Requests (PRs); incremental feature development; load-testing with real-world traffic; and - generally speaking - a big bowl of awesome sauce that you didn't even know you needed! And, once you have it, you realize that you can't live without it.

Mic drop!

But, while Feature Flags may seem magical, they aren't magic. And, moving feature flags through a product development life-cycle requires a certain degree of discipline. Because if you leave feature flags in your code for too long, your application logic can quickly devolve into an unclear, unpredictable maze of control-flow spaghetti.

In other news, the Working Code crew is also about to embark on their fist book club adventure, starting with Clean Code by Robert Martin (aka, "Uncle Bob"). We intend to review this book in the May 12th episode. Feel free to follow along!

And just when you thought things couldn't get any better, the Working Code Podcast now has a party line! Just kidding; but, we do have an answering service at (512) 253-2633 (That's 512-253-CODE!). Please leave us a message with with your comments, questions, and anything else you feel like sharing. We miss hearing your voices!

Triumphs & Failures

  • Adam's Triumph - Historically, when his team needed to host a private npm module, they've stored it in a private GitHub repository and then used git URLs within the package.json file. And, this worked most of the time. But, it was wonky and there were lots of quirks and edge-cases and they've been on the lookout for a better solution. Enter stage left: GitHub Packages. These allow you to "officially" store npm modules right alongside the rest of your GitHub hosted code - no hacks, no troubles.
  • Ben's Failure - He's generally very regimented about the hours that he keeps. But, in the wake of losing both his Project Manger (PM) and his Engineering Manager (EM), he's been struggling to properly prioritize all the work on his plate. And, instead of being smarter, he's opted to work harder by putting in a few extra hours here-and-there. He understands that it's a slippery slope; and, not the life-style that he wants to live; but, if he can just get ahead of it, he's confident that he'll get back on the right track.
  • Carol's Triumph - She's been wanting to build something with React as means to level-up on her front-end skills. And she finally finished going through a Udemy course on React! Next step: React side project (possibly to track her water intake).
  • Tim's Triumph - He's launching a skunk works project that is based on a previous skunk works project. It feels a little bit rogue; and a little bit cowboy; but, it also feels kind of amazing and is something that Tim recommends to everyone (assuming that they have some free time to commit).
ASIDE: A "skunk works project" is a secret project that the rest of (or most of) your company doesn't know about until there's a big reveal. These types of projects may or may not be authorized by the company itself.

Notes & Links

Follow the show! Our website is workingcode.dev and we're @WorkingCodePod on Twitter and Instagram. New episodes weekly on Wednesday.

And, if you're feeling the love, support us on Patreon.

Episode source