Making guides for highly technical tasks, step by step, in great detail are an incredibly flawed way of teaching people how to accomplish these tasks. I'm finding this out in real time as I research the best practices way of doing MDT nowadays. I see many people have specific guides, and then with one tiny change of variables for their environment, or one new patch... that all can come crashing down. So what's the point of the detailed guide?
I think it's self-interest. I personally like to write out these guides or these thoughts on things since it helps me really discover my own thought processes and reevaluate some of the steps. It makes me realize that some parts of how I got there were inefficient or flawed. They might have some exposure to risk as well.
Write guides for yourself, but when you want to learn something read multiple guides, go through the work yourself, and learn directly through trial and error. Document your steps, refer back to your notes, etc... Every single MDT guide or advice I saw had a major flaw in it that I could discover very quickly. Storing server Administrator passwords in a CustomSettings.INI for instance. Why not make a throwaway account that only does one thing, deployments, and have those deployments do email alerts? Well another guide said that, but it had all kinds of unnecessary bloat in it's processes. Another guide fixed that bloat, but had the former problem, and had a new problem of not taking you through a crucial step of using DISM to convert install.esd to install.wim. And so on...
The point is, these guides aren't really helpful in actually learning what you need to do in order to accomplish a task. A perfect example of a good guide for the purposes of actually learning something is Linux from Scratch.
As you can see they don't give you links to download each thing, or commands on how to do it. Prior to this they don't tell you what distro to download. They don't tell you what command parameters to do it. This will actually lead to you ACTUALLY learning! You will have to google what this linux-kernel thing actually means, what distros have it, how to install gzip, how to use gzip, how to wget, etc...
I honestly don't see the point in holding someone's hand so much that they don't have to actually learn something. And I say this as someone with a pretty bad learning disability, keep in mind. The best way for us to learn is to make these strong synaptic connections between our actions and our experiences. Being led around reduces the amount of "action" we are taking, and lessens the experiences associated with the task of learning.
So next time you write a guide, be vague. I wrote mine for my own learning experience and reflection, but if I was trying to help people, I would point out steps in vague ways. Sorta like what /u/iConrad did on /r/linuxadmin when asked how to get your start in Linux Sysadminnery.
You can see how rough around the edges this is, but that's the point. If you want to be a Linux Systems Administrator, you have to be able to read a sentence like, "Set up a KVM hypervisor." and be able to find the answer, do what is requested, do it again, and again, until you are a full-fledged expert at doing this initial task. If you refuse to do that, then maybe this isn't your line of work. Why would a guide be written out in such a way that doesn't assume people can be curious and learn on their own?
Either way, this is less of a rant and more of an encouraging thought in showing people how to teach people to learn, like the other entry.