HPC kitchen [reading-docs]: Making sense of information overload

Duration: 7:54 1266 transcript words EN summary

Video summary

The video addresses the challenge of managing information overload by using a personal travel checklist as an analogy for technical documentation. The speaker explains that while their partner initially found their twenty-year-old packing list too long to read before every trip, they argued against shortening it because its length ensures nothing is forgotten. Instead of reducing content, which would force users to rely on memory and risk missing critical items, the solution lies in organization; by sorting a comprehensive list into logical categories with clear titles based on when specific actions are needed—such as right before leaving or while packing—the document becomes manageable despite its size. This approach demonstrates that documentation should be extensive enough to cover all potential scenarios but structured so users can navigate it efficiently without feeling intimidated. The core lesson drawn from this metaphor is that long documents do not need to be feared if they are well-organized, and the first step when facing such resources is to look for a table of contents or quick reference guides rather than diving straight into specific details. The speaker emphasizes that documentation serves as a tool to complement human expertise rather than replace it entirely; while search engines allow individuals to find information independently, relying solely on them often leads to confusion and inefficiency because the sheer volume of data is difficult for humans to navigate alone. Consequently, users should be encouraged to utilize support networks like supervisors or team experts who can guide them through complex systems, ensuring that they do not attempt to solve every problem in isolation when professional assistance could streamline the process significantly. Furthermore, the transcript highlights the importance of treating documentation as a living resource rather than an immutable truth, noting that much of it may be outdated and requiring updates from users or experts who encounter current issues first-hand. When encountering information that seems incorrect or obsolete, readers should not discard it immediately but instead use it as a starting point to verify facts with colleagues or request necessary revisions, thereby maintaining the document's utility for future reference. The speaker also advocates for specific structural design choices in documentation, such as keeping tables of contents on a single page and avoiding overly deep hierarchies that obscure the big picture; ideally, these documents should offer a quick summary view where users can perform keyword searches to jump directly to relevant details without having to click through multiple layers. Ultimately, the video concludes by urging creators to prioritize organization in their own documentation efforts, specifically recommending single-page overviews with links to detailed sections so that both new and experienced users can find what they need quickly. By combining a comprehensive scope of information with smart structural design like one-page summaries and clear indexing, organizations can prevent information overload while still providing the depth required for complex tasks. The speaker reiterates that whether writing guides for equipment or navigating vast digital resources, maintaining an organized framework allows people to leverage their support networks effectively rather than struggling alone against a sea of unstructured data.

Read the full video transcript

Hello, and welcome to another low-quality HPC kitchen video. This time we're talking about documentation or generally finding information. So, my partner's just gotten back from traveling. And hello. And this time instead of going through the checklist myself, I printed it out and gave it to them. And they looked at this and said, "This is too long. I can't go through it all before traveling." And well, I mean, partly yes, that's true because this set has everything that I've ever needed to think about before traveling for the last 20 years and so on. Anytime I forgotten something or had to do something before traveling, I would add it to the list. And it becomes long. So, what does this mean? Um is longer worse? So, in some sense, you might say so because it's too hard to read. But the point of the checklist is to have everything that you might need on it. So, you can check through it. Once you've read, you make sure you've got everything, and then you can go off and be confident you haven't forgotten anything. If it had less on it, it would be easier to go through, but then you would still have to go think, "What am I missing?" And then think of that and maybe forget things. So, it's actually longer than it would need otherwise. So, actually the checklist needs to be long in order to be useful. So, what's the metaphor here? The metaphor is to documentation to use all our computing resources. So, if you tried to print it out, it would be around this long. Of Of I didn't actually print it out just for a video. I'm not crazy like that. I printed out the first page and then the rest is some other paper I've gotten. So, this is long. What do we do? So, do we want it to be shorter or longer? So, if you ask me, the answer here is organization. So, if you look at my packing list, it's sorted into 13 categories with titles that tell you when you may need each of the different things in it. So, for example, right before you walk out the door, you look at the final check section. Um when you're packing, you would look at the clothes and maybe information section. If no one's staying at home and you need to turn stuff off and pack stuff up before leaving, there's a if no one is staying section. And so on. So, this allows you to sort of have something long, but also go through and be able to use it in a way that's possible for humans. So, what are the lessons here? So, first off, if something is long, don't be scared. So, if it's um if it's long, first look for the organization. So, before diving and trying to find an exact page you need, look at the table of contents. Look at any quick references. Maybe look at the index, but that's not quite the organization you need. But, get the big picture of it before you go and try to narrow down to the place to start because the first page you find or search engine brings you to might not be the actual right starting place. Know that not everything is needed all the time. So, be able to um not be intimidated that way and look more in-depth. Ask for guidance. So, if you ask me, part of the reason we've written this much stuff is not because we expect everyone to go read read it all, but that when people come ask us a question, instead of needing to give everyone an individual answer, we can point them at the relevant page here. So, the documentation is meant to be used along with us, not only instead of us. You can also ask your friends or colleagues, whoever that's doing the same kind of work, for information on like where to start, what they actually use, and so on. Finally, realize a lot of the stuff in here may be old and um may be out of date. So, if you're reading something and it looks a little bit off or not quite correct, well, then don't just go and um give up, but use it as a starting point. Maybe come and ask for us to update it or ask how it may be old. You might need to add in other stuff you're finding online with that, if you're able to do that, but it's better than removing something and next time someone needs to begin, they're starting from the very beginning once again. Finally, there's something that I've been thinking about and have made here. So, I made this little diagram of finding information in the past, if you can see. So, in this theory, in the past, we didn't have all these computer systems and so on. So, when you need to find information, you would have to go to this middle layer of say your supervisor or the team expert you have, or librarian, or a research engineer, whatever, who can help you go and navigate the things and find whatever it is you're looking for. And that's sort of made all the information more manageable. But then these days, we have computers, we have the internet, we have search engines, and so on. So, since you can find everything yourself, it's sort of expected that you try to find everything yourself. And if you ask me, this is not necessarily good. I mean, it's good that we have access to the information, but since um there's this idea, "Oh, we don't need the team experts. We don't need people like that anymore." Just let people find it all themselves leads to information overload. And there's just too much for people to be able to navigate themselves, and actually slow things down. So, make sure you keep this in mind and use your support networks. Don't try to go alone. If you're writing information If you're writing documentation for um your own equipment, don't go and uh just do it without paying attention to the organization. I'd say make a good table of contents. Try to have the table of contents be all in one page, so it's easy to navigate and see everything in it, instead of having to click through different things. Like, if you make a really deep hierarchy, where to know what's at the lower levels what levels, you have to click down through several upper levels to see there, that makes it a lot harder to get the overview and know if you're going to the right places or not. I like to try to have one page where it's possible to do a control F, like control find, within a single page and get a summary of where some keywords are, and from there it should link you to the details. So, first have a quick summary there, which is useful for quick reference, like in our cluster documentation, with links to the details. So, that way if someone genuinely knows what's going on, they can just use the quick reference and copy what they need. If they're new, they can get the overview and go to the more detailed pages. So, with that being said, I need to actually clean up this stuff now. Um, so thank you for watching and see you perhaps in the next low quality HPC kitchen video. Bye.