Ask HN: How do I stop overthinking personal project management? | Hacker News Reader

Ask HN: How do I stop overthinking personal project management?

73 pointsmxfe67 comments

I am a solo dev working on a personal web project.

As ideas for features and enhancements are starting to accumulate, I feel that I need to introduce some structure to my process. However, every time (yes, I've done this many times before) I attempt to do so or try to add tools to my workflow , things quickly get OCD for me and I spend all of my time NOT working on the project but managing the project instead.

Thanks to this latest incarnation of madness I've done the following:

- Set up projects in Notion, GitHub Projects, and Jira, and compared them to one another to make THE BEST choice. - Began doing detailed documentation of requirements and tracking design decisions in Notion or Confluence. - Began thinking of what kind of process would be the best for me. What Kanban columns to set up? What issue types should I create? What labels to set up? Do I need to organize user stories into epics? Etc., etc., ad nauseam.

Meanwhile, somewhere deep inside I KNOW that all this is waaay overkill. That my time would be much better spent actually designing or writing code. Keeping things minimal and frictionless.

And yet, the lure of the perfect system is ever present. Maybe, just maybe, if I set things up right, this effort will be worth it. Maybe in the future I will want to know exactly what the thought process that made me choose one font over another was. Or how I came to decide which aspect ratio to use for the images. Maybe these things are important to keep track of?

But I suspect that all this specification and documentation is just going to result in a bunch of outdated artifacts specifying and documenting time well wasted. Because experience has shown that I am at my most productive with a structureless .md file and pen&paper setup.

Do you have any suggestions? How do you stop yourself from overthinking and over-engineering task/project management? How do you determine what is worth specifying/documenting/archiving, and what should be ephemeral and only exist for the sake of facilitating taking the next step? Thanks.

View on HN

> Do you have any suggestions?

You do:

> experience has shown that I am at my most productive with a structureless .md file and pen&paper setup.

Seems like you already know what works for you. Do that!

But since you’re asking, I’ll give another shout out to pen and paper. The thing I like about it is that it becomes physically overwhelming. That is key. When you dump information into a digital system you can avoid it and leave it to linger and grow indefinitely, but a bunch of papers strewn around your desk are harder to ignore. They begin to pile up and make working harder, at some point forcing you to deal with them. This means grabbing what’s around and starting to cross out what is not important after all (or was already done), and reorganising remaining tasks into new pieces of paper. The physicality of the process forces the cleanup step.

At one point I moved from separate pieces of paper to a notebook, but the principle remains: the filled pages to the left are the equivalent of the scattered pieces of paper. As that side of the notebook grows, I flip back to cross out tasks and rip the pages where everything is done. That step is important because otherwise I wouldn’t have an intuitive sense of how many tasks are left behind.

I have to disagree from personal experience; I did the same for a while but got into a paralysis when trying to find the right notes/tasks for a job but ending up having to write a whole new set of tasks causing unneeded fragmentation

What works for me is one single file with all my tasks ordered by priority, I can resort them comparing the top task to bottom until I have all my tasks sorted by priority, when a new task is added it's easy to tell where it slots in.

I find this easier to maintain, doesn't give me paralysis and things at the end can be culled if there too long.

> I have to disagree from personal experience

Of course, you do you! I don’t think any method will work for everyone, but since the OP already has some success with pen and paper…

I used to suffer from this, i.e. overplanning and over-organising as a means of combating anxiety associated with lack of progress or organisation. I've gone through every project management tool and todo app imaginable (I've written a few too). I don't know if this helps you, but here's the advice I would have given myself from 10 years ago:

1) Just use Github issues for high level tasks, and use checklists within issue body for task breakdowns. Categorise with labels, schedule with milestones. More tools, more problems.

2) Don't plan for more than a week (a more natural time unit than a two-week sprint). I.e. your execution should not lag your plans by more than a week. The further in the future a task is, the more time consuming it is to plan it, and less accurate the plan tends to be.

3) +1 for markdown files and paper notebooks. Don't try to categorise or organise. Just use a linear, chronological (more accurately, reverse chronological) stream of text. Search when you need.

4) Keep tabular data in spreadsheets (I use Google Sheets). Nothing fancy.

5) Keep documentation as close to the code as possible, or it will go out of sync. I usually try to stick to: module = file, and documentation = comment at the top of the file/module explaining the purpose of the module.

