Programmers make assertions all the time with a wide range of utilities: tests, types, written prose, and so on. Assertions are how we establish some ideal of the system at any particular scope. Maybe there is a requirement that all services in an ecosystem do not rely on each-other's internal implementation details or that exceptions should not be thrown in library code. Perhaps a team decides that despite correctness being of the utmost importance, it doesn't give anyone the right to be an asshole.
Ray Dalio wrote a whole book on the matter of principles and feels they are at the center for decision making and iterative improvement,
Principles are fundamental truths that serve as the foundations for behavior that gets you what you want out of life. They can be applied again and again in similar situations to help you achieve your goals.
My likening of principles to assertions is superficial. Assertions are, in my mind, simply the application of principles. We assert that an invariant is upheld during each iteration of a loop, that some postcondition is still met after execution of a function, that a system is composable and modular from applying principles sat around the locus of flexibility. In some cases these are machine-checked, in others they rely on humans to verify. Regardless of checking they are still present.
When you have autonomy in a team it is key that you take initiative to achieve excellence. The problem with initiative is precisely an issue of what to work on. Principles provide a 'north star' metric that enables you to say "is the error handling in this code dividing concerns between internal versus external concerns?" or possibly "do people feel supported and empowered to make the changes they need ot make across the broader company?" With principles we can scrutinize, but also work towards, some ideal. Hence our application of these ideals is the work we undertake.
One could easily take principles from elsewhere but that would leave us with little to no understanding of how to form our own principles that best suit our needs and desires. What is the trick? The process I'm about to describe is probably not the only way to go about carving up principles but it's one that has worked for me and others.
Feedback loops are how we take risks and reflect. Experiencing this cycle for long enough means we start noticing patterns that can take the form of principles. A principle is really just a pattern that can describe some ideal clearly. You make failures (by way of decisions), you learn from failures (by way of reflection), you get principles.
I've been thoroughly enjoying Turn that Ship Around! and one of the mentioned mechanisms towards getting a "leader-leader" culture is changing the focus from avoiding errors to achieving excellence. In this same manner I think the best principles are formed. When I talked about treating your codebase as a home you want to build, this 'idealised life' that a home represents is the same as these principles I've talked about here. In that sense, from a programmer's perspective, excellence is really just the code and the culture we wish to embody.