I felt that about many joints when I slacked off on working out for a few months in my 20s. I was still lifting enough to keep my muscles from too much atrophy, but my joints got… lazy? Dynamic motion and heavier weights suddenly felt (as suddenly as me taking exercise more serious again) like my joints were the limiting factor.
and then I overworked my arms and got something like tennis elbow and basically had to rehab myself back to being able to exercise, all without my muscles being the limiting factor!
Take care of your body, folks. You can go over 100% when you’re young, but your body makes you pay when you’re older!
Reminds me of the stories of the people who do crazy stuff on adrenalin rushes, like lift a car off their dying child, and then end up potentially hospitalized or otherwise extremely sore for months. I think I get it now…
IMO, the most important parts are to document the actual intent of the code. The contract of what is being documented. Sure, it’s only so useful in perfectly written code, but NO code is perfect, and few will come through later with full context already learned.
It makes it sooo mich easier to know what is intended behavior and what is an unchecked edge case or an unexpected problem. If it’s a complicated thing with a lot of fallout, good documentation can save hours of manually lining up consequences and checking through them for sanity.
You might say, “but that’s indication of bad code!”. No. Not really. Consequences easily extend past immediate code doing things as trivial as saving data to the database without filtering, or having a publicly available service. Even perfectly coded things come up with vulnerabilities all the time due to underlying security issues. It’s always great to have an immediate confirmation of what’s supposed to happen whether it’s immediate code or some library with a new quirk in a new version.