6) Look at your completed todo list more often than your incomplete todo list. The former is a source of dopamine, the latter, a source of anxiety.

Can relate to both you and the OP. More specifically, I too have tested out (and retested) almost every project management tool and often, every few months or so, tugged at mixing it all up, thinking I'll (re)discover some magical tool that'll solve all my problems. And if I'm honest, when taking a step back, it boils down to (as you mentioned): anxiety associated with lack of progress or organization.

Appreciate the advice you would've imparted on yourself 10 years ago. What stands out the most is "Don't plan for more than a week." When I read this, I noticed a thought come up: how does this person ensure that their short term (i.e. week) maps to long term goals/values etc?

There are plenty of PSYCHOLOGY tools. I myself from childhood practice eastern martial arts (Kung-fu). My friend practice Tai chi. Other examples are Yoga, or Buddhism. But also exists western ways, like just go to psychotherapist.

You are procrastinating. Your psychology is preventing you somehow from doing the work, because you have some inherent fear that is preventing you from getting started.

I am guilty of this too - I think we all are. It’s far easier to focus on productivity tools/processes because it feels productive, thus giving you feedback without actually doing the harder job of the actual work, and thus perhaps realizing your underlying fear of failure or fear of being judged / etc.

I agree with this. Some other reasons could be:

1) you are afraid you will fail

2) you actually don't want to do that project. This could be a lot of different reasons: e.g. you get excited about ideas, but quickly lose interest etc.

They say everybody essentially writes about themselves, in this case very true.

> They say everybody essentially writes about themselves, in this case very true.

Can you elaborate on this? Curious what you mean about how (in this instance) the OP is writing about themselves?

I meant I was writing about myself, these are my typical issues.

That last line is so true - sounds like a coping mechanism. Reminded me of this Substack post:

https://theteardown.substack.com/p/notes-about-notes

Edit: coping

I've had similar things in the past. What was the case for me, and maybe for you is that I was using the idea of "organizing" and "planning" to procrastinate doing actual work. I was working on difficult problems and I felt like if I could just organize everything correctly, the results would fall into place. This isn't how it works though, you need to just do the work.

Organization and tools like that can be helpful for communicating and coordinating across a company, but at the individual level it's usually a waste of time. You don't need them. Remember, the whole point is to get work done. If organizing isn't moving you closer to your goal, it's not doing it's job.

My suggestion is to do what I do now.

One list: TODO.txt.

I put tasks in priority order and just work through them. Sometimes I write a note or an idea at the bottom, but that's it. No over complication. It only has what I need to get the next thing done and keep moving through my tasks.

A more or less single-todo-file system got me through college, it’s a great approach.

Maybe the thing to realize is that the idea of BEST is very much in the realm of diminished returns. Being able to internalize that and the recognition that there is no single best, but varies for each new context will show that it's not a 'once and done' thing worth knowing. Don't make secondary goals a primary objective.

I find that jr devs are preoccupied with learning what's best for each category of thing. A more seasoned dev recognizes that everything's a trade-off, makes appropriate satisfactory picks and carries on pragmatically to get something end-to-end off the ground. Then they can iterate on the next most important area do improve.

The best way to get into that pragmatic loop is to have actual users providing feedback. It's much harder to justify optimizing something with little impact while there are real bugs or glaring missing features in the queue.

I have a home lab, but my family and friends use it so it's semi-production.

I write changes and thoughts in notes by date. That's my entire organization system.

Usually "installed X because it does Y, but it's $DESCRIPTIVE_WORDS_HERE". Occasionally something like "TODO: fix LDAP upgrade to move off of Debian 11"

If I want to remember when the server froze for seemingly no reason last year, I just search.

When did I install X app? Search.

If you are working on a project, you don't need a project management system.

There is always the one biggest thing you need to do to move the project to the next step. While doing that you might want to skip some small tasks or code cleanup. Those you mark with a Todo: in code like the good ol' days. Almost every editor has a Todos parser which you then use to cleanup when you feel like it.

Project management systems are almost always procrastination tools imo.

