I can't pretend that I have any good methods for capturing and maintaining documentation, but I do love the file management system an engineering friend of mine has: I was leaning over his shoulder recently while he was working on his laptop and I noticed he had three folders on his desktop: crap, more crap, and even more crap. He told me that was where he stored the "important" content!
The challenge of documentation is that it is usually intended for retrieval in the future. This means that the effort of documentation has little immediate reward and the future retrieval depends upon maintaining access integrity through time. Three ring binders are bulky and hard to search but admirable in their accessible user interface through time, changing computer software, and operating system. Computer files must be created in a format for which future access is assured and the files must be rolled ahead to each new generation of the storage system. They must also be preserved in a way that is obvious to others. Most computers are reused or retired when their owners retire or pass away. Few files are effectively captured and mined for the corporate benefit. Lab books are visible which at least forces somebody to consciously decide whether to preserve or discard them. Someday, our ability to create data will be matched by our ability to mine it. In the meantime, most recollections of previous solutions depend upon the memory of the inventor; the documentation merely fills in the fine details. The next generation has little hope of mining the digital records of their predecessors.
I use a lot of 3-ring binders, so many it's hard to store them all. I don't use them for everything. For day-to-day notes and planning, I far prefer college-ruled composition books with "granite" covers. They're a nice size, light, and easy to take on public transportation. I carry them everywhere.
I'm also a strong believer in documentation -- the earlier the better. When I'm working on something new and don't know what I'm doing yet, the notebook is excellent. However, once I can start to describe it I find that writing it up using a document editor is a great way to get the ideas filled in, and it becomes the first draft of the eventual documentation. The hard copy goes in binders.
I find it very hard to proof-read on a screen. I always find errors after printing out on paper.
IMO everyone should print hard copy listings of their software and technical references. If doing so creates so much paper that you can't manage, then your design approach clearly needs to be reconsidered.
The days of bound engineering lab notebooks (for patent purposes) that would no longer close due to being stuffed full of Polaroid scope photos are long gone, binders do help solve this.
These days keep all your design notes and measurements on a computer. This way you can search for some long-forgotten entry based on a vaguely remembered keyword, and disseminate your notes through email instead of a photocopier. (Patent lawyers might not agree with this philosophy, makes it too easy to fake the dates.)
The main thing is to write everything down. You never know what you may need at some future time.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.