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

73 pointsby ciaobenover 8 years ago

I am a solo developer who loves to work on side projects in parallel his regular job.I am REALLY struggling to manage them, I need some system that:- does not require more work to keep updated than the project itself - it quickly gives me the ability to understand at what point of the project I am. Often pass days or week from the last time I have been able to work on the project, and I need something that helps me having the general view of the status I left the project last time and what are the next steps. - improves my ability to track the different aspects of the project. Whatever they are different functionalities or other more broad aspects as marketing strategies....I know are hard requirements, but I am not looking for a tool suggestion, but a method or some suggestions to find the right path.Developing software products has a lot of facets (technical, and not!), and I am losing among them, I need someone who can show me the way :)

37 comments

ChuckMcMover 8 years ago

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.

评论 #12549225 未加载

评论 #12552598 未加载

评论 #12549515 未加载

评论 #12550648 未加载

评论 #12549440 未加载

评论 #12549633 未加载

thr0waway1239over 8 years ago

I agree with the predominant two suggestions here: to use Trello, and to do a little more planning up front.But it also looks like you are having some issues with getting back into the zone quickly, without too much overhead. A trick that writers use is to apparently write an incomplete line at the end of the draft. You can try something similar - depending on your project, this could be something as simple a quick note on something you can do in exactly 5 minutes the next time you set down with some detailed steps if possible (for additional context).Its just a suggestion, which is unfortunately not backed by personal experience (I have faced other challenges with my side projects but not the one you mention).

评论 #12549613 未加载

mosselmanover 8 years ago