I launched a web based service when my employer went bust. It took me a couple of months over Christmas to get a clunky system good enough to deploy. It made a bit of money and I quickly smartened it up over the next 6 months. A year later I decided to do it properly, and guess what - I fell into where you are now. After many years the service had barely changed and became so "retro" it was a joke. Users dwindled and I closed it down. I think the moral is -

Set an aggressive launch date, keep to it whatever, and when you are done, repeat.

I don’t know what would help you. But I do know that I avoid hard things by doing “productive” and easy things too much. It’s a good way to avoid failure, but it’s even better at avoiding success.

Just the questions show you may be on the right path. I'd look for emotional blocks inhibiting the implementation/coding work. In my aged experience virtually all procrastination is based in emotion.

I found the "snacking" metaphor that I think I learned from here[1] really helped me understand why I would sometimes get stuck in these kinds of corners. Its reframing helped me do it less. I find I reach for snacking when I'm confronted with something that is hard, as a way of avoiding it.

[1] https://lethain.com/work-on-what-matters/

This is a good reframe. To summarize a key idea from that article for other readers (though the whole post is worth reading), the author recommends thinking of low-priority but arguably important work as "snacking" and a distraction from the most important tasks.

This is clever, as it's likely easier for people to admit that they are "snacking" versus "procrastinating," especially if the task they are snacking on seems vaguely productive or helpful.

Could you be using the planning as a form of procrastination? As a way to feel like you're making progress without tackling the parts that scare you?

Making a plan is a great way to break down a big task, but it's also a way to avoid facing difficulties.

My plans are usually a few dooedles in Notability. I might also let an idea simmer for a few weeks to let various problems resurface. After I start doing anything, I find that the best (design) lessons are learned through experimentation.

Go for a walk, come back and crank out some code. You can draw bridges all day, but eventually you must break soil and face the task at hand.

I struggle with this too. You need to find a process and system that work for your particular combination of needs and limitations.

My current best effort is pure-analog: I keep a small notebook for each distinct project. I also keep a box of index cards with dividers (now/next/tomorrow etc.) for things I’m working on. When I sit down to my workday, I start a list on a new index card, taking any needed leftovers from yesterday. I then schedule it into my planner for the day. If I need more space specific to a task, I start a new card and either put it or the active card in the “next” section.

The index cards serve to constrain the space and complexity of my active topic and to force me into a serial workflow. The notebooks are only for finalized plans and documentation, i.e. I treat them as the permanent record for the project and its higher-level organization. If I need to eventually I will organize an oldschool index card catalogue I can put references into in my notebooks but it’s nowhere near that complicated yet.

I also use emacs orgfiles for note-taking / “thinking in place” / as a scratchpad but I try to prioritize the analog system. It’s really efficient, and helps me control my complexity and avoid distractions. Digital systems easily get too big and complicated to manage.

Sometimes even something that seems positive (like organization or project management) can be a form of avoidance.

That's why the concept of "workability" can be helpful. When you find yourself spending time on project management instead of the project, you can ask "Is this workable? Is it serving me in the long run, or is it taking me away from the life I want to live?" Workability is contextual, so your judgment on it may change day to day.

I also have suffered from having too much process to keep track of work and personal experiments.

My solution is to just use simple notes like Apple Notes or Google Keep. It helps me to take a little time once a year to discard old notes that are no long useful.

I mean this genuinely: do you have anxiety? Because I do, and it can make it hard to handle uncertainty and the feeling of not having control. A big project, especially one with lots of things left to do, is the definition of uncertainty. So, instead of tackling the anxiety-inducing project work, you spend time trying to cope by erecting larger and larger edifices of organization. The problem is that this never actually helps, because rearranging Jira columns doesn't get code written. But it, briefly, makes you feel better, and can even feel like progress. It's a sort of avoidant mechanism. I have OCD, and one of my compulsions is counting. Anxiety is the actual problem, and counting is the maladaptive coping mechanism. It's possible that spending too much time on organization tools functions similarly.

If this affects other portions of your life, some mild therapy might not be a bad idea. Otherwise, you might consider trying a very lightweight system, like notes in a text file, but with very actionable goals and milestones. Start with your end result, and work backwards. What would it take to get to, say, a production web service? Then write TODOs as you break the chunks up. Crucially, tell yourself that you can totally do the work, and then do a small task. You know how to do the work, but it's easy to talk yourself out of it. And it won't always be easy, but so what? It's a personal project, the stakes are so low! And it's supposed to be fun anyway, not a chore. But you have to think about why you're worried so much about finding the perfect tool, because I think that's the root of the issue.

