tl;dr:“I feel like there are some key features missing that would make me switch vendors. I mainly have two problems with current solutions: (1) It can get tedious and messy to turn on/off a feature when multiple FFs were placed for it. (2) Your codebase becomes a FF graveyard if you don’t remember cleaning it, and you probably don’t…” Eli provides suggestions on how to address these.
tl;dr:“I believe that the downsides of overly nested code are well known and covered, it mainly revolves around readability and maintainability, and I won’t go into more details in regards to that.
I’d like to focus on the techniques to flatten an overly nested code, but before doing so, you should keep in mind that flattening your code isn’t always the answer.”
tl;dr:“Modularity is a must for good software design. It helps with extensibility, readability, maintainability, and more. It certainly isn’t easy to make your code modular, but what exactly is modularity, and how do we measure it?”
tl;dr:“I’ll share my practices for writing tests and talk about when I write tests. Disclaimer: This is not groundbreaking advice, if you’re an experienced software engineer the following might be obvious to you.”
tl;dr:"There are many pitfall that can lead to useless, wasteful and confusing logs. Therefore I follow a specific set of practices which allows me to write better logs while also being consistent across the system." Eliran discusses here.