Ask HN: How do you manage your personal software projects?

I use Microsoft OneNote for this. Searchability is fine, but if you write down the context of what you are working on, you can save minutes to hours picking up where you left off.

I use a notebook. One that I write in using a pen. When stopping for the evening/day/whatever I take 5 - 10 minutes to write in my notebook what part of the project is working, what has been changed, open questions, and a list of three things to do next. You can think of it like having a standup meeting with myself :-). When I go back to the project, I thumb back through the pages in my notebook until I find the last "log entry", read it, and them make a notation with a page number of the next open page in my notebook and an arrow to the right. Then I flip to the open page put the project name on it, and put a left arrow notation to the page where the previous update was.

By working this way my note book contains a bunch of doubly linked list of pages which are the log of a particular project, but the number of projects is not bounded. If I want to review a project from start to finish that is pretty easy to do, and the act of actually writing in my notebook affixes the information in my head more thoroughly than writing it into a computer file does.

I have tried a lot of things and failed at keeping them up.

The two big tips that I think have worked best for me over the years, is:

- Let your code repository do most of the talking. I don't stop a work session without committing what I have been working on, and therefore I work really hard to split any work item into small chunks. Also, given that I am sometimes interrupted in the middle of some work, it really helps to try to get the code committed after every few lines of work.

- Keep the management tooling really simple, the more complex it is the harder it will be to manage. I have evolved into keeping 2-3 types of documents (in evernote): an operations cheat sheet (how to start the code, and manually how to do things especially if I have not automated it) and 2-3 types of todo lists preferable on one page (some which I need to do in an hour, others which would be good to do, and finally some which will revolutionize the industry :-) ).

I'll bite, but I actually authored two tools I use to manage personal / open source projects. So while I can't fit your question exactly, I'll share what's worked well for me over the past years.

Break your project out into open source components. This gives the community a library, which makes it possible (but not guaranteed) to share responsibility to it.

It also keeps things fresh, you can keep the core of your personal project closed, so there is less moving parts to track, and hopefully less dead code on it. I’ve many “personal projects” end up getting mothballed amounting to time wasted due to me just chucking all my code in one repo and not breaking out components / pulling in the right libs when I could.

I've participated on a lot of open source projects over the years, so I’ve developed a workflow to organize the minutiae. There are times where I won’t re-open a project for a few months, so I need to be able to “snap back into” a familiar environment.

- tmuxp [1], a session manager for tmux. It allows using a .tmuxp.yaml file [2] to load a project workspace in combination with a bootstrap file [3] to automatically launch a tmux environment with tests, documentation, etc. I mimic this workflow in all my other projects.

It has worked for me across OS X, Linux, FreeBSD. On local and ssh machines. No IDE required.

Passively, another thing I do is document very well. If its python, I keep docstrings, autodoc for API generation and sphinx everywhere. Even personal projects I do at work have sphinx docs for other developers to peruse. I’m consciously doing everything possible to be helpful to other programmers on the project. Give them API docs, examples, as much as you can.

- vcspull [4] is a tool I use to declaratively manage projects in a yaml file [5]. When I want to update I just type ‘vcspull project1 project2 project3’. What’s nice is being able to pattern match projects I have, ‘vcspull django-\*’ to grab django extensions.

On projects I patch, I add my fork as a remote to keep it in sync.

So the above are my taste. YMMV. Here are some other things:

For C/C++ projects / libs, stuff like CMake [6] for build systems is great. Gets me a build that finds libs on OS X, FreeBSD and Linux. I’ve ported windows only projects in SDL2 to work across all 3 easily thanks to it.

There are other mindset things, try to strike a balance between being opinionated in your own flow (as I am), because you’re going to have another person who swears to Eclipse, then another one to Atom, you can’t make everyone happy. Invest in things universally helpful (api documentation, tests, linting), they end up helping you in the end no matter where your project ends up: Even if you wrote stuff, if you don’t document, you’ll be at a loss when you wrote stuff a year ago “Did I really write that”? With other developers, they can't read your mind, they keep into the grind faster when you explained what your project does and what your code quality / expectations are.

[1] https://github.com/tony/tmuxp [2] https://github.com/tony/tmuxp/blob/master/.tmuxp.yaml [3] https://github.com/tony/tmuxp/blob/master/bootstrap_env.py [4] https://github.com/tony/vcspull [5] https://github.com/tony/.dot-config/blob/master/.vcspull.yam...

Personally I use TDD (or more precisely BDD) for this purpose. If I leave the project overnight, or for a week or a month, I can come back to it, run the tests, and the failing and/or pending tests tell me what I was doing when I last worked on it.

So I always leave an in-process development project with failing tests. If they're all green, I don't know what to do next!