There are no "best practices", only "good practices in context". Also, Clean Code and Clean Architecture, at least in the circles I travel, aren't considered "bibles". They have some good ideas, but those ideas (and more) are available from other sources.
I also learned XP before Scrum, and I too find the number of meetings onerous. That said, a core tenet of Scrum is "inspect and adapt"... if you're doing Scrum the same way a year after you started, then you aren't doing Scrum! 😂 If the meetings aren't providing value, then seriously consider dropping them and finding a different way to accomplish the same goal.
And, related to XP, I don't use TDD all the time for all the things. I do write tests pretty much all the time, but especially when working with legacy code written without test, it can be difficult. When I'm working on fun stuff away from work like Raspberry Pi or Arduino, I often don't write tests at all, though I've been looking at changing that approach.
All that to say that, in the 40 years since I wrote my first line of code, I've realized that there are no absolutes in software development. What is considered a best practice today could be obsolete tomorrow.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
There are no "best practices", only "good practices in context". Also, Clean Code and Clean Architecture, at least in the circles I travel, aren't considered "bibles". They have some good ideas, but those ideas (and more) are available from other sources.
I also learned XP before Scrum, and I too find the number of meetings onerous. That said, a core tenet of Scrum is "inspect and adapt"... if you're doing Scrum the same way a year after you started, then you aren't doing Scrum! 😂 If the meetings aren't providing value, then seriously consider dropping them and finding a different way to accomplish the same goal.
And, related to XP, I don't use TDD all the time for all the things. I do write tests pretty much all the time, but especially when working with legacy code written without test, it can be difficult. When I'm working on fun stuff away from work like Raspberry Pi or Arduino, I often don't write tests at all, though I've been looking at changing that approach.
All that to say that, in the 40 years since I wrote my first line of code, I've realized that there are no absolutes in software development. What is considered a best practice today could be obsolete tomorrow.