What Twelve Professionals Said in a Forum Thread

Every tool has a learning curve, and the interesting thing about most curves is not how steep they are but what shape they take. Some tools are difficult at the start and then trivial: a week of confusion followed by years of fluency. Some are easy at the start and grow harder as the material accumulates and the initial arrangement stops fitting. And some have a shape that is rarely described, in which the basics are immediately obvious and the parts that eventually matter most are invisible for months, not because they are hidden but because their value cannot be perceived until there is enough material for them to act on.

A note-taking tool of any depth falls into that third category. Creating an entry and typing into it is self-explanatory and requires nothing. What transforms such a thing from a place to put text into an actual working system is a set of decisions about structure, capture habits, and the small features that only become meaningful at a certain volume. A person with forty entries has no use for a mechanism that surfaces forgotten material, because nothing has been forgotten. A person with two thousand entries depends on it. The feature was present the whole time and was genuinely useless when they started, which means no amount of documentation at the outset would have persuaded them to care.

This produces a specific kind of regret that experienced users express in almost identical language across completely unrelated fields. Not that they chose the wrong tool, and not that anything failed, but that they arrived at a particular habit eighteen months later than they might have, and that the eighteen months of material produced before the habit exists is measurably worse than everything after it. Retrofitting a convention across a thousand entries is tedious. Adopting it on day one costs nothing. The difference between those two facts is the entire content of most advice worth giving to a new user.

What makes this hard to convey is that the advice is boring and the reasons for it are not visible in advance. Name things consistently. Decide what an entry is before creating four hundred of them. Encrypt from the beginning if you will ever need to. Attach files to the part of the record they belong to. Capture quickly, structure later. None of these sound like insights and all of them are, because each one represents somebody discovering, after considerable effort, that the alternative accumulates into a problem that has to be solved manually later.

The most useful documentation a tool can have is therefore not written by its makers. It is written by people who have used it long enough to know which of their early decisions were expensive, and who are willing to say so plainly rather than presenting a tidy account of a system that emerged fully formed. That kind of testimony is uncomfortable to give, since it requires admitting to eighteen months of doing something inefficiently, and it is worth considerably more than any feature list because it answers the only question a new user actually has, which is what they should do differently starting tomorrow.

What follows is one such collection. A small private group, started informally after a conference and grown by introduction rather than by advertisement, now contains a dozen people who use the same tool across healthcare, law, education, journalism, security, ministry, property, research, hospitality, film, and maritime operations. Somebody posted a question. Over several days, everybody answered it, and the answers turned out to be more useful read together than any of them would have been alone.

The question

The thread was started by Tomas, who apologised for it in the first line, which everybody agreed afterward was unnecessary.

The post read: I have been using this for a bit over a year now and a colleague at school has just started. I sat down to write her some advice and produced two pages of things I only learned by getting them wrong. It occurred to me that everybody here has a version of that list. So: what do you wish you had known when you first started?

There were twelve replies over four days.

Dr. Meera Iyer, psychiatrist, Austin

I will give the short version first because it is the only one that matters, and then explain it.

Encrypt from the beginning. Not eventually, not once you have decided what is sensitive, not when you get round to it. From the first entry that concerns a person who is not you.

I did not do this. My first four months of clinical entries were unencrypted, and there were around ninety of them by the time I decided to change that, and I encrypted them one at a time over about three evenings while feeling considerably worse about myself than the situation warranted. Nothing had gone wrong. Nothing was ever at risk in any realistic sense; the machine sat in a locked consulting room in a building with an alarm. What bothered me was that I had made a decision by default rather than deliberately, which is precisely the thing I spend my working life helping other people notice.

The reason I did not encrypt initially is worth stating, because I suspect it is common. I was evaluating. I had not committed to the tool, I was not certain I would still be using it in six months, and encrypting felt like an act of commitment I had not yet earned the right to make. That reasoning is entirely backwards and I would like to save somebody else four months of it. The material was sensitive on day one. Its sensitivity did not depend on my confidence in the software.

The specific thing I would tell a new user is to decide the category rather than the item. My rule now is that anything concerning an identifiable person other than me is encrypted, full stop, without any judgment being made about how sensitive that particular note is. Judgment at the point of creation is where errors live. A blanket category applied automatically removes the decision, which is the only way a rule survives a difficult week.

I also want to mention something I found late and which changed how the whole arrangement feels. For a period I was entering a password more often than the work required, which produced exactly the outcome anybody could predict: I started leaving things open, and I began to resent a mechanism I had chosen deliberately. Then I understood that the key is held for the working session, so entering it once at the start of an appointment covers everything I do within that material for the duration of it. I had been treating each individual opening as a separate event.

That distinction matters more than it sounds, and I want to put it in clinical terms because that is how I think. A protection that is proportionate to the risk gets maintained. A protection that is disproportionate to the risk gets circumvented by the person it protects, usually in a way nobody records, and the circumvention is always worse than a slightly weaker scheme applied consistently. I have watched colleagues abandon perfectly reasonable security practices for exactly this reason and then feel guilty about it, when the actual failure was that the practice was designed by somebody who did not have to perform it forty times a day.

The last thing I would say is about what encryption did to my writing, which I did not expect and which I would now put ahead of the security argument. My notes became messier, longer, and considerably more useful. When I knew a note was genuinely inaccessible, I stopped writing for an imagined reviewer who was never going to arrive. My earlier notes are technically complete and clinically thin, and I can tell exactly which ones were written before the change without checking any dates.

So: encrypt the category from the first day, let the session hold the key, and notice what happens to what you are willing to write down.

Suki: This is the correct answer and I want to add one line to it. The reason retrofitting is painful is not technical, it is that you have to make ninety individual decisions you could have made once. Decide the category, not the item.

David: Meera, the sentence about writing for a reviewer who never arrives is going to stay with me. I had not connected the two things at all and I think it explains something about my own early notes.

Raj Malakar, documentary filmmaker, Berlin and Mumbai

Mine is going to sound trivial and it cost me an entire post-production.

Use hashtags consistently from the first day. Not eventually. Not once you know what your categories are. From the beginning, even if the categories turn out to be wrong, because a wrong convention applied consistently is trivially fixable and no convention at all is not.

Here is what happened. I put inline hashtags into my entries from the start, because it felt natural and because I write quickly and it was faster than anything else. But I did not use the same ones. On day fourteen of a shoot I would write one word for a stage of production, and three weeks later, tired, in a different city, I would write a slightly different word meaning the same thing. Singular and plural. One with a hyphen and one without. An English word one week and the word I actually use for the concept in my head the next.

None of this mattered at all until I opened the board.

The board builds its columns from labels and from the hashtags in my notes, and pulls the cards from what is there, and it is genuinely the tool I use most during production because it shows me the state of a project as a shape rather than as a list. And when I first opened it, on a project that was eight months old, it produced something close to nonsense. Fourteen columns where there should have been five. Cards scattered across near-identical buckets. A production stage split into three because I had spelled it three ways.

I spent two evenings fixing it. Not a disaster. But two evenings of finding and correcting variants across several hundred entries, which is precisely the work I would have avoided by writing a list of eight words on a piece of paper before I started.

So the practical advice is: before you write your fiftieth entry, write down your tags. Physically. Somewhere you will see them. Mine live in an entry that is starred so it appears in my sidebar every morning, and there are nine of them, and I have not added one in a year.

