It is important to pass on the knowledge of RFCs’ to the new generation of software engineers. And it is doubly important to follow the standards, for mankind’s benefit (or at least the maintenance engineer’s benefit).
If you don’t agree with RFC, then get to work to change it, but tossing it out of the window is short-sighted at best and disastrous at worst.
Many people don’t know where RFCs come from, or assume that the process is opaque, or that it’s entirely driven by corporations.
In reality, joining the IETF is as simple as subscribing to a mailing list, contributing to an existing working group is as simple as reading a few “how to write RFCs” RFCs, and learning how the IETF works as a whole is… well, it probably needs about 2 hours, all told, as long as it’s the right two hours. Starting here is not awful:
You don’t need corporate sponsorship or to pay a fee. The IETF Meetings are big conventions which do have a fee, but you don’t actually need to go to them. The next one is in July, will be entirely online, and fee waivers are available for people who need them. Many employers can be persuaded to pay some or all of the costs.
Before the pandemic, a relatively new initiative was to hold regional meet-ups in places which had sufficient density. I hope that will continue when it’s safe.
In my experience, one way this goes so horribly wrong is through your innocent debug lines unconsciously becoming information somebody else relies on via automation.
In startup settings, something that commonly happens is in the beginning nobody cares about your product, much less its logs, so you hack away, trying to push the important features out to get some big customers. Then one day, in the middle of your start-up chaos, the product manager tells you that the IT department of one of your important customers has been scavenging your logs for some alerts and that they’d like you to add this and that bit of information to some lines and it comes to you as this tiny low priority task that you couldn’t possibly justify including the arduous yet hard to justify task of redesigning your whole logging story. That’s one way your unstructured log dumps slowly become a loosely defined interface where you have some nebulous compatibility concerns. It was never designed properly and it will never be redesigned…
There have been times in my life where I had been overjoyed to have this person’s problems with syslog, because there had been syslog.
Believe me, there are far worse approaches to logging.
good thing about standards is that there are so many to choose from that we don’t have to follow…