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

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.

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.

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

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/

> 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.

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.

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.

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 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.

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.

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.)

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.

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 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.

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.

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.

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.

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.

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.

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.

> 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.

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.

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.

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.

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.