The deeper thing I would say, and this is the part I actually believe, is that the naming conventions matter more than the features. I have spent my adult life around people who evaluate creative tools obsessively and then produce chaos in them. The tool is not what makes a project findable. What makes a project findable is that you decided, in advance, what things are called, and then you did it that way even at two in the morning in a hotel with bad wifi when you did not feel like it.

I would extend this beyond tags. Decide what an entry is before you have four hundred of them. For me one entry is one shooting day, always, and everything about that day lives inside it in sections. I arrived at that after trying one entry per interview, which fragmented everything, and one entry per location, which is meaningless because we return to locations.

And decide how you name them. My entries are named with the day number first, then the place. Not the place first. That single choice means my list sorts into the order things happened, which is the order I think in, and I changed it about four months in and it took an hour.

Last thing. If you are chaotic, and I am, do not fight it. Set the conventions and then be as chaotic as you like inside them. I capture badly, at speed, in fragments, constantly. That is fine because the fragments land in the right entry under the right tag. The discipline is entirely at the level of where things go, not at the level of how carefully they are written.

Tomas: I am taking the physical list of tags. I have been holding mine in my head, which explains why I have both a singular and a plural version of two of them. Thank you for saving me from finding that out during a busy week.

Marcus: Raj, the sentence about deciding what an entry is before you have four hundred of them is the whole thing. I got that wrong for a year and the correction was substantial.

Claire Fontaine, patent attorney, Chicago

I wish I had migrated sooner, and I want to be precise about what delayed me, because I do not think it was caution.

I spent several months intending to move a practice archive across from a markdown vault while doing nothing about it. The stated reason was risk. The actual reason, which I recognised only afterward, was that I had built the migration into something ceremonial. I imagined a weekend, a checklist, a period of parallel running, and a formal decision at the end of it. Nothing on that scale was ever required. When I eventually did it, prompted by an associate who had run out of patience with me, the import itself took a morning.

The import tool reads markdown files directly. You point it at them, they come in, and what arrives is entries with their content intact. There was nothing to reconstruct and no format to translate by hand, which was the specific fear I had been carrying and had never examined.

What I would tell somebody in the same position is that the migration is not the project. The structure is the project. I spent about three days deciding what the hierarchy should be, which was genuinely necessary work and would have been necessary regardless of which tool I was moving into, and once that was settled the material went where it obviously belonged. My delay was not caution about data. It was reluctance to make the structural decisions, disguised as caution about data, and I would encourage anyone recognising themselves in that description to separate the two.

The second thing I underused for far too long was the indexing of attachment contents.

My practice runs on documents. Filings, office actions, prior art references, analyses, correspondence. For roughly the first six months I treated attachments as things I stored and located by remembering which matter they belonged to, which is exactly what I had always done and which I did not think to question. I found out by accident that the text inside those documents is searchable, and I found out because I typed a phrase into the search box in a moment of frustration and it returned a filing from a matter I had not thought about in three years.

The phrase in question was eleven words of claim language that I was certain we had used before and could not place. I knew the shape of it. I could not name the client, the matter, or the period. In the previous arrangement that is a lost afternoon and a favour asked of an associate. It took four seconds, and it returned two other filings I had forgotten used the same construction, one of which was the useful one.

I want to state the general principle because it took me some time to articulate. Perfect filing was never an end in itself. It was a strategy for retrieval, and it demanded that I predict, at the moment of filing, how I would want to find something years later. Nobody can make that prediction accurately. Once the contents of documents are searchable, the prediction becomes unnecessary, and the filing decision simplifies to putting the item where the matter lives.

My practice became simultaneously more rigorous and less laborious, which sounded contradictory to me until it happened.

Two smaller things. First, I would tell a new user to test the search on something they know exists only inside an attachment, in their first week, because the experience of it working changes how you use the tool immediately and no description substitutes for it. Second, if you are in a regulated profession, work out early which categories need protection and apply it by category rather than item, for the reasons Meera has already given better than I would.

Priya: The line about filing being a strategy for retrieval rather than an end in itself is going into my thesis notes, attributed. That is a considerably better statement of something I have been circling for two years.

Suki: Claire, the observation that reluctance to make structural decisions can disguise itself as caution about data is uncomfortably accurate and applies well beyond migrations.

Tomas Herrera, chemistry teacher, San Antonio

Since I started this thread I should probably answer it, and my answer is the least sophisticated one here and I am not embarrassed about it.

I did not know there were tables.

For about seven months I built every table I needed in a separate program, exported it, and attached the file to the entry it belonged to. Lab results. Comparison charts for reaction types. A grid of what my classes actually got for a standard experiment, year over year, which is the single most useful document I own. All of it produced somewhere else and then attached, which meant that updating a table involved opening a second application, finding the file, editing it, exporting it again, and replacing the attachment.

I want you to understand that I did this happily. I did not experience it as a problem. It was simply how tables worked as far as I knew, and it never occurred to me to look for an alternative because I had not identified it as something that needed one.

Then a student asked me a question during a free period and I was building something quickly and I clicked a control I had not clicked before, and a small grid appeared letting me choose how many rows and columns I wanted, and a table appeared in the note.

I said something out loud. The student asked if I was all right.

The part that turned out to matter is not the table itself but the context menu on it. My tables grow. Every year adds a column to the results grid. Every unit I teach adds rows to a comparison. In the old arrangement, adding a column meant the whole cycle in the other program, which is enough friction that I would batch it up and do it three times a year and the table would be out of date for months at a stretch. Now it is a right click and it takes four seconds, so I do it in the moment, and the tables are current because keeping them current costs nothing.

That is the actual lesson and it generalises well beyond tables. The cost of an operation determines how often you do it, and how often you do it determines whether the thing stays true. Any part of your process that is expensive will be batched, and anything batched will be out of date most of the time.

So my advice to a new user is oddly specific: spend twenty minutes in your first week clicking every control in the editor to find out what it does. Not reading about them. Clicking them. I would have found the table in twenty minutes and I found it in seven months, and the difference is entirely that I never went looking because I was not aware there was anything to look for.

A second thing, smaller. I now use the same six elements for everything I write and each one has exactly one meaning. Headings for the phases of a lesson. Bold for anything with no tolerance for error, which for me is timings and quantities. A block with fixed spacing for equations and pseudocode, because the alignment is the content. A callout for safety and only for safety. Tables for anything with more than a few rows. And one highlight colour, yellow, used exclusively for hazards.

That last rule is the one I would defend hardest. The moment I highlight something merely interesting in yellow, the safety warning stops being distinguishable from the interesting thing, and a sixteen year old scanning a procedure at the start of a period is not reading. They are looking for the shape that means stop. If that shape also means look at this, it means nothing.

Third and last. My structure was wrong at first. I organised by date, which is tidy and useless, because I do not think in dates, I think in units. A thing I taught in October two years ago is related to the same unit in every other year and to nothing else that happened in October. Fixing it took a Saturday because pages can be dragged, and everything kept its labels and attachments through the move.

Do not try to design the correct structure in advance. You cannot. Build something plausible, use it for a month, and fix what annoys you, because the annoyance is the information.

Amir: Tomas, the twenty minutes of clicking everything is the best advice in this thread and I say that as somebody who spent three weeks fighting a button by accident before working out what it was for.

