More code per unit of time? More frequent integration
Practice of Continuous Integration traditionally meant integrating code to main at least once per day.
»Practice of Continuous Integration traditionally meant integrating code to main at least once per day.
»how fast the code has been written.
»When coding, I find AI especially valuable when trying to achieve consistency across the codebase once I have a directional change in design. The “look at this example of how I did it and apply it to all other cases in the codebase”, where AI does all the heavy lifting, drastically cuts the time to implement a change.
»optimizing for making bigger changes faster
»If you can’t change design cheaply because refactoring skills are lacking, you’re less likely to end up with a suitable design for a given problem that emerges from insights you get as a byproduct of refactoring.
»I often ask myself if a technology, beside lowering the costs for which lowering the costs is beneficial, is also lowering the costs for which lowering the costs is detrimental.
»In short, the system compensates for the increase in transaction cost per batch size by increasing the batch size.
»The idea of managing (inherent) interdependence in systems is at least as important as the idea of decoupling (independence) that the software development industry is so predominantly obsessed with since the field’s inception.
»in a way that it amplifies the pain that every single individual felt when working in isolation, but because everyone was suffering alone, the pain was perceived not as high to address it.
»contains more action items related to adding more gates before a change reaches customers, rather than reducing the size of the change, you’ll likely end up with having to create even more incidents reports.
»