Trello works pretty well for me.I usually create a new board with 3 columns:Backlog - Doing - DoneYou create any amount of cards in backlog and as you start to work on something you can leave comments on your status "Started working on live updates, trying to figure out if websockets are better than polling", etc.You can easily forget to update cards so an alternative is to leave comments in your code:```` def some_method<pre><code> User.where(email: 'aj # TODO: I WAS HERE, continue fixing the query!</code></pre> end ```By leaving this change open in git you can easily see it when you run `git diff`For my one big side project I keep a notebook (moleskine) with thoughts and notes. I write down the current date when I make one and usually where I am.

评论 #12549165 未加载

lazylesterover 8 years ago

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!

评论 #12549427 未加载

vineetover 8 years ago

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

blcArmadilloover 8 years ago

I know you said you're not asking for a specific tool recommendation but it sounds like you want something like Trello (trello.com). Basically you first need to come up with the individual tasks that are needed to complete the project. At first you'll likely miss things but as you're developing you can add new tasks. For each of these tasks you'll create a card. Then on the Trello board you'll have vertical columns called lists. A simple set of lists would be:<pre><code> - Backlog: Tasks that haven't been worked on - In progress: Tasks you're working on - Complete: Tasks that are finished </code></pre> You can always add more lists if your workflow requires it (e.g. adding a "In testing" list). All your tasks/cards will start in the "Backlog" list. It's also a good idea to roughly order them in priority. You can then pick the highest priority task and move it into the "In progress" list. Once you've completed the task you can move the card to the "Complete" list. Then grab the next highest priority task from the "Backlog" and repeat the process over again.When you come back from not working on the project for a while all you have to do is look at what task(s) you have in the "In progress" list. If that information isn't enough to figure out where you left off, the task is likely to broad and should be broken down into more detailed tasks. After doing this a few times you'll get more used to creating tasks at the appropriate level of detail--it's just something you have to learn from doing.

lobo_tuertoover 8 years ago

I recommend putting a TODO file in your projects' root folder.You will use this file to take a _snapshot_ of your current status. Be as detailed as wanted, you need this to recover the context you were in before walking away from it.

luckyshotover 8 years ago

I tried spreadsheets, bug trackers, self made tools...But for a few years now I've been using Trello with the (open sourced) Agile SCRUM Chrome Extension<a href="https://chrome.google.com/webstore/detail/agile-scrum-for-trello-bo/njmflagahgdhopbcdilgahjlfiecakpe?hl=en" rel="nofollow">https://chrome.google.com/webstore/detail/agile-scrum-for-tr...</a>It is a very quick methodology to manage all my projects as well as estimate timings and effort for everything. I set how many hours I want to work a week, estimate each task duration and priority and the extension can tell me how long it will take to finish each milestone and release dates.Organizing boards on Trello:I have one board with an overall view of all the projects in a Kanban style (To Do, In progress, Completed) and then one board for each project with their lists (To Do, In progress, Testing, Completed) and follow a loose non-strict Agile SCRUM methodology.

cheriotover 8 years ago

I've ended up with two different methods of similar (over?) simplicity. The fun part of side projects is that there's less communication and priorities are based on little more than our own interest.1. A TODO text file on the project root. It's harder to get more natural that editing in vim or whatever you use. I keep different lists for features, tech debt, research, etc and slowly pluck items into the immediate todo list. What's the point of a commit? Check the line deleted from TODO2. Google Keep is surprisingly great. Every project I work on has at least one list there so I can jot notes down where ever I am. Even offline. Some projects are entirely in Keep.Remember why you started a project. Is it for fun? Focus on the thing that interests you most right now. Profit? Focus on proving your biggest assumption.

asimuvPRover 8 years ago

I use notebooks like this commenter: <a href="https://news.ycombinator.com/item?id=12549098" rel="nofollow">https://news.ycombinator.com/item?id=12549098</a>Now, I've also researched this for a while. My latest approach was to develop a git-like command line application (named nica) that allowed me to keep notes, track issues, and pretty much manage the project. It works by creating a hidden directory (like git) and the data is stored in JSON files (because I planned on doing web interface. The aim is to include everything related to the project inside the git repo. So you would not need to use a web interface to know the issues of a particular code base. You could do:<pre><code> nica issues </code></pre> and it would print out a list of open issues. Then you'd do:<pre><code> nica issue -n 100 </code></pre> and it would open issue #100.I built it to understand how to move away from commercial services like github while giving devs a way to host their project data online. There is a web server being developed that would provide the ability to pull/push nica data and a web interface. The only problem I had was with conflicts due to how the data was inside the git repo. But I have not spent any time solving it.Note that I slowed down development because I'm working on another project (V2V, V2I, and V2S communication for automated cars). It is not a commercial or open source project (pure research). Its being written with python and click (library for command line apps by the team behind flask).

6DMover 8 years ago

There's a few different approaches to this:1. Set a deadline and go for it. This can take up a lot of your time and make you feel burned out. I'm assuming you want to avoid this.2. Assume it will take longer to release than you would like, but incrementally make progress each week.I am currently #2 after trying #1 with a completely new stack. I eventually decided that it's better to workout with my significant other a day of the week to work on the project. We decided Sunday would work best for us. If this is your case I really recommend you keep your time flexible and be willing to "swap" days or switch to 1 hr each day after work.Now that you established a schedule, you will need to maintain two lists. A short list is what you need to work on next. A long list is what you want to accomplish and release in the big scheme of things.With your two lists, you will prioritize. If you get hung up on something, is it really that necessary? Can you live without it until after your "release".Keep a rough estimate going, it will give you an ok timeline and help you further prioritize.This strategy has helped me a lot, I hope to release my side project at the end of this year. :)

评论 #12549200 未加载

emilburzoover 8 years ago

It sounds like you're not really satisfied with the digital stuff.So here's a crazy idea: you might benefit from having actual (real) folders for each project with scribbles in them.Even though it feels like a waste of paper, for some reason it works better for me.Maybe because I don't have to open an app for that, it's just like a second screen (without sacrificing your second screen).

DanielBMarkhamover 8 years ago

This is going to sound trivial, but I've always been a big fan of writing down whatever I'm worried about on a post-it and sticking it on my monitor.If I have too many items and the post-its fall off, I'm being too aggressive. If I have two projects, I use two colors for my post-its.The problem with any electronic or free-form system like pencil and paper is that it is far, far too easy to type things in than it is to accomplish things. Your goal is not to create a version of your mind. Your goal is to prompt yourself enough so that you're ready to begin doing the next important thing the next time you sit down.So set your filter to maximum and only track the bare minimum you need to pick the work back up. Trust me, once you're back in it again, the next batch of things will come to mind -- and as you work, you'll work through both the strategic and tactical items, coming up with whatever the new batch of post-its will be before you finish.

bloafover 8 years ago

Here's what I want in my ideal personal code environment.1. Literate programmingI want to be able to write methods/functions in something like a Jupyter notebook, with text and section headings. This is a great way to both comment the code and to organize to-do lists. I want the text in these documents to have weak ties to the actual code (e.g. have method renaming apply to the text as well.) I should be able to toggle between "plain code" and "Jupyter style" views.2. Ability to share modules across projectsDid I write some code to make state machines for project A? I should not have to copy paste it to get state machines into project B, I should be able to share the code between them. Something like Visual Studio's shared projects, but less wonky.3. Audio recordingI suck at writing notes to myself, especially in exploratory code. However, I sometimes find myself thinking out loud. Why not allow recording of the thinking out loud, so I can hear what I was thinking later.

pcestradaover 8 years ago

I keep a journal using Google Docs. Whenever I make an entry, I have the date and a brief summary of any interesting thoughts related to the project, URL links, etc. I always keep a TODO list of what to work on next. This helps immensely when picking up the project again after a while to figure out what I was working on.

fumonkoover 8 years ago

If you're an emacs user, definitely check out org mode. Or if you've wanted an excuse to check out emacs, org mode may be a reason for you to make the move.It's insanely powerful but not for everybody.<a href="http://orgmode.org" rel="nofollow">http://orgmode.org</a>

评论 #12549389 未加载

baccheionover 8 years ago

Use a project management tool (as though you were contracting things out to someone), then occasionally transfer things to it from a notepad or text file (or your memory).Write down a list of todos or whatever you're trying to do, then write notes next to each as you progress. Usually, once you have a good sense of what you're trying to do (are clear on the details and on what's required to fully implement everything), then it all becomes straightforward.I'm not sure what else to say, as I usually don't need any "outside assistance" once I'm clear on what I'm trying to do, and essentially just scribble notes wherever is convenient when I need to (when I'd forget otherwise).

fotbrover 8 years ago

I used Trello for quite a while, and still use it for some things. In addition to the suggested "backlog, doing, done" columns, I have another "stopping thoughts" column, where I keep a few notes about what I was thinking when I quit working on the project for the day/week/whatever".I've mostly switched to a self-hosted, local-to-my-dev-laptop-only jira instance, since I also use jira for regular job work. I've found that kan-ban type boards are fine for the tech side of a project, but I do like the other project management stuff that jira brings; and being the only user of it, I don't have to worry about the way I use it negatively affecting anyone else.

ibizamanover 8 years ago

On my side, I don't manage all of them quite well. But those I have the easiest to come back to are by far those where I spent time automating things. Either setting up a dev environment with docker, having automated tests, integrating with a CI platform, having added tickets on a tracker platform, etc.I think the more the state is explicit, the easiest it is because I'm clearly not good at documenting stuff.Btw, I try to keep all of those things on my local server. I have JIRA, Stash and Bamboo installed, a docker registry, and a few bunch of other stuff all behind haproxy doing the SSL termination. I like using a tracker understanding code that way I can seamlessly link from/to PRs, commits and branches.

jenkstomover 8 years ago

I am transitioning to gitlab. It's had issues, but a recent version lets you put them onto a board similar to Trello. I'm waiting on a screen replacement for my primary development laptop (from China, via slow air boat apparently) to really dive into it.But I do agree with the "getting back into it" issue. I will go weeks or months between working on a project, and this is the biggest hurdle I'm facing. Some of the suggestions here are great. I'm thinking what I may do is try to leave a single issue under "Development" on the boards and make sure it is commented well enough to pick it back up.

MichaelBurgeover 8 years ago

Usually before I start any project at all, I'll write a couple pages summary in a Google doc. I'll consider implementation, but I won't try to plan out the entire implementation since it always changes.I keep a separate Google doc(or a Trello or Kanbanflow board) with a list of specific pending tasks. This is designed to be easy to grab tasks off of without having to think much.If it's been so long since I last did anything that I don't understand any of the tasks, I'll take 30 minutes to update the summary and task documents.

talkingtabover 8 years ago

alias demo='vim "$(git rev-parse --show-toplevel)"/demo.txt'I have a bunch of these aliases for files I use for specific purposes. "demo.txt" holds a description of my next waypoint- I call it demo because it has to be something I can show. There are aliases for bugs, howto, etc.I don't have to use an external tool, as I'm working on some code I can just type "bug" at the command line and enter some text. Not super high tech but easy enough that I actually use it.

pjc50over 8 years ago

The best tool for this may be a paper notebook. Especially if you interleave it with something like the "pomodoro" 25 minute work units. Then spend a few minutes writing down what you did and what you expect to look at next, what unsolved problems you have, etc. before going back to the computer.(I tend to do this at work with Notepad, but in the past I've found the medium shift to pen and paper useful in itself for changing mode of thought)

评论 #12549070 未加载

kaizensozeover 8 years ago

I just have a folder of text files for each project. Even if it's trying out a git project, I'll record the setup process and TODO list as I go in case I need to re-setup the project from scratch at a later time. To maintain a decent SNR and keep my active projects grouped together, I'll have an archived folder and place a project in there when I'm no longer actively working on it.

mediusover 8 years ago

Trello works well for me. I make lists for In Progress, Today, This week, This month and Backlog/Icebox. Planning involves creating and organizing tasks in these lists. I move the tasks between the lists as I work through them. It gives me a good way to pickup where I left off. I use the Checklist feature to manage subtasks for each task.It's been working well without any extensions/plugins.

tmalyover 8 years ago

I use bitbucket right now as my version control. I was using trello to help me keep track of what I want to do, but I have found a simple TODO.txt file in my repository to be much simpler.Make sure you commit frequently, use tags, and find a good way to handle dependencies with the language you are using.I use a Makefile to build all aspects of my side project, and deployment is very straight forward on a vps I rent.

buro9over 8 years ago

I use pivotal tracker to record tasks and then prioritise them and work through them.It's good in that, if I don't work on it for a month or two then nothing changes.When I start working on something... everything changes and the estimates come forward and it auto-generates the idea of a sprint, spacing work out over coming weeks based on your velocity.It's nice.

praveensterover 8 years ago

I took the overall concepts from StrikeThru <a href="http://striketh.ru/" rel="nofollow">http://striketh.ru/</a> but instead of using a paper notebook, I use OneNote. It works really well across desktop and mobile. Plus, since it is in electronic form, searching is very easy.

everlostover 8 years ago

I have a folder called Projects in my tasks app (Wunderlist), with each project listed as a to-do item, and their status listed as subtasks.At the start of every week, I move one of these projects to my Inbox, update the subtasks to match current thoughts, work on the top few, and move project back at end of week.

gravypodover 8 years ago

Estimate the time it will take you to complete a project, wait for a time slot like that to appear, hammer it out. Bug fixes after the initial stable release should be minimal, so should needed features.Use your lack of time to promote good planning before a project is started as well as to prevent feature creep.

topogiosover 8 years ago

I use issue tracking, having a list of 3-5 next features I would like to implement. With a detailed description of the feature and potential upcoming challenges, this works well to get back in the groove when having been away from the project for some time.

dmanover 8 years ago

I add compiler errors in bits that i suspect are half done before I leave a project for any period of time. On return its fairly obvious what I need to fix.

Jtsummersover 8 years ago

The main thing I've found to help when juggling multiple side projects is to reduce the friction and the number of tools involved.I live in the terminal with tmux, emacs, org-mode, and git. My projects get an index.org in their base directory which describes the purpose and tasks involved. I've moved to (but this isn't essential to the concept of reducing friction) literate programming, and each source file ends up with its own org file as well [0], like foo.org for foo.c. My index.org contains a list of bugs, features, etc. as headlines. Each of those headlines contain notes on reproducing the bug, identifying where it occurred, specifying where the feature will be placed, etc. Specific things inside it become TODOs, which can be quickly found by (in org-mode) doing C-c / t which will highlight all TODO tasks in the file. In foo.org I use the same approach. I have an outline of the source file:<pre><code> * Purpose * Includes * Declarations * [0/3] Definitions ** TODO foo_bar: int -> int ** TODO foo_baz: char* -> int ** TODO foo_quux: void -> void </code></pre> So now everything I need to know about the project is in one place. And by virtue of it all being in the repository (and hopefully backed up somewhere online like github or my personal server, when I had one), I can easily move between computers (modulo tooling, but mostly I just need emacs + git + tup + <compiler>).I can also put a great deal of configuration information into this. What tools need to be installed, what are my dependencies (for packages/crates/etc.) and why do I depend on them. As I'm starting to play with docker and containers, I can include all the steps needed to reproduce the environment and configuration.So by reducing the number of places I need to look for information to a handful of org files, I've greatly reduced the effort required to resume a project. I can also do everything offline, which is great for me because an open web browser means I'll lose the evening's productive hours.[0] I originally did one big org file that spit out files into src/foo.c and inc/foo.h, etc. But that became annoying so I switched to individual files. This improved my ability to reuse code from one project to another (these being personal projects I'm not always spending enough time to justify producing a proper library). And it helped with make/tup because a change to foo.org only affects things depending on foo.c, where index.org would affect many build rules because it produced so many files. Fine in a small project, annoying in anything big.

segmondyover 8 years ago

I use Phabricator and Google Sheets.

JohnLeTigreover 8 years ago

I use Todolist from AbstractSpoon

UK-ALover 8 years ago

Personal Kanban

git-pullover 8 years ago

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] <a href="https://github.com/tony/tmuxp" rel="nofollow">https://github.com/tony/tmuxp</a> [2] <a href="https://github.com/tony/tmuxp/blob/master/.tmuxp.yaml" rel="nofollow">https://github.com/tony/tmuxp/blob/master/.tmuxp.yaml</a> [3] <a href="https://github.com/tony/tmuxp/blob/master/bootstrap_env.py" rel="nofollow">https://github.com/tony/tmuxp/blob/master/bootstrap_env.py</a> [4] <a href="https://github.com/tony/vcspull" rel="nofollow">https://github.com/tony/vcspull</a> [5] <a href="https://github.com/tony/.dot-config/blob/master/.vcspull.yaml" rel="nofollow">https://github.com/tony/.dot-config/blob/master/.vcspull.yam...</a>