Felix: The observation that the cost of an operation determines whether the thing stays true is a genuine insight and I intend to steal it for a chapter about laboratories.

Suki Tanaka, security consultant, Tokyo and remote

I will contribute the mistake that cost me the most, which was structural and which I made for a reason that seemed excellent at the time.

I organised by engagement type. Penetration tests in one branch, audits in another, architecture reviews in a third, incident work in a fourth. This is how my profession describes itself, it is how my invoices are categorised, and it is how I would have described my own practice if anybody had asked. It is also, as an organising principle for the material, completely wrong.

The problem revealed itself about eleven months in, when a client I had worked with three times over two years asked me a question about something we had discussed during the second engagement. The three engagements were of three different types. They were therefore in three different branches, with nothing joining them except my memory, and my memory produced roughly sixty percent of an answer.

I restructured over a weekend. Client at the top. Engagement beneath. Phases beneath that. It changed everything, and the reason is worth stating precisely: the stable entity in my work is the client. Engagements end. Types of work are a description of a method rather than of a relationship. The client persists, and the questions I am asked are almost always about a client rather than about a category.

The general form of the rule is: structure on the thing that will still exist in a decade, and let everything else be a filter. A type of engagement is a property of a piece of work. Properties belong in labels, in filters, in search. Only the durable entities deserve a place in the hierarchy, because a hierarchy is expensive to change and a filter costs nothing and can be discarded the moment it has answered its question.

I would add that the mistake is extremely easy to make, because the wrong organising principle is usually the one your profession uses to talk about itself. Ask instead what your clients, patients, or students would consider themselves to be. They do not think of themselves as an engagement type.

Second thing, and this is aimed at anyone assessing the tool rather than using it.

Verify the network behaviour yourself, in your first week, before you commit anything you care about. Open the developer tools, work normally for an extended period, and count the requests. Then do it again at the operating system level with something that does not depend on the browser reporting honestly. It is not sophisticated work. It is tedious, which is why it gets skipped, and skipping it means trusting a claim you could have confirmed in an afternoon.

The reason I raise this is not that I expect anybody to find something surprising. It is that the confidence produced by having checked personally is a different substance from the confidence produced by having read a claim, and it changes what you are willing to put into the system. I have watched people hold material outside a tool for years because of an unease they could not name, and the unease is almost always resolvable by one afternoon of looking.

Third, smaller, and it is a practice rather than a feature. I keep every version of the application file I have ever used, dated, with a hash recorded separately. Costs nothing. Means I can compare versions, detect any tampering on my own machine, and decline a future direction indefinitely if I ever want to, because a file does not expire. That habit is only available because the whole thing is one readable file, and I would not have thought to establish it if I had not noticed that the distribution model made it possible.

Marcus: Structure on what will still exist in a decade. I organised by document type for a year before working out the same thing about properties. Wish I had read this eleven months earlier than I did.

Lena: The point about the wrong organising principle being the one your profession uses to describe itself is the sharpest thing in this thread so far.

Pastor David Achebe, Atlanta

I am the least technical person in this group and I have made peace with that, so my contribution will be simple and I hope useful to somebody in a similar position.

I wish I had found the feed reader in my first month rather than my eleventh.

Here is what I was doing before. I follow perhaps a dozen writers, theologians, and colleagues who publish regularly, and I have always considered that reading part of my work rather than separate from it. A sermon written by a man who has read nothing new in two years is a sermon everybody has heard before. So every week I would go round the sites, one at a time, in a browser, checking whether anything had appeared. When something had, and it seemed useful, I would select the text, copy it, create a note, and paste it in, then add a line at the top saying where it came from.

Eleven months of that. I want to say clearly that I did not resent it. It felt like diligence. I was rather proud of the discipline.

James, who volunteers with our technology and who has the patience of somebody who has explained a great many things to me, watched me do it once and asked why I was not using the reader. I said what reader. He showed me, and it took about four minutes, and I sat there feeling the specific way a man feels when he learns that eleven months of a weekly ritual could have been replaced by a list.

The feeds come to me now. They sit in folders, which I have arranged by relationship rather than by topic, because that turned out to be how I actually think about it. One folder for people I know personally. One for the institutions I am accountable to. One for theology generally. One for things entirely unrelated to my work, which exists to stop me becoming a bore at dinner.

What I would tell somebody new is not really about the reader. It is that when a task in your week feels like diligence, you should check whether it is actually diligence or whether it is a manual version of something. I could not distinguish those two things from inside the habit. Somebody had to watch me and ask.

That is my real advice: show somebody your process, early, out loud. Not to be corrected. Simply because you cannot see your own workarounds. Every one of us in this thread is describing something we did badly for months while feeling perfectly satisfied, and in most cases it ended when another person saw it.

The second thing I would say concerns what I do with what I read, and this one I got right by accident.

When something in a feed sets something off, I do not save the article. I make an entry, put two lines in it about the source, and then write for as long as the thought runs, in my own words. Beneath that there is a section listing which sermons or which pastoral concerns it connects to.

The result is that about a fifth of what I have written this year began as a reaction to somebody else’s work. That is what a college of colleagues used to do for me when I was younger and had one. I did not know I was missing it until I had it back.

Third and last, and I will be brief because others have covered it better. Decide your protected category on the first day and never revisit the decision item by item. Mine is everything pastoral, one password, all of it, because grading confidences would mean grading the people who gave them to me and I will not do that. Whether that rule is right for your work is your judgment. Having a rule at all is not optional.

Meera: David, the point about not being able to see your own workarounds is the reason this thread exists at all, and it applies to every one of us.

Nkechi: I have a version of your reader problem and it is the reverse. I cannot receive feeds at sea, so I download aggressively in port. Same principle: replace the manual thing before it becomes a ritual you defend.

Priya Sharma, doctoral candidate, London

Mine is about a feature I actively ignored for the first year, and I ignored it for a reason I now think is common and worth naming.

The related entries suggestions are trained by voting. When you are looking at an entry, other entries are proposed as connected, and you can vote them up or down, and those votes persist and influence what is proposed in future.

For a year I did not vote. Not once. I looked at the suggestions, formed an opinion privately, and moved on, which is the behaviour of somebody treating a system as a fixed thing to be evaluated rather than as something they are participating in. I had unconsciously classified the suggestions as the software’s output rather than as a conversation, and you do not argue with output.

The consequence is that for that entire year the suggestions were mediocre, which confirmed my classification, which is a very tidy trap.

I started voting because a friend asked me what I thought of the feature and I said it was not very good, and she asked how many things I had upvoted, and I said none, and we both sat there for a moment.

Within about six weeks it was noticeably better. Within three months it was surfacing connections I would not have made, which for a literature-heavy project is the single most valuable thing any system can do. My field produces papers faster than anybody can read them, and the difficulty is never finding a paper, it is remembering that a paper I read fourteen months ago bears on a problem I am looking at today. That is precisely what a trained suggestion system does, and it cannot do it if you refuse to tell it anything.

So the specific advice is: vote from the first week, on everything, including the ones that are obviously wrong. Downvotes are as informative as upvotes and probably more so, because a wrong suggestion tells the system about a boundary. And do it while you are looking at the entry anyway, since it costs a click and no thought.

