Not strictly what the author is talking about, but I once made a mediumly-impactful change by reducing a single character from a 6 to a 5. I worked on controllers for three phase motors, and we did something called “third harmonic injection” to use about 15% more of the bus voltage than a naive strategy would. Somebody had previously remembered incorrectly, and was trying to command 16% more voltage, which would cause a math error and suddenly make everything crash. At the time, this was somewhat mysterious. Changing the 16 to a 15 fixed it, lol.

great idea -- for sufficiently lumbering enterprisey clients you may discover that it is impossible for a mere dev to "push" a change into production without the right part of the org tree pulling, let alone for that to happen on timescales of less than a week. but even if so, that's a profoundly helpful thing to learn on week 1 so this is still great advice!

("...what do you mean that any changes going to prod need to first be socialised with and endorsed by the ABC steering committee & have their full rollout, rollback, & test plans signed off in blood by the responsible product, engineering & test managers & then sent for review by the change review board with at least 5 businesses days of lead time prior to the requested change date...")

Similar to working with an open source tool. Fix all the errors you find in the documentation when you are getting it up and running. If the pull request gets handled well and quickly, future contributions will probably be painless and productive.