Caveat: not a psychologist, just someone who struggles with anxiety and a crippling inability to get things done. :) I hope this helps a bit.

I do have anxiety. I think it is exacerbated when I use digital tools because anything can be edited/improved at any time. I can expend considerable mental resources in analysis paralysis. What should I call this user story? Do I need to break it down into smaller ones? Is this description of the issue accurate or am I being sloppy with my thinking/writing? How much specification should I do before I start coding? Do I need to document my thinking process? Do I archive or delete the user story once it's done? Do I need to transfer any of the insights acquired while completing it into long-term storage, like a knowledge management system (Zettelkasten, Notion, Confluence, ...)? And so on.

Jira to me is like a playground of torture machines haha. Oh, I can link this issue to this Confluence page. Oh, I can build a custom workflow from scratch and set conditions for issue completion. Oh, I can limit the number of cards in a column.

The weird thing is that I KNOW that I don't need any of this shit. Because I've done this many times before only to then delete all these projects and databases and go back to pen and paper. And yet, sometimes I feel like THIS TIME I'll do it right and stick with the system long enough, until it begins to return on my investment with productivity and clarity dividends. But this never happens.

Recently I've been experimenting with keeping an engineering logbook. One notebook for EVERYTHING. No tearing out pages. Chronological order, naturally. I like that all of its power is contained within the limitations of its physical form. Funny how it's the limitations that liberate.

I am rambling. But this reminds me of one of my favorite quotes from Lao Tzu: "Do you have the patience to wait until your mud settles and the water is clear?" Project management, the way I am doing it, is like stirring the water and the mud trying to force clarity.

Honestly, I don't track what I want to do, I just track what I've done. Git commit logs with reasonable detail do that just fine. I also track bugs, but nothing about future features or enhancements.

The things that annoy me the most or get me the most excited get done. Usually this is driven by users repeatedly asking for it. My lack of brain capacity acts as a natural filter to forget the things I and my users don't desperately want.

I keep a notebook as well with pen and paper, and this lets me keep details of what I'm currently doing right this moment. I then also use that for very short term todo lists, but these are mostly "get back to person X" or "send accountant Y", it's not long term planning.

Obviously this isn't always perfect or appropriate, but it's my default for personal projects and it's made me a lot more relaxed about the management side. As a result, I get a lot more done.

If it’s a personal project, then my advice is not to be so hard on yourself. There’s no deadline. Each time you decide to spend time on your project, you can choose how you spend that time. If researching and project management tools is really scratching your itch, then great!

Obviously if this is your livelihood then you need to remember your priorities.

I have a hobby project I’ve been working on occasionally for the past few years now, and at this point I think I’ll only ever finish it if I take a bunch of time off work. But when I do spend time on it, I work on whatever part interests me the most. Sometimes that’s just planning! Sometimes it’s graph theory. It really just depends on my mood. If I’m not having fun then it isn’t worth doing.

A simple plain text document should be all the management you need.

Isn't it obvious to you that every bit of time and energy you spend managing is sucking at least as much from the project itself? You must know this.

Maybe you like management, too.

Premature optimisation is the root of all evil :) I was very much in your place a few years ago - the most flexible and responsive and useful place to have most planning is in your head: crystallising ideas and plans and all that just makes them brittle and a sharp failure point.

Most of these organisational tools are for multi-person orgs.

Your PKM should look very 'suboptimal' from the outside. You need much less conscious control than you're exerting. Let your system forget stuff.

It's infinitely better to have something completely undocumented than almost nothing extremely well-documented.

Step away for a while, spend some time in nature, then come back to whatever it is you're doing with a clear mind.

Whenever I take a break, I usually return with a better sense of what is and isn't worth my time.

I get my best work done during bicycle and car trips. I'll have my morning coffee, then hit the road and think about a problem for a few hours. My hands are holding the handlebars so I'm only allowed to think. I do this day after day for a few weeks.

By the time I'm behind a keyboard I have most things figured out.

For my side project i have a simple text note in a web notes app.

In that note i have a list of around 10 things i should do next, ordered by priority.