The general form of this is the part I would emphasise, because I think it applies to more than one feature. Some parts of a tool are static and some are cumulative. A static feature works identically on day one and day one thousand. A cumulative feature is worthless at the start by construction and becomes valuable only in proportion to how much you have fed it. Judging a cumulative feature on day one and concluding it is weak is a category error, and it is the error I made.

The mechanisms that surface forgotten material fall into the same category. So does anything that reports on your own patterns of use, which is meaningless at forty entries and genuinely informative at two thousand. If you evaluate those early you will correctly conclude they do nothing, and you will be wrong about the future rather than about the present.

One smaller thing that I would put in front of anybody starting a long research project. Decide that one paper is one entry, from the beginning, and never let a paper become a paragraph inside a note called Reading, March. A paper is a thing with an identity. It has findings, and it has your opinion of it, and your opinion will change across four years. If it is a paragraph inside something else it cannot be labelled, it cannot be linked to a chapter, and there is nowhere for that evolution to live.

I got that right by luck rather than judgment and it is the single decision my entire thesis rests on.

Claire: The distinction between static and cumulative features is extremely useful and I have not seen it stated anywhere. It explains why my own assessment of several things was wrong in the first months.

Raj: Priya, I did exactly the same with the suggestions and for exactly the same reason. Starting to vote this week.

Marcus Webb, property investor, Denver

I will keep this practical because that is the only register I have.

I did not use sections for the first year and it cost me a restructure of about six hundred entries.

Here is what I did instead. For each unit I had a separate entry for the lease, a separate entry for the move-in inspection, a separate entry for each maintenance incident, a separate entry for the tenant correspondence, and a separate entry for the financial records. Which is tidy, and which produced a list under every unit that was long, flat, and impossible to read as a sequence.

The problem showed up in a dispute. A tenant’s attorney asked what we had done about a heating complaint and when. The answer existed. It was distributed across four entries, in an order that was not obvious from the list, and assembling it took me about forty minutes and produced something that read as a reconstruction rather than as a record.

What I do now is one entry per incident, with sections inside it. The tenant’s original message with the photographs attached to that section. The plumber’s diagnosis. The invoice. The follow-up two weeks later. The correspondence with the insurer. Open the entry and you are reading the whole thing in order with every document sitting at the point in the story where it belongs.

I have sent that twice since and both conversations ended within a few minutes.

The rule I would give somebody starting is: an entry is an event, and a section is a part of that event which has its own paper. Not a document type. An event. My mistake was letting the filing structure follow the categories of paperwork rather than the shape of what actually happened, and paperwork categories are how a filing cabinet thinks rather than how a business does.

Second thing, and this one I would put ahead of everything if I were only allowed one.

Attach files to the section rather than to the entry. A maintenance entry can accumulate nine or ten documents over a few months, and a flat list of nine files named by whatever a camera or a contractor’s office manager decided to call them is not something anybody scans successfully. Attached to the section they concern, each one is identified by where it sits. I do not have to remember the filename. I have to remember what kind of thing it is, which I always know.

Third, and this is about a habit rather than a feature. Rename about one file in fifteen. Not all of them, which is a full-time job with poor returns. The ones that carry weight: the photograph that shows the damage, the invoice that became contentious, the document somebody will ask about. Everything else stays as it arrived and remains perfectly findable by its contents.

Which brings me to the last thing, and it is the one that most changed a number in my actual accounts. The text inside attachments is searchable. I found that out about eight months in, searching a contractor’s name, which appears in no title and no label of mine and exists only inside invoices attached to maintenance entries across eleven different buildings. It returned all of them, including three from a property I had already sold and had forgotten he ever worked on.

I went into a negotiation with a total instead of an impression. My impression was low by about forty percent.

Start with that. Search for something you know is only inside a document, in your first week, and then decide how much filing effort is actually necessary. In my experience the answer is considerably less than you think, provided the structure is right.

Amir: Marcus, the photographing of invoices was my daughter’s idea and I resisted it for two weeks. Same result. A conversation with numbers in it goes very differently from a conversation with a feeling in it.

Tomas: An entry is an event and a section is a part of that event with its own paper. That is the clearest statement of it I have read and I am putting it in the note I am writing for my colleague.

Lena Johansson, investigative journalist, Stockholm

Mine is the one that produced an actual loss, so I will state it plainly and without any framing.

Archive web sources before you disconnect. Immediately, at the moment you find them, not when you get round to it.

I work air-gapped. Material comes in on removable media, and the machine that holds my working archive has never touched a network and never will. That arrangement is correct for my threat model and I would not change it. What I did not think through, at the beginning, was the consequence for anything that exists only on the open web.

I lost three sources this way. Not sources in the human sense. Pages. Two of them were company disclosures that were quietly replaced with amended versions, and one was a regional news report that was taken down entirely, and in all three cases I had a reference and a note about what they said and no copy of the thing itself.

A note about what a document said is not a document. In this work it is a description of evidence I no longer have, and its value in a legal review is close to nothing. I knew that. I had known it my entire career. I had simply been treating archiving as something that happened at the end of a research phase rather than at the moment of discovery, which is a scheduling error with permanent consequences.

What I do now is that anything I find gets saved into an entry at the point of finding it. The page becomes a note with its content and the address it came from, immediately, before I have decided whether it matters. That last part is the important one. I no longer make a judgment about significance before archiving, because the judgment requires knowing how a story develops and I never do at that stage.

The rate is roughly one in twenty. Nineteen of the things I archive turn out to be irrelevant and cost me a few seconds each. The twentieth is a page that no longer exists, and I have it, and it is sometimes the entire basis of a paragraph.

There is a general form here and it is not specific to journalism. Anything you find outside your own system exists at somebody else’s discretion. A supplier’s published price list, a regulator’s guidance, a manufacturer’s specification, a competitor’s public statement, a research protocol on an institutional page. All of it can be changed or removed without notice by people who have no obligation to you, and a link is not a record. A link is a request to a stranger for permission to see something again later.

Second thing, related, about the physical workflow. I bring material into the isolated machine on removable media and I examine it in isolation, and what leaves is only finished text I have read in full. That is my constraint rather than a general recommendation. But the principle transfers: decide in advance what direction material moves in, and make that decision structural rather than something you determine in the moment. Late at night, tired, at the end of a difficult week, I do not want to be making a judgment about whether something can be copied out. I want the answer to have been settled months earlier.

Third, and briefly, because Suki has covered the substance. Verify offline behaviour before you rely on it, not after. I ran mine for three weeks with the network hardware physically disabled before I put a single real document into it, and what that proves is stronger than an absence of traffic. It proves an absence of dependence.

Suki: The distinction between the absence of traffic and the absence of dependence is one I have started using in client work and I should have credited you for it before now.

Felix: A link is a request to a stranger for permission to see something again later. That is going in the book, with attribution, and I am not asking.

Amir Hassan, bakery owner, Toronto

Everybody here has written something thoughtful and mine is about a button.

There is a round button in the corner. You press it and a new note opens immediately, wherever you are, without navigating anywhere. That is the whole feature.

For three weeks I did not know what it was. My hands are large, the laptop sits on a steel table at the back of the shop, and I lean on things. I kept touching it accidentally, something would open, I would close it, and this happened perhaps twenty times over three weeks.

