Keeping a Maker's Logbook

In a good workshop, there is usually a notebook somewhere. It might be greasy at the corners, or covered in coffee rings. It holds measurements, mistakes, reminders and sketches. When something goes wrong a year later, the notebook is where the answer lives.

Software and digital makers often skip this habit, because everything seems to be on the screen already. But the screen does not remember why you made a decision, what you tried that failed or what you meant to do next. A logbook does. This guide shows how to keep one that is simple enough to survive a busy month.

What a logbook is

Scientists keep laboratory notebooks, dated records of experiments, observations and results, so that work can be checked, repeated and built on. A maker's logbook is a lighter cousin. It records what you did on a project and what you learned, in order, with dates.

It is not documentation for others, and it is not a diary of feelings, though you may add a line about those. It is a working record, for you, to make the next session smarter.

Why keep one

It saves you from re-learning. You solved a tricky problem in March. By September you have forgotten how. The log remembers.

It makes restarting easy. After a gap of weeks, you can read the last few entries and know where you were and what you meant to do.

It reveals patterns. Reading a month of entries shows where time goes, which problems recur and which ideas keep coming back.

It records decisions and reasons. "I chose X over Y because Z" is gold when someone asks why, including future you.

It gives you honest material. Posts, listings, release notes and support answers can be drawn from real notes.

It protects you from false memory. What you remember is often tidier than what happened.

Keep it small

The enemy of a logbook is the grand plan. Large templates and detailed headings feel virtuous for a week and then become a burden.

Aim for a few lines per session. A page or less. If you only have two minutes, write two lines.

A good minimum is four short prompts.

• Did. What I worked on.
• Learned. What I found out, including what did not work.
• Decided. Anything I chose, and why.
• Next. The first thing to do next time.

That last one is the most valuable. Ending a session with a clear first step makes starting the next one painless.

Choose a format you will use

The best logbook is the one you open.

A paper notebook. Hard to lose in a sea of tabs, pleasant to sketch in, and it keeps you away from the screen. Hard to search.

A plain text file. One file per project, newest entry at the top. Searchable, portable, future-proof.

A notes app. Convenient on a phone, easy to search, can hold photos.

A file in the project itself, kept in the repository or folder, so notes travel with the work.

Pick one. Put it somewhere you will see it. If you have more than one project, give each its own.

Date everything

A date turns a note into a record. Use a consistent format that sorts well, such as year, month, day. Add a time only if it helps.

Dates let you answer questions later: when did this start failing? How long did that take? What was I doing when the numbers changed?

What to write

Some things are almost always worth recording.

Measurements and numbers. How long a task took. How fast something ran. How many users tried it. Numbers fade from memory quickly.

Errors and fixes. The message, what caused it, what fixed it. Write the exact words of an error; they are searchable.

Dead ends. What you tried that did not work and why. It stops you repeating it.

Decisions. What you chose and what you rejected.

Sources. A link to where you found an answer.

Ideas. A line, to be sorted later.

Feelings, briefly. "Frustrated, took a walk." It is useful to see what drains and what energises you.

Next step. The first action next time.

You do not need all of these every time. Write what will help future you.

Keep a separate "later" list

A logbook is for what happened. Ideas belong in a "later" list, so they do not break your focus. When a new idea arrives, write it in the list with a date and carry on. Review the list once a month.

Use it to restart

When you come back to a project after a gap:

1. Read the last few entries.
2. Read the "next" line from the final one.
3. Do that.

Within five minutes you are working. Without the log, many people spend an hour trying to remember what they were doing, and some give up. The log is a rope you leave for yourself at the top of the cliff.

Turn it into a public changelog

A logbook can feed a public record. A changelog, in the sense popularised by common conventions for keeping one, is a curated, human-readable list of notable changes to a project, in order, with dates, for each version. It is written for users, not for yourself.

From your log, pick the changes users care about and write them plainly: what was added, changed, fixed or removed. Group them by version. If you use version numbers, a scheme such as semantic versioning gives them meaning, with major, minor and patch numbers that tell readers the scale of a change.

This is how a private log becomes trust. A visible changelog shows that the project is alive and cared for, and it saves you from answering "what changed?" over and over.

Never publish private notes by accident. Keep the working log separate from the public version, and remove anything personal, any credentials and anything about other people.

Use it for writing

When you want to write a post about your project, the log is your source. It holds the real story: the problem, the false starts, the decision, the result. Posts written from a log sound like a person because they are one.

It also helps when you write a listing or answer a question. You can look up exactly what you said and did.

Protect what it contains

A logbook may hold sensitive material, such as passwords you pasted in a hurry, customer names or private links.

• Never store passwords or keys in it. Use a proper password manager.
• Avoid personal data about users. Use anonymised descriptions.
• Back it up, especially if it is on one device.
• Know who can see it. If it is on a shared drive or in a public repository, check.

Weekly and monthly reviews

Two small reviews multiply the value.

Weekly, five minutes. Read the week's entries. Note what moved, what stuck and what to do next.

Monthly, fifteen minutes. Read the month. Ask: what took longest? What did I learn? What should I stop doing? What decisions should I revisit? Move useful ideas from the later list into the plan.

A few lines from each review go into the log as well.

A sample entry

Described in words: a dated heading. Did: worked on the export feature, got CSV working, JSON half done. Learned: the date format from the library differs by machine setting, which explains last week's bug; fixed by setting it explicitly. Decided: no PDF export for now, because nobody has asked and it would take two weekends. Next: finish JSON export and write the help text.

That is a good entry. It took two minutes, and it will save an hour.

Common mistakes

• Too elaborate a system.
• Not dating entries.
• Skipping "next".
• Recording only successes.
• Storing secrets in it.
• Never reading it back.
• Treating it as a chore.

On this site

The submit page lets you list your project so that people can follow it, the launches page shows what other makers have shipped and the blog has more guides for makers. The founders page introduces the people behind this place, and the categories page helps you find a shelf.

A month with a logbook, in prose

Picture a maker who builds a small habit tracker in the evenings. In week one her entries are about choices: a plain database over a fancy one, no accounts for now. In week two she records a bug that took two evenings, with the exact error message and the one-line cause. In week three she notes that she has spent three sessions on colours and none on the feature people asked for, and she writes that down without scolding herself. In week four she reads the month and sees the pattern: her best sessions are short, early and start with a clear next step.

She changes her schedule, drops the colour work and ships a small release. The public changelog she writes takes ten minutes, because every item is already in the log. Six months later, when a user reports the same sort of bug as week two, she finds the old entry in seconds and fixes it in minutes. The notebook is not glamorous. It is the quiet reason the project is still alive.

Starting today

If you do not keep a log, start with one line tonight. Write the date, one thing you did on the project and the first thing to do next time. Tomorrow, do the same. In a week you will have seven lines and a surprising amount of clarity. Do not buy anything, install anything or design anything. A scrap of paper is enough to begin, and a habit that begins small is a habit that survives.

The short version

A maker's logbook is a short dated record: what you did, what you learned, what you decided and what to do next. Keep it small, in a format you will open, write the first step for next time, record dead ends and numbers, keep ideas on a separate list, never store secrets and review weekly and monthly. From it you can draw a public changelog, honest posts and a restart in five minutes.