That's it. Either i work on one of the ten items or i do not. Only when i finish some items i add new ones. (Of course i also sometimes just reorder or delete stuff from the list.)

There are weeks where i do nothing and in those weeks i do not waste time with "busy work" but just look at the list from time to time and see that i am not motivated to work on the important stuff so i do not work on it at all.

Oh and i have a paper notebook where i sometimes sit in a coffeeshop and just do thinking by writing in the notebook. Thinking about the side project and its future. After the session i update the list of things to do.

> And yet, the lure of the perfect system is ever present

What evidence do you have that anyone has discovered this?

My impression is that highly productive people have will and focus, not a perfect project management system.

System building is a form of procrastination.

The solution is: Timebox every decision.

Tell yourself: "I'll give myself 15 minutes to make a decision in this area, and no more. Whatever the consequences of the decision be, I'll bear with it"

Also at a philosophical level, remember that immersion in the activity of choice is usually time well spent. One rarely regrets time spent with 100% involvement in anything. Optimise to get into flow, rather than optimising for mere information accumulation.

As a soloprenuer myself, I can say that the problem is understanding the goal. When your goal is unclear, there are too many paths to the solution. Some paths are too resource intensive or unfeasible.

From reading other successful soloprenuers the first goal should be: For idea X what is the quickest way to validate the idea.