I did not ask my daughter. I want to be honest about the reason. I did not want to be a man who asks his daughter about a button. So instead I created eleven empty notes over three weeks and quietly blamed the computer.

Then one morning I touched it deliberately, to see what would happen if I did not close it immediately, and it was a new note, and it was exactly the thing I needed and had been needing for twenty-two years.

Here is what my mornings are. I am in at five. My hands are in dough by ten past. Somewhere between five and seven, every single day, something occurs to me. A supplier I need to call. A quantity that was wrong last week. Something a customer said on Saturday that I have just understood. And by seven o’clock, when my hands are free, it is gone. Every day. For twenty-two years I treated that as a fact about my memory.

It is not a fact about my memory. It is a fact about the cost of writing something down. When writing it down meant finding a pen, or opening a program and deciding where the note goes, the cost was higher than the thought was worth in that moment, so the thought lost. When it costs one press and eleven seconds, the thought wins.

So my advice to somebody starting is: find the fastest way to capture something before you learn anything else. Not the best way. The fastest. Whatever takes the fewest actions between having a thought and it being recorded somewhere permanent. Everything else in this thread is about organising material, and you cannot organise material you never captured.

The second thing I would say is that I use very little of this. I have four pages. I do not use encryption, I have never opened the version history, there is a board with cards which my daughter showed me and which is clearly excellent and which I closed and have not returned to.

And none of it is in my way. Nothing has ever suggested I try any of it. There is no small red dot telling me I have failed to discover something. I mention this because I have left two other products in my life not because they were difficult but because they kept talking to me, and if you are the kind of person who finds that exhausting, you should know that this one is quiet.

Third thing, and then I will stop. The star.

I thought it was decoration for four months. A little star, what is that for. Then my daughter put it on my four base doughs and on the page where the day’s notes go, and now there are six things in a panel and I open one of them within four seconds of sitting down. It is not a filing cabinet, which you open when you need something. It is a door, which you walk through every morning.

I could recite all six from memory. I open it anyway, because opening it is how the day starts.

Nkechi: Amir, the point about the cost of writing something down rather than the quality of your memory is exactly right and I would extend it to anybody working with their hands.

Felix: I met this man in his shop and I can confirm that the baklava justifies the entire thread.

Captain Nkechi Obi, cargo ship officer, Lagos and at sea

I will describe a specific month, because it is more useful than a general recommendation.

My first contract after starting with this, I did not set up the calendar. I had entries, I had structure, I had my pages arranged in the way I still use. But the scheduling side I left alone, on the reasonable grounds that I had a paper calendar which had worked for eight years and which required no decisions.

Four weeks later I had a paper calendar with three corrections in ink, one drill I had recorded on the wrong day because we had changed time zone twice that week, and a certification renewal date I had copied incorrectly from a document I no longer had aboard.

Nothing went wrong. I want to be clear about that. I caught all of it. But I caught it by checking obsessively, which is what a person does when they know their record might be wrong, and that checking is a background process running continuously for a month at sea.

So the advice is: set up the schedule before you need it, not when you notice you need it. And specifically, before any period where you will be unable to reach anything.

What I have now takes about forty minutes to establish per contract. The watch rotation goes in first, because everything else is arranged around it and because a person on a four-and-eight rotation loses track of the day within a fortnight. Then the fixed obligations: drills, which recur and which I enter once with a repeat rather than as individual events, inspection cycles, and port windows as they are confirmed. Then certifications, which are the ones that end my ability to work and which I treat differently from everything else because missing one does not make me late, it makes me unqualified.

That distinction is the second thing I would tell somebody. A due date means something must be done by then. An expiry means something stops being valid whether or not anybody acts. They need different warning horizons. I want six months on an expiry because fixing a lapse involves other people and takes that long. I want a week on a due date because a week is enough to do the work.

Third. The whole thing lives on the disk in the folder with everything else. That is not a technical detail for me, it is the reason any of it is usable. I close the laptop for three weeks at a time. I open it and it is exactly as I left it, nothing queued, nothing failed, no wall of accumulated messages arriving at the moment I am least able to absorb them. Returning to range is uneventful. I cannot describe to somebody who works ashore how unusual that is.

Fourth, and this is a practice rather than a feature. Every Sunday I copy the folder to a memory stick, and there is a second copy in the ship’s safe. If this laptop went over the side tomorrow I would lose a laptop. That is the whole procedure and it is the only one available to me, because there is nobody ashore to call at three degrees south, and anything I depend on has to be something I can restore myself with what is aboard.

Last thing, briefly. Capture during watch is a chat-style thread, one line at a time, because I have eleven seconds and not four minutes. At the end of the watch six lines with times on them become one proper entry. Half of what I capture never becomes anything. The other half is the half I would have lost.

Marcus: The distinction between a due date and an expiry is one I have been getting wrong for two years with insurance certificates. Fixing that this week.

Priya: The forty minutes per contract is the part that persuades me. I have been treating setup as something requiring a free afternoon that never arrives.

Dr. Felix Brennan, retired professor, Vermont

I have read everything above and I notice that eleven people have advised more structure, more consistency, more discipline, and earlier decisions. I am going to argue the opposite and I think we are all correct, which I will explain at the end.

I wish I had started looser.

When I began, I had eleven boxes of forty years of material and a memoir to write, and I did what a scholar does when facing an unstructured problem. I designed a taxonomy. It was excellent. It had five levels in places. It distinguished correspondence by relationship and by period and by whether the exchange concerned research, administration, or friendship, which is a distinction that sounds meaningful and which collapses the moment you look at an actual letter from an actual colleague, because a letter from a colleague is all three things and usually in the same paragraph.

I spent, I estimate, six weeks categorising and about nine days writing.

The specific failure is one I would recognise instantly in a doctoral student and could not see in myself. I was performing the appearance of the work in order to avoid the work. Categorising is comfortable. It feels productive, it produces visible progress, it has a clear right answer at each step, and it does not require me to write a paragraph about my own conduct in a hiring decision nineteen years ago. Every hour spent refining a hierarchy was an hour I did not spend on the difficult thing, and I could have continued indefinitely.

What broke it was a former student visiting and saying, gently, that she had come expecting to help me scan things and had found a man who had built an information architecture rather than a book.

So I loosened it. Eight pages at the top, which is still more than most of you have. Sub-pages where a branch genuinely earned one through use rather than through anticipation. And a rule I still keep, which is that I do not create a page until the thing has eleven entries wanting to live in it. Before eleven, they can sit in the parent and be found by search, and if they never reach eleven then the page was never needed.

The material found its shape by being used, which is what everybody in this thread has said in different words, and the difference between my position and theirs is only about which decisions are cheap.

Here is the reconciliation, and this is the actual contribution I would like to make.

The decisions that are expensive to change should be made early and deliberately. What counts as an entry. Whether a category is protected. What things are called. Whether you attach a file to the part of the record it concerns. Suki is right that structuring on a durable entity matters, Raj is right about naming, Meera is right about the protected category, and every one of those is expensive to retrofit across a thousand items.

The decisions that are cheap to change should be deferred until the material tells you. How deep the tree goes. How many branches exist. Which sub-pages are needed. Those cost a drag and an evening, and deciding them in advance means deciding them with no information, which is how I lost six weeks.

