Principles are products of practice, not the reverse

I can think of one reason for strict adherence to principles is for newbies, for new starters not familiar with the world they're dealing with, too many moving pieces can be overwhelming, so using principles to fixate a few things can be helpful.

I started off, from Day One, heavily structuring and documenting my code.

These days, I don't even think about it, and my productivity is pretty much as good as you can get.

Plus, I am the one that usually has to go back into my code, and maintain it, so I'm glad of that habit.

"We are what we repeatedly do. Excellence, then, is not an act, but a habit."

- Mis-attributed to Aristotle.

You gotta be careful with this one in the context that it is being applied here (HTML). This risks becoming an ableist mantra because the practice might be disregarding accessibility concerns.

In software engineering, “principles” constitute a delicate and evolving synthesis of theoretical constructs and empirical lessons.

They transcend the mere aftermath of triumphs, as posited by the author, to encapsulate the intricate tapestry woven by both successes and failures.

The author posits that principles are the byproduct of success, but that’s simply not the whole truth.

Principles, far from being dichotomous with experimentation, represent not only “prescriptive guidelines for successful implementation” but also incorporate the counsel of hard experiences and bitter emotional lessons distilled from the long and enormous crucible of software project failures.

In my experience managing and coding software engineering projects, this kind of fidelity to principles becomes a multidimensional pursuit, where the so-called “failure principles” bear just as much gravitas as their counterparts learned from success.

> This is also why it’s important for the makers of policies and standards to be connected with the real-time experimentation in a market, and not in silo, to constantly adapt, iterate, and refine standards and principles according to real-world outcomes.

This lesson is profoundly true, and encompassed in lean experimentation and their ilk, and while it’s important not to rely on principles to guide product as effectively it becomes tradition guiding product instead of learnings and therein lies real risk, principles and the practice of adapting, iterating and refining standards are not exclusive in any way. You can have a map and make changes as you learn things in the exploration.

That is why we have rules of thumb and principles for doing things: because it’s incredibly important to pay attention to “principles” in order to mitigate the not so insignificant risk of catastrophic failure. So saying that all principles come from success is not correct.

After all, ‘those who chase two rabbits never catch one’ isn’t the lesson of a successful hunt.

I would say, and do say, that Principles are Rules of Thumb