Example: If I have an idea (like a previous article from today indie hacker article) to show a progress bar for followers on twitter (won't work today). Do I need a subscription mechanism? no. Do I need payment management? no. Do I need an admin console? no. So how do I do it? A form with an email+access key to write to a database or file. a crontab to run a script to update the profile photo. Done. Time to execute: 1 day.

Next task: get feedback to validate. Publish on my twitter account with funny or news related posts. See if people use the script.

If validated: Next goal, take money. Send email to users, that they can continue using for 4$. Send a form from some saas platform to subscribe. Manually remove non-payers.

From what that indie hacker writes he did a few thousand dollars this way. Sounds plausible.

Amazing how easy it is once the goals are completely clear.

The next goal could be, how do I increase my income. Do I need a new feature, new marketing channel, etc...

Do Not Worry

25 “Therefore I tell you, do not worry about your life, what you will eat or drink; or about your body, what you will wear. Is not life more than food, and the body more than clothes? 26 Look at the birds of the air; they do not sow or reap or store away in barns, and yet your heavenly Father feeds them. Are you not much more valuable than they? 27 Can any one of you by worrying add a single hour to your life?

28 “And why do you worry about clothes? See how the flowers of the field grow. They do not labor or spin. 29 Yet I tell you that not even Solomon in all his splendor was dressed like one of these. 30 If that is how God clothes the grass of the field, which is here today and tomorrow is thrown into the fire, will he not much more clothe you—you of little faith? 31 So do not worry, saying, ‘What shall we eat?’ or ‘What shall we drink?’ or ‘What shall we wear?’ 32 For the pagans run after all these things, and your heavenly Father knows that you need them. 33 But seek first his kingdom and his righteousness, and all these things will be given to you as well. 34 Therefore do not worry about tomorrow, for tomorrow will worry about itself. Each day has enough trouble of its own.

I worked with a very intelligent software engineer with a PhD in CS who encountered orgmode and it enticed him into the same OC spiral you are describing. He resolved the problem by switching to lab notebooks (8 1/2 x 11" or A4 size, don't remember which) and writing design plans, test notes, everything in pen or pencil. This worked well for him but obviously would not be everyone's solution.

If this is a personal web project that you get a few hours at a time...

If you like Notion, keep to it but don't use any fancy features. Just text and links. Skip anything else until you have at least five people. But you're just going to make a list of things. As you think of something, put it on the list.

Then, when you are working on it, cross them off. All you need is a basic Todo list at the step you care about. If this starts getting too big, you can split some of them off to a "someday/maybe" list. But that's only once you are building something.

If this doesn't end up being enough, you will see what you need to change.

Think lean. The next step is to write any notes that you care about remembering. A tool like Obsidian, LogSeq, org-mode or Notion can help here, but again, Apple Notes is enough. The trick is just to pick one.

While I think PARA is a good system, it is too much for what you need right now. You just need to dump things outside your brain. You can use search until it gets unwieldy, and organize later.

[Just in case it helps to offer a simple tool, but this is also self promotion I guess]

I'm working on a very simple tool to manage projects and tasks. The focus is around simple checkboxes and hierarchical structure. Behind the scenes it has the structure of block model editors where every line is a block, but it is presented as a regular text interface. This results in feeling as simple as a big ass text file, but with real data structure. Happy for anyone to join and test it out and help define a roadmap toward utility without ever becoming as overwhelming as something like notion or other block editors. Basically I love the simplicity of text files and want to create something that on the surface is as simple as a text file but has a whole lot of power under the hood.

https://trylist.io

Experienced technical project manager here, used to dealing with lots of teams across lots of organizations involving lots of money. Also an architect!

5-10 teams and 1-10m$ can be managed with a 15 minute daily meeting and an email that is sent immediately after the meeting.

You need less, but still need to organize your thoughts. Use a text file and work!

One simple hack is confine yourself to a single text file; the need to understand what is going on in the text file after a few weeks will make the text file correct meaning productive. (Or push you to a failure state. The general critique of literate programming is now you have to be good at two things.)

This is not technical question, but mostly psychology, so best answer you will find talking with good psychoanalyst if you cannot switch yourself.

To be more informational, I suggest google, how to accept the inevitable. As this is the most annoying thing in development, question, where to stop doing and become abstract observer, or switch to something more important.

In practice, this could be done by switching environment, go to gym, or even go to travel.

Some people could use meditation, some need just look good cinema, or even read good book, or just walk on street. It depends on how good person in regulation of his psychology.

Project management software is for working with other people. It’s a tax. You can waive this when going solo.

Apple Notes is enough, with simple checklists and freeform text blocks.

I divide things into two categories: now and not now.

I've settled with Jira for issue tracking, and Notion for documentation after years of internal battles. Once I start to treat Notion as an overqualified xlsx, everything started to make sense to me, it's just that Notion sucks at issue tracking, I had to make due with Jira (under-powered Cloud version).

I have a serious issue with over-thinking and over-engineering with personal projects. After I'm sick and tired of seeing myself doing these, I actually ended up with a psychiatrist, whom has put me on a ADHD evaluation, but still pending 2 more visits to know.

> Maybe, just maybe, if I set things up right, this effort will be worth it.

Worth it how? For your own curiosity or in some meaningfully productive way for your future self?

> Maybe in the future I will want to know exactly what the thought process that made me choose one font over another was

Maybe, but if it's trivial it's trivial so you don't need to remember it. If it was something you spent a lot of time deciding you probably are going to remember it anyway - if it was important. This kind of historical decision documentation becomes more useful when you have teams and want to onboard new people (and even then it has a limit)

> Do you have any suggestions? How do you stop yourself from overthinking and over-engineering task/project management?

For single-person projects you can go very simple. Most people are worried they're going to forget important tasks, but important tasks have a way of coming up again and again. I think storing list of items in a simple todo app or on paper is about all you need - this list can be as long as you want, but the longer it is the more diminishing the returns. Choose some small set of priorities you will do today - maybe 4-6 items. Do those then move down the list. Feel free to re-prioritize frequently.

> How do you determine what is worth specifying/documenting/archiving, and what should be ephemeral and only exist for the sake of facilitating taking the next step?

Specs are most useful in making you write, and thus helping you think. If you can't write it down you probably don't understand it. Small tasks don't need a lot of writing because you understand what you need and why. Specs are worth writing for the big items if you need to force yourself to think deeply. They're not important for historical purposes - once the feature, project, whatever is done, the spec is no longer needed. And in fact it's not very useful to review again as it's always better to review the thing you actually built instead of the spec (which in most cases will differ). Documentation (how to use the thing) can be useful if you want your future self to remember or others to use it - so document APIs, Libraries, things like that. Don't spend time documenting self-explanatory functionality.

First, OCD may require professional help if you can't manage it rationally.

With that being said, managing personal projects is simpler than "management" which involves human interations.

In short, start with a basic pen, paper or notepad-like software. Update it as shortcomings appear. Managing is like designing data structures or databases: it involves "reads" and "writes" (I actually mean "search and read" and "search and write", to be percise), starts simply, and is designed around use cases.

I've applied this to cooking. I used to struggle finding spices in a deep drawer. I realized they were organized like a stack, making it difficult to reach the ones at the back. I moved them to a wider drawer. The frequent used ones shuffles to the front, whereas the less used are left in the back. And with time, I memorized their rough locations.

This process mirrored data structure design: starting with a minimal structure (linked list), moving to a more complex one when it becomes slow (search trees), and further improving it when it gets imbalanced (AVL tree). You'll not going to invent red–black tree in the first place - even copy it from the text book is a pain.

This perspective can be applied to anything - digital data, paper systems, or physical spaces. 'Reads' and 'writes' costs are determined by the system you use. System efficiency depends on its use case and time as costs are "amortized".

A few examples:

Diary: Easy to write, harder to read. Low overhead makes it enjoyable to write.

Dictionary: Takes longer to write, quicker to read. The large audience justifies the high writing cost for well-organized indexes.

Research notes: Balanced read-write (citations and knowledge graph). Constantly evolving knowledge even makes folders inadequate, hence the popularity of software like Obsidian and systems like Zettelkastens. But such systems take efforts to build so most people adopt instead of developing their own.

RDBMS: Balanced read-write but difficult to develop.

Kafka-ish DB: Designed for high-speed writing. RDBMS is too slow for its use case due to constant indexing.

Your system will depend on your use case, which will emerge over time.

Over the years I have tried Trello, Asana, Notion, Airtable, Jira, GitHub Issues, Shortcut, EverNote, etc.

I settled with Obsidian for notes, and Linear for tasks.

With Obsidian, it lets you separate personal, career, and business notes thru files and folders.

With Linear, it lets you separate projects by workspaces, it lets you separate tasks by sprints (or cycles), it lets you separate tasks for teams oncce you have people working for you.

OCD is a mental illness that has nothing to do with neatness, it’s a life-interrupting illness. You’re not engaging in OCD behaviours. “OCD” as a colloquialism for being organised is something we should avoid so that we do not downplay the harsh reality of OCD or downplay the support people with OCD often need. The desire to be organised is the desire to be organised, you can say that instead.

I like to say I’m anal retentive about being organized. This, I think, gets to the heart of why this colloquialism even exists/persists. “Desire to be organized” doesn’t fully capture the _intensity_ that some feel to be organized. However, I couldn’t agree more with everything you’ve said. This colloquialism needs to die.

You are right. I should have been more careful with my choice of words.

I developed a culture of laziness. With this comes great focus and time optimal solutions.

At most there will be a TODO file in the directory the project is unceremoniously thrown into. If it’s not obvious what it does I might write a couple of lines in a README. VCS rarely. Ticketing or project management software, never!

About 15 years ago I brought a whole product to market and sold it without any of those things being done!

Check out his videos on the topic: https://www.youtube.com/@smatla

I started with text file, which is often the best way for me for any management thing as JIRA/tools get too complex and I often miss things in UI Text file was also great as it was straight in my IDE and I could move it to done at the bottom of the page. Now I migrated to Asana/kanban, becouse text file got to big, but only after half of year of development.

Think of PKM as another project with an unclear set of requirements. You have something released (what you've set up so far), now use it and reflect. Slowly iterate where you notice friction, and if you don't notice meaningful friction, it's good enough for right now.

Things might change down the line, but the perfect system really is the one that sticks for the time being.

Trackers like that are for teams. You are one person, you know what you need to work on at any given moment. If you don't, a simple TODO.txt or even TODOS in the code will get the job done.

What you are doing is a form of procrastination (something I struggle with as well) and why I'm getting tested for ADHD meanwhile.

For now, Just do It(tm). Put that stupid meme video on youtube if it helps.

Dedicate some time to organization - maybe it's a couple of hours in the morning, maybe it's one day a week.

Whenever you have an idea, dump it in your .md file. Organize that file during your organization time. The rest of the time, just do something. If you aren't sure what to do, do the first thing in the file.

All that energy needs to be channeled into happy feedback from clients, hence results. Have you considered asking for calls 1:1 with clients and make them happy with the value your product creates or prospect the most valuable easier to implement feature/adjust you can add to your product?

I used to have this problem, where I could fall into these deep rabbit holes optimizing todo management, editor configuration, notes, Linux desktop configuration etc.

With age I have gotten better at recognizing them and avoiding them by just picking good-enough solutions.

An example of a rabbit hole few years ago: I got the NixOS bug a wanted to declaratively define my whole system and dot files with Nix. Many hours were spent making everything declarative and the setup required regular maintenance (things change/break all the time in nixpkgs).

At some point I realized that I can set up a Mac in a good-enough state in an hour or so, and I do a clean macOS install maybe yearly. One hour in a year was far less time than maintaining a declarative system (still great for managing many servers though).

Example of avoiding a rabbit hole recently: I wanted to do more note taking. I recognized that this can be a potential rabbit hole for me. So I just chose what everyone recommends (Obsidian) and use it as a simple note store without thinking much about structure (we have search).

Deep rabbit holes are only worth it, if it concerns our main work and the outcomes are potentially very positive (like if you are working on performance in a product and a deep dive could potentially remove a nasty bottleneck).

tl;dr: train to recognize your rabbit holes/nerd snipes, and learn to say no to them. You might still fall into a hole occasionally, but that is part of the learning process. You’ll get better at recognizing them earlier.

Skim through a ~100 page booklet called MCDP 5: Planning, published by the US Marine Corps as official training documentation. Once you are done reading, swear to yourself that you will not go on a reading binge and look up other books on planning or time management. The link (PDF) is at: https://www.marines.mil/Portals/1/Publications/MCDP%205%20Pl...

I've felt your pain in the past, and the principles from this booklet have helped me a great deal. For example, I got a team far more productive and happier with minimal overhead in terms of planning software (we mostly just used a few Google Sheets for task tracking), than other teams that I've been on (that relied a lot on various project management software—while there is a time and place for these tools, I felt that their usage added unnecessary complexity).

For a summary of some principles that helped:

* A key quote is at the start of Chapter 2, though it's a bit trite now: "[A] good plan violently executed now is better than a perfect plan next week."

* In more practical terms, you should always have a strong bias to keeping your planning simple and flexible, instead of adding complexity through software.

* To do this, you need a clearly defined goal with clearly defined objectives. You should also include a clear "why" behind your decisions, to orient yourself when you face confusion.

You can immediately apply these principles to your personal situation. Your goal right now is simple: spend less time using project management software, and get right to work. What would be a simple way for you to do this? (This may involve simply committing to not using any software whatsoever, and sticking to a .txt or .markdown file or even just a pen and paper. I've read from your post that you really are most productive with paper or an .md file, so you know what to do.)

Outside of planning, you also mentioned documentation. I'll resist giving a recommendation of a method as it sounds like that is not what you need. Instead, I recommend keeping it simple and sticking to a OneNote notebook (or its equivalent in Obsidian because you already know markdown; but if this is new to you, no need to bother with learning at all at this point in time), and having your past notes easily searchable (this is exactly how I've kept track of favoured hex colour codes and image aspect ratios in the past).

Lastly, for evaluating what notes to archive versus throw away, there are a couple of approaches. A more complex approach is to create a list of temporary or "fleeting" notes and then manually sort them regularly into notes to make permanent, or notes to throw away. But a simpler approach that also works great is to lean on keeping most of your documentation notes for a project in a folder (or virtual notebook) for that project, and relying on search to find the information as needed.

To summarize: have a strong bias for simplicity, with a clear understanding of "why" you are doing particular tasks. (For nuance, I acknowledge that sometimes, long, detailed plans have been very effective in certain contexts, such as in 20th-century history and likely in present-day aviation—but I've personally found my planning to be best in most contexts, by starting plans as simple as possible, and only adding complexity as absolutely necessary.)

Whatever you do don't visit https://www.outlinersoftware.com if you want to curb your compulsive-reactive information management.

Is your plan to work for yourself/by yourself in the future? If so, this is overkill.

If you are planning on working for/with others, then all you're doing is becoming accustomed to the tools you'll need. So it's not overkill.

Sometimes it helps to jump in the cold water and just start building. In other words: Don't worry about what not to do but start doing what you want to accomplish.

I like the cold water analogy and what it suggests: embrace pain. The preparative dread is much worse than the thrill of being in cold water.

OP here. Thanks, everyone, for your generous advice. It's been great to read your comments. You've helped me see more clearly. Best of luck to all!

I'd lean towards doing zero planning and documenting and focus just building and thinking.

Reply on news.ycombinator.com