The mistake I made was treating a cheap decision as though it were expensive. The mistake I have watched others make is the reverse, and it is worse.

Two smaller things and I will stop.

The first is the widget that surfaces a random entry once an hour. I ignored it for a month as decoration. It is now the reason the book exists, because the material I had forgotten I owned is the material that matters, and there is no query for a thing you cannot name. Most days it produces a receipt. On one occasion it produced a letter from a man who died young, which I had scanned mechanically and never read, and four sentences on its second page became an entire chapter.

That feature only works with a loose structure, incidentally, which is the connection I did not expect. A rigid taxonomy means everything is where you put it and you already know where that is. A loose one means things sit near each other for reasons you did not intend, and the collisions are productive.

The second is that I would tell any new user to write badly on purpose in their first week. Make an entry that will never be shown to anybody, and put something uncomfortable in it, and notice what happens. The reason is not sentimental. It is that most people arrive carrying a habit of writing for an imagined reader, and they will not discover that habit by being told about it. My early entries are appalling. Fragments, contradictions, one that consists entirely of the words check whether this is why. I have deleted none of them. About one in twenty germinates two years later.

Amir: Felix, the rule about not creating a page until eleven things want to live in it is the most useful sentence in this thread for somebody like me, and I say that having read all of it twice.

Suki: This is the correction the thread needed. Expensive decisions early, cheap decisions late, and the skill is telling which is which. I would add that most people misclassify in the direction of over-planning.

Tomas: I am going to put Felix’s last paragraph at the top of the note I am writing for my colleague. Everything else can be learned. The willingness to write badly cannot be taught by a manual.

What the thread actually said

Read individually, those twelve posts are a list of specific regrets about specific features. Read together they say something more coherent than any individual contributor intended, and the coherence is worth extracting.

The first observation is that almost nobody regretted their choice of tool, and almost everybody regretted a habit. The complaints are about naming conventions established too late, categories decided by default rather than deliberately, structures built on the wrong organising principle, and capture that was slower than it needed to be for months. In every case the software behaved correctly throughout, and the cost was incurred by a decision the user made at a moment when they had no information and did not realise they were deciding anything.

The second observation is that the expensive mistakes cluster in one place. What counts as an entry. What things are called. Which category is protected. Which entity carries the hierarchy. Whether files attach to the part of the record they concern. Every one of those is trivial to establish at the beginning and requires manual work across hundreds of items afterward, and every one of them was named by at least two people who had never discussed it. That convergence across healthcare, law, security, property, research, and film is a reasonable indication that the list is not domain specific.

The third is subtler and comes mostly from Priya and Felix. Some capabilities are static and some are cumulative, and evaluating a cumulative one early produces a correct assessment of the present and a wrong conclusion about the future. A mechanism trained by votes is weak until it has been fed. A widget that surfaces forgotten material is useless when nothing has been forgotten. A report on your own working patterns is meaningless at forty entries and informative at two thousand. Dismissing these in the first month is not unreasonable, and it is a category error, and several people in the thread lost a year to it.

The fourth is that the most common way anybody learned anything was that another person watched them work. A pastor copying articles by hand for eleven months. A baker fighting a button for three weeks. An attorney deferring a migration she had built into a ceremony. A researcher who had never voted on a suggestion and had concluded the suggestions were poor. In every case the person was satisfied from inside the habit and could not see the workaround, and in every case the correction came from somebody else noticing. That is a strong argument for showing your process to a colleague early, out loud, and it is probably the single most transferable recommendation in the whole thread.

Underneath all of it is the tension Felix named at the end, which is that expensive decisions should be made early and cheap ones should be deferred, and that most of the harm comes from misclassifying which is which. Over-planning a hierarchy costs weeks and produces a structure built without information. Under-planning a naming convention costs an evening of corrections across several hundred items, or a board that produces fourteen columns where there should have been five. Both are recoverable. Neither is free.

What none of them said, and what is visible only from outside, is that twelve people in unrelated professions produced twelve pieces of advice with no contradictions in them except one that turned out to be a distinction rather than a disagreement. A psychiatrist, a ship officer, a baker, and a patent attorney describe the same architecture, arrive at the same habits, and regret the same omissions. That is not a fact about software. It is a fact about the shape of the problem, and the tool’s contribution was to be flexible enough that all twelve of them could get it wrong in their own way first.

FAQs

What is the single most common regret among experienced users?

Adopting a convention late rather than choosing a different tool. Almost nobody in a long-running discussion of this kind regrets their choice of software; nearly everybody regrets a habit established months after it would have cost nothing. The pattern is consistent across unrelated professions: naming decided too late, a protected category decided by default, a hierarchy built on the wrong organising principle, and capture that stayed slower than necessary. In each case the software behaved correctly throughout and the cost arose from a decision made without information at a moment nobody recognised as a decision. The practical implication is that advice from long-term users is usually about habits rather than about features, and is worth more than any comparison of capabilities.

Which decisions genuinely need to be made on day one?

The ones that are expensive to change across hundreds of items. What counts as an entry, what things are called, which category is protected, which durable entity carries the hierarchy, and whether files attach to the part of the record they concern. Each takes minutes to establish at the outset and requires manual work across the whole archive afterward. Practitioners in healthcare, law, security, property, research, and film independently named the same short list, which suggests it is a property of the problem rather than of any particular domain. Writing the five down before creating fifty entries takes under twenty minutes and is the highest-return time anybody spends on the whole arrangement.

Which decisions should be deferred?

The ones that cost an evening to change. How deep the hierarchy goes, how many branches exist, which sub-pages are needed, and how material is grouped within a branch. Pages can be rearranged and entries keep their labels, attachments, and history through a move, so these choices are cheap to revise and expensive to make well in advance, since deciding them before any real material exists means deciding without information. The most common failure is treating a cheap decision as though it were permanent and spending weeks on a taxonomy. A useful rule of thumb is that anything a drag or an evening could fix should wait until the material has demonstrated what it needs.

Why is retrofitting encryption so painful?

Because it converts one decision into hundreds. Choosing a protected category at the beginning is a single judgment applied automatically thereafter, while deciding later means opening each existing item and deciding individually, which is tedious and invites inconsistency. Practitioners who delayed usually did so while evaluating the tool, reasoning that encrypting implied a commitment they had not yet made. That reasoning is backwards: the material was sensitive from the first day regardless of anybody’s confidence in the software, and the sensitivity never depended on that confidence. Anybody currently evaluating a tool with sensitive material should therefore apply the protection during the evaluation rather than after it, since the trial period is not exempt from the obligation.

How should a protected category be defined?

Broadly and without item-level judgment. A workable rule is that anything concerning an identifiable person other than yourself is protected, applied without assessing how sensitive any particular note is. Judgment at the point of creation is where inconsistency enters, particularly during a difficult week, and a blanket category removes the decision entirely. Whether the right boundary for a given profession involves tiers or a single password is a separate question, and having any explicit rule at all matters more than which rule is chosen. Writing the rule down as a sentence, rather than holding it as an intention, is what allows it to be applied consistently by somebody tired at the end of a long day.

Why do naming conventions matter more than features?

