In tech we talk far too much about how to do various things, then toss around marketing speak for the rest of our careers. It might be better to talk about why we do those things. That way, we can spend our careers moving forward on really difficult problems our great-grandfathers started fixing instead of jumping from buzzword to buzzword every decade.
Here's a list of current buzzwords and the underlying problem they're trying to fix. I can guarantee you that the buzzwords and products will change. The problems will continue on.
Note that none of this involves any sort of specific tools, technologies, programming languages, or products. These are problems we face in technology creation today that we'll still have 50 years from now.
TDD: Test-Driven Development (TDD)
TDD is a coding practice to help the programmer understand that their mental model of the code does not reflect the actual code itself
That's it. There are some follow-ons, of course, like if your mental model is exactly in-line with the code then logical errors are unlikely (although business errors can be quite common!). Another follow-on is that TDD is much more about design than testing. Once you realize that it's a practice or habit that's all about sending information from the code back to the mind of the coder, all of that other stuff sorts itself out.
ATDD: Acceptance Test-Driven Development (ATDD)
A business practice that helps everybody involve in developing technology talk about what they want from the system in a logically-consistent way without getting into exactly how anything is going to be built (or, ideally, not built)
Microservices are a coding practice that simplifies the mapping of business value to code as much as possible by decoupling any sort of technical details used to support the implementation from the technical details used to deliver the implementation. (Microservices have no architecture, although they certainly can create very complex architectures when grouped together in various ways!)
Type systems are only stable across one particular business' feature and only for a limited period of time. The more you try to couple them into the larger biz, the tech stack, the world, or whatnot, the more you end up in monolith land. Nothing wrong with that, understanding that trade-off is the difference between knowing WTF you're doing and simply writing stories about how tough X was If you don't know the problem, you'll never know the solution when you see it.
Good Enough Programming
Code that provides value to others and that you never have to touch is good enough. There are a lot of programmers who are trying to code great systems when they've never even coded a single thing in their career that was good enough.
Myths and Misunderstandings
TDD is About Testing
TDD is a communication tool