They synergize together. As an example, what's beyond code quality is writing library code where doing the right thing is easier, and is aligned with the syste

They synergize together. As an example, what's beyond code quality is writing library code where doing the right thing is easier, and is aligned with the system. If, for example, one uses a design pattern whose anti-pattern is misaligned with the overall system, then it is easy to do the right thing locally and the wrong thing systemically. As another example, the "best practices" are actually sound engineering principles applied specifically and locally. In a different architecture, with a different constraint and use-case, how those principles applied may sometimes look different than what "best practice" says, but not so strange if you understand the engineering principle underlying the "best practice". Lastly, I would say, "systems thinking" always includes people: the people writing the code, the people making sure the infrastructure is running, the people using the system as end-users, the people supporting the users, the people running the business, the people paying the business, the people depending on the technology. Incorporating that means dipping into a product perspectives where people talk about things like, ux, or "job to be done", or "lived experience" rather than "requirements analysis" or "observability".