Documentation Practice

Note-Taking Tools and Methods for Engineers

A general comparison of paper notebooks, plain text files and wiki-style notes for capturing technical work, with guidance on choosing and combining them.

On this page
  1. What notes are for
  2. What to record
  3. Paper notebooks
  4. Plain text files
  5. Wiki-style and linked notes
  6. Comparing the three
  7. Choosing and combining
  8. Habits that make any system work

What notes are for

Engineers keep notes for several overlapping reasons: to remember what they did and why, to think through a problem on the page, to capture what was agreed in a meeting, and to leave a trail that someone else, or their later self, can follow. Notes are personal working material. They differ from the shared, polished documents a team publishes, although good notes often become the raw material for those.

This article compares the main approaches in general terms. It deliberately avoids recommending particular products, since tools change and what suits one person may not suit another. If your employer or industry requires formal records, such as controlled laboratory notebooks or logs, follow those rules first, since requirements vary by country and field.

What to record

Whatever the medium, the content that tends to be most useful is fairly consistent.

  • Date and context. Every entry should be dated, with a note of the project or task.
  • Goal. What you were trying to do or find out.
  • What you did. Settings used, versions, measurements taken, and the order of events, in enough detail to repeat it.
  • Results and observations, including unexpected ones and failures. Negative results often save the most time later.
  • Decisions and reasons. A single line of why a choice was made is often the most valuable thing in the page.
  • Open questions and next steps.
  • Sources. Where a value, formula or idea came from.

Recording units alongside every number is a small habit with large rewards. Measurements without units, or with the wrong ones, are a common source of mistakes.

Paper notebooks

Paper is simple, quick and robust. It needs no battery, no login and no software to learn. Sketching a circuit, a free-body diagram or a rough layout is often faster by hand than in any tool, and many people find that writing slows them down enough to think. Habits for keeping technical notebooks tidy are a topic of their own, but a bound notebook with numbered pages and dated entries gives a natural chronological record, and in some settings this is the required format.

The drawbacks are also clear. Paper is hard to search, so finding an old entry depends on memory and on an index you keep up to date. It can be lost or damaged, copying it requires scanning, and it is awkward to share. Handwriting may be difficult for others to read, and pasting in data or screenshots takes extra effort. Some people keep an index page at the front and number pages to compensate.

Plain text files

Plain text, including simple Markdown files, sits at the other end. Files are small, open with almost any program, and are searchable. They can be stored in a folder structure, backed up easily, and placed under version control so that changes are tracked. A plain text note written today is likely to be readable in many years’ time, because it does not depend on a particular application.

The drawbacks: plain text has little built-in support for sketches, tables of data or images, although links to files can fill the gap. Structure depends on your own discipline, with consistent file names and headings. A pile of loosely named files can become as hard to navigate as a drawer of loose paper. Searching works well only if you use consistent words.

A simple scheme helps: one file per day, or one per project, with dates in file names written in a sortable order, and a short list of keywords at the top of each. This suits people who are comfortable at a keyboard and want a low-friction system with long-term durability.

Wiki-style and linked notes

Wiki-style tools let you create pages that link to each other, so that a note about a component can link to the project that uses it and to the people who know about it. They are well suited to a body of knowledge that grows over time, and they make it easy to restructure as understanding improves. Many support tags, search, embedded images and tables, and some can be shared with a team.

The costs are overhead and dependency. It takes time to set up and maintain a structure, and it is easy to spend effort organising instead of working. Some tools store notes in formats that are awkward to export, which creates risk if the tool changes or disappears. Shared wikis also raise questions of ownership and keeping pages current, which become a team matter; the broader issue is covered in discussions of how teams manage documentation. A personal wiki can also drift into a store of material nobody revisits.

Comparing the three

Feature Paper notebook Plain text Wiki-style
Speed for sketches High Low Medium
Searching Poor Good Good
Sharing Difficult Easy Easy
Long-term readability Depends on handwriting and storage Very good Depends on the tool
Setup effort Very low Low Medium to high
Linking between notes Manual Manual Built in

These ratings are general tendencies, not measurements, and they will vary with the particular tool and the person using it.

Choosing and combining

Few people use only one. A common arrangement is paper for quick sketches and thinking during meetings or at the bench, with a digital system for searchable records and longer-lived notes. If you do this, set a habit for moving what matters across, perhaps at the end of each day, such as photographing a page or typing up decisions. Otherwise, important information stays trapped in whichever place you used first.

When choosing, consider:

  • where you actually work: at a desk, in a lab, on a site, on the move;
  • what you need to find later and how you will search for it;
  • whether others need to read your notes;
  • whether confidentiality rules limit where project information may be stored, in which case follow your organisation’s policies, including for remote engineering tools;
  • how easily you can export your notes if you change tools.

Whichever you pick, the most important factor is consistency. A modest system used every day beats an elegant one used for a week.

Habits that make any system work

  • Date every entry and name the project.
  • Write for your future self, who will not remember the context.
  • Keep a short index or table of contents, or use consistent tags.
  • Review notes weekly, pulling out actions and decisions.
  • Turn valuable notes into proper shared documents when others would benefit.
  • Keep backups of anything you cannot afford to lose.

Notes are only valuable if you can find and understand them later, so aim for plain, dated, specific entries over polished ones.

The complete guide to documentation practice

Documentation Practice for Engineering Teams
Read the guide

Keep exploring

Guides from other topics

All topics →