Because a wrong convention applied consistently is trivially fixable and no convention at all is not. Practitioners describe hashtags that drifted between singular and plural, hyphenated and unhyphenated, or between two words meaning the same thing, none of which mattered until a view that groups by those tags produced fourteen categories where there should have been five. The correction took evenings of finding variants across hundreds of entries, and would have been avoided entirely by writing down eight words before starting. The general form is that a tool cannot make material findable if the person creating it named the same thing three ways, and no feature compensates for that.

How should a tag or label vocabulary be maintained?

By writing it down physically somewhere that gets seen, rather than holding it in memory. A common approach is a single entry listing the agreed terms, starred so it appears in the daily panel, containing under ten items and rarely changed. Keeping the list visible is what prevents drift, since drift happens at moments of tiredness or distraction rather than through deliberate choice. Periodic auditing of the counts also helps, since a term applied to two items is usually a variant of something that already exists. Keeping it under about ten items is the other half of the discipline, since a vocabulary too large to hold in mind gets applied inconsistently regardless of where it is written down.

What is the right unit for an entry?

The thing you actually work on, revise, or are asked about, which differs by profession and is worth deciding explicitly. A shooting day, a patient, a matter, a maintenance incident, a lesson, a paper. The reliable test is whether the item has an identity that persists and accumulates: something with children over time is a page, while something that happens once and generates consequences is an entry with sections inside it. Getting this wrong produces either an unreadable list of fragments or entries so large that nothing inside them can be followed. Asking what you would rewrite or be questioned about in one sitting usually identifies the correct unit quickly, and it is worth answering before creating a few hundred items.

Should each document type be its own entry?

Usually not. Practitioners who created separate entries for each kind of paperwork report producing long flat lists that cannot be read as a sequence, and discovering the problem during a dispute when the answer to a question was distributed across four items in no obvious order. The stronger arrangement is one entry per event with sections for the parts of that event which have their own paper. Opening it then presents the whole sequence in order with each document at the point where it belongs. The resulting record also reads as a narrative rather than as a folder, which practitioners report ends disputes considerably faster than assembled files do.

Why attach files to a section rather than to the entry?

Because the section supplies the classification that a filename cannot. An entry accumulating nine or ten documents over months produces a flat list of names chosen by cameras, contractors, and office software, which nobody scans successfully. Attached to the section they concern, each file is identified by position: a photograph on the report section, an invoice on the invoice section, a rubric on the assessment section. The user then needs to remember what kind of thing they want rather than what it was called. It also means a colleague or successor can interpret the material without knowing anything about how the original filer thought about naming.

How much renaming of files is worth doing?

Roughly one in fifteen. Renaming everything is a full-time job with poor returns, while renaming nothing means a list that conveys nothing at the moment of looking. The files worth naming are the ones that carry weight: the photograph showing the damage, the invoice that became contentious, the document somebody will eventually ask about. Everything else stays as it arrived and remains findable through its contents, which is why the effort can be concentrated where it changes something. Doing it at the moment of attaching, rather than in a later cleanup pass, is what makes the habit survivable, since retrospective renaming almost never happens. It is also the clearest sign that the difficulty lies in adoption rather than in the software, which is where a new user’s attention is best spent.

Why do people underuse attachment content search?

Because they arrive with a habit of locating documents by remembering which record they belong to, and never think to question it. Discovery is usually accidental: somebody types a phrase in frustration and receives a document from a matter they have not considered in years. The practical recommendation is to test it deliberately in the first week on something known to exist only inside an attachment, since the experience changes how the tool is used immediately and no description substitutes for it. The discovery frequently changes a decision as well as a workflow, since a total assembled from years of documents tends to differ substantially from a remembered impression.

What does searchable content change about filing effort?

It removes the requirement to predict, at the moment of filing, how something will be wanted years later. That prediction was always the hard part and nobody makes it accurately. Once contents are searchable, the filing decision reduces to putting an item where the relevant entity lives, and the rest is handled by retrieval. Practitioners consistently describe their systems becoming simultaneously more rigorous and less laborious, which sounds contradictory until it has happened a few times. It also means poorly named material arriving from other people remains fully reachable, which removes a large source of friction in any profession with heavy incoming correspondence. The transfer works in both directions, and offering an account of your own mistakes is usually what prompts somebody else to offer theirs.

What is the difference between static and cumulative features?

A static feature behaves identically on the first day and the thousandth. A cumulative feature is worthless at the start by construction and becomes valuable in proportion to what has been fed into it. Suggestion systems trained by votes, mechanisms that surface forgotten material, and reports on personal working patterns all fall into the second category. Evaluating them early produces an accurate assessment of the present and a wrong conclusion about the future, and several long-term users describe losing a year to exactly that error. Deferring judgment on anything cumulative until a few hundred items exist is therefore sensible, and feeding it in the meantime costs almost nothing.

Why does a vote-trained suggestion system need early participation?

Because refusing to vote guarantees the outcome that justifies refusing to vote. Users who treat suggestions as fixed output rather than as a conversation form a private opinion and move on, the suggestions stay mediocre, and the initial assessment appears confirmed. Voting from the first week, including on obviously wrong suggestions, is what calibrates it, and downvotes are arguably more informative than upvotes because a wrong proposal describes a boundary. Noticeable improvement typically arrives within weeks rather than months. Doing it while already looking at an entry, rather than as a separate activity, is what makes the habit sustainable, since it costs a click and no thought.

How should somebody approach a migration from another tool?

By separating the two things it actually involves. Moving files is straightforward and frequently takes a morning, particularly where an import reads markdown directly. Deciding the structure is the real work, takes a few days of thought, and would be necessary regardless of which tool was involved. Practitioners who delayed for months usually discover afterward that their stated caution about data was reluctance to make structural decisions, and separating the two makes the whole thing considerably less daunting. Deciding the structure first also means the imported material lands somewhere sensible immediately rather than needing a second pass afterward. Asking a group directly what they got wrong, rather than what they recommend, tends to produce considerably more useful answers.

What is the fastest capture method and why does it matter most?

Whatever takes the fewest actions between having a thought and it being recorded permanently, which usually means a single control that opens a new item immediately from anywhere. It matters more than any organising feature because material never captured cannot be organised at all. Practitioners describe losing thoughts daily for years and attributing it to memory, when the actual cause was that writing something down cost more than the thought seemed worth at that moment. Lower the cost and the thought survives. Establishing this before learning anything else about organisation is the recommendation most long-term users make, since organisation is useless without material to organise.

Why do people not discover useful features for months?

Because they never go looking, having no reason to suspect anything is there. Discovery in practice is accidental: a control pressed by mistake, a colleague watching somebody work, a moment of frustration producing an experiment. A widely recommended remedy is to spend twenty minutes in the first week clicking every control in the editor to find out what each does, which is faster than reading anything and produces the same result as several months of accidental encounters. Asking somebody who has used the tool longer is equally effective and is roughly how most practices in this area actually spread between users. Settling three or four expensive decisions and then simply beginning is the approach every long-term user in such a discussion effectively describes, whatever else they say.

Why is showing your process to somebody else so valuable?

Because nobody can see their own workarounds from inside a habit. Every long-term user has a story of doing something manually for months while feeling perfectly satisfied, and in almost every case the correction came from another person watching. A pastor copying articles by hand, a baker fighting a button, an attorney deferring a migration, a researcher who had never voted on a suggestion: all of them were content until somebody asked a simple question. Demonstrating a workflow out loud, early, is the cheapest available diagnostic. The reviewer needs no expertise in the tool, only a willingness to ask why something is being done that way, which is a question people rarely put to themselves.

