But for people that don't do technical writing day to day, it can be a little daunting when you are initially tasked with writing some docs. This is usually the case at smaller companies where people have to wear multiple hats.
In my experience, as a tool writer/maintainer I tend to want to document the implementation, but nobody cares about that until you leave your job (by then the documentation may be out of date if you don't maintain it). Most people's highest priority is a troubleshooting guide (which is difficult with a new tool) and a very explicit walkthrough for non-technical people (which is difficult to maintain because dialogs get tweaked and supporting tools can change).
This is what I'm trying to help with. If you keep the framework of "know your audience" and "know their purpose" in mind, docs will be much less daunting. Who am I writing this for? What do they know beforehand? What is their purpose of reading this doc? Answer those questions, and you won't need to memorize long lists of specific tips. Trying to memorize tips and grammar rules without having an overarching framework of why they improve your communication is what makes writing daunting, IMO.