> Can you give an example of the latest library or framework that changed? I guess the most famous example of this sort of API churn is react-router which comp

> Can you give an example of the latest library or framework that changed? I guess the most famous example of this sort of API churn is react-router which completely changes how it works internally and externally every major version, rather than keeping the APIs the same but changing internally. I stopped using it myself after the second or third version where everything changed. Most mainstream libraries/frameworks has this sort of churn, just differs what level of churn they introduce each version. > The part where you mentioned editing code like you edit Clojure/Lisp, moving/ modifying forms rather than text — I don't fully understand, but it sounds super interesting. It's called "Structural Editing" (or similar). Some references: - https://clojure.org/guides/structural_editing https://clojure.org/guides/structural_editing - https://www.editorworld.com/article/What-is-Structural-Editing https://www.editorworld.com/article/What-is-Structural-Editi... - https://en.wikipedia.org/wiki/Structure_editor https://en.wikipedia.org/wiki/Structure_editor > Can you point to some specific examples of design patterns and data structures? Not really, depends on the problem you're trying to solve. I guess where I see others and myself getting bogged down, is when you've chosen the wrong data structure for a job, and everything after that becomes harder. Usually re-evaluating what data structure you use (a list instead of a map, or vice-versa) can make the usages a lot easier. > are you talking about unit tests, integration tests, or E2E tests? Yes :) > Also, don't you think setting up tests takes a lot of time? It does take time, yes. But usually you spend even more time manually verifying that you didn't break anything and that it works correctly. And if that manual verifying takes 5 minutes each time you want to do it, you do it less often, so it's more likely something broke and you didn't even notice. So by spending 30 minutes setting up proper tests, you can save N*5minutes, depending on how often you run those tests and how much of a hassle it is to manually test. > Do you feel it provides a net gain in productivity? Most of the time, yeah. Sometimes you test too little, so you spend too much time manually testing. Other times, writing the tests themselves take longer than the time you'd recover to simply test it manually. Like all things in programming, I think it's about balances and "doing enough", not dogmatically just follow whatever is trendy. If something feels stupid, it probably is.