How does the cost of an operation affect whether information stays accurate?

Directly, because cost determines frequency and frequency determines currency. Anything expensive gets batched, and anything batched is out of date most of the time. A table maintained in a separate application gets updated three times a year and is stale in between, while the same table edited in place gets updated the moment new data arrives. This generalises to filing, capture, and archiving: reducing the cost of an action is usually more effective than resolving to perform it more often. When something is chronically out of date, the productive question is what makes updating it expensive rather than why nobody remembered to do it. Twelve compatible architectures arrived at independently is a stronger endorsement than twelve favourable reviews would be, since nobody was trying to agree.

Why archive external sources immediately rather than later?

Because anything outside your own system exists at somebody else’s discretion and a link is not a record. Pages get amended, replaced, and removed without notice by people who have no obligation to you. Practitioners who deferred archiving until the end of a research phase describe losing sources permanently, including material they had described accurately in a note, which is a description of evidence rather than the evidence itself. The archiving decision should also precede any judgment about significance, since significance is rarely knowable at the point of discovery. The ratio is favourable: most archived items turn out to be irrelevant and cost seconds each, while the occasional page that no longer exists can carry an entire argument.

What is the correct way to think about due dates and expiry dates?

As different categories with different consequences. A due date means something must be done by a certain point and missing it makes you late. An expiry means something stops being valid whether or not anybody acts, and missing it makes you unqualified, uninsured, or unapproved. Because remedying a lapse usually involves other people and formal processes, expiry warnings need horizons measured in months while due dates need days or weeks. Misclassifying one as the other produces discovery of a lapse rather than warning of one. Reviewing everything currently carrying a date, and reclassifying anything whose consequence is invalidity rather than lateness, is a short exercise worth doing once.

How long does it take to set up a working schedule?

Less than most people assume, which is why it gets deferred indefinitely. Practitioners describe about forty minutes to establish a full schedule for a working period: the recurring pattern first, then fixed obligations entered once with repeats rather than as individual instances, then anything with an expiry treated separately. The common failure is treating setup as requiring a free afternoon that never arrives, when the actual requirement is under an hour and produces reliability immediately. Entering recurring obligations once with a repeat, rather than as individual instances, is the part that determines whether the schedule stays accurate after the first month. This is worth keeping in mind when reading any collection of advice from experienced users, since their conclusions were expensive and their reasoning is the transferable part.

Why does a loose structure sometimes work better than a rigorous one?

Because rigid categorisation is comfortable, feels productive, and can substitute indefinitely for the difficult work it postpones. One contributor describes spending six weeks building a five-level taxonomy and nine days writing, and recognising afterward that categorising had a clear right answer at every step while the actual task did not. A loose structure also produces useful collisions: material sitting near other material for reasons nobody intended, which is what makes serendipitous rediscovery possible. The warning sign is spending substantially more time arranging material than using it, which is comfortable precisely because arranging has a clear right answer at every step. This is worth keeping in mind when reading any collection of advice from experienced users, since their conclusions were expensive and their reasoning is the transferable part.

When should a new page be created?

When enough material wants to live in it that the parent has become hard to scan, which one practitioner sets at about eleven entries. Before that, items can sit in the parent and be found by search, and if a proposed category never reaches the threshold then the page was never needed. This rule prevents the common failure of anticipating structure that never materialises, and it costs nothing to apply since creating the page later takes seconds and moving items into it is a drag. Applying a numeric threshold removes the judgment entirely, which is what stops a hierarchy sprouting branches that nobody ever opens.

What should a genuinely new user do in their first week?

Five things. Decide what an entry is and write it down. Choose a naming convention and a short tag list, on paper. Decide which category, if any, is protected, and apply it from the first item. Find the fastest capture method and use it. And spend twenty minutes clicking every control in the editor. Everything else, including how deep the hierarchy goes and which features turn out to matter, can be deferred until the material has said something about what it needs. None of the five takes more than twenty minutes, and together they prevent most of the corrections that long-term users describe having made painfully later.

Is there any advice in this collection that contradicts the rest?

One apparent contradiction, which resolves into a distinction. Eleven contributors advise more structure and earlier decisions; one advises starting looser and letting the shape emerge. Both are correct, because they concern different classes of decision. Anything expensive to change across hundreds of items should be settled early, while anything costing an evening should wait until the material provides information. The harm comes from misclassifying, and the more common direction of error is over-planning things that were always cheap to revise. That the twelve otherwise agreed, across healthcare, law, security, property, research, film, ministry, education, hospitality and maritime work, is itself the most informative thing about the collection.

Why do people in unrelated professions give such similar advice?

Because the underlying problem is structural rather than domain specific. A psychiatrist, a ship officer, a baker, and a patent attorney all accumulate material over years, need to attach evidence to interpretation, and must retrieve by association rather than by filename. The vocabulary differs completely while the shape does not, which is why the same short list of expensive decisions appears in every account. It also suggests the advice transfers: somebody in a profession not represented here can reasonably expect the same list to apply to them. This is worth keeping in mind when reading any collection of advice from experienced users, since their conclusions were expensive and their reasoning is the transferable part.

Is it worth reading advice from people in completely different fields?

Frequently more useful than reading peers, because colleagues share assumptions so thoroughly that the assumptions never surface. Somebody in an unrelated profession will question a choice that has never been examined, and the differences are what expose the reasoning behind each practice. Contributors to discussions of this kind routinely report taking a habit from somebody whose work has nothing in common with theirs, and describe those exchanges as producing more change than an equivalent conversation with a direct colleague would. This is worth keeping in mind when reading any collection of advice from experienced users, since their conclusions were expensive and their reasoning is the transferable part.

How should a group like this be used by somebody just starting?

By reading the regrets rather than the recommendations. A list of features somebody likes is of limited use, while a list of what they did wrong for eighteen months identifies precisely the decisions worth making deliberately. The most valuable posts in any such thread are the ones where somebody admits to a long period of inefficiency, since that admission is uncomfortable to give and answers the only question a new user actually has, which is what to do differently starting tomorrow. This is worth keeping in mind when reading any collection of advice from experienced users, since their conclusions were expensive and their reasoning is the transferable part.

What is the risk of trying to adopt all of this advice at once?

Producing exactly the over-planning that one contributor spent six weeks on. The correct response is to settle the small number of genuinely expensive decisions, then start working and let everything else emerge. Attempting to implement every practice described by twelve experienced users before creating any material means building an elaborate arrangement with no information about what it needs to hold. The advice was accumulated over years of use and is best adopted the same way. This is worth keeping in mind when reading any collection of advice from experienced users, since their conclusions were expensive and their reasoning is the transferable part.

What does this kind of collective testimony say about a tool?

That its range is wider than any individual account suggests, and that its learning curve has a shape worth naming. Twelve people arrived at compatible architectures without coordination, each got something wrong in their own way first, and none regretted the choice of tool itself. A product that can be misused in twelve different professions and still support all of them once its users find their footing has demonstrated something that no feature list conveys, which is flexibility that does not require specialised knowledge to exploit. This is worth keeping in mind when reading any collection of advice from experienced users, since their conclusions were expensive and their reasoning is the transferable part.