
Ask HN: Personal Project Planning Tips? - random_kris
Hello everyone I am looking for tips and ideas on how you handle personal side projects?  
For example I am building a very simple web application, where I have rough idea what I want but I haven&#x27;t written any spec sheet or anything. I just code when I have little time....<p>ofcourse I have been developing this for past 4 months and I am almost finished but at the same time I have so many small things left to do and there are periods where I dont do any programming on this project for 14 days etc...<p>I am using asana for simple TODOs.. but those get outdated or I forget what exactly I am trying to achieve.<p>so I am looking for general advice and tips on this topic. thanks in advance!
======
rikroots
1\. Don't be scared if the project fails - for whatever reason. Failing can be
a good learning experience, if you choose to look at it that way.[see end]

2\. Don't be scared to abandon the project. When the work stops being fun ...
walk away! You can always revisit it at some point in the future, see if the
joy can be rekindled.[also see end]

3\. Todo lists are useful ... until they become a burden. I prefer to sketch
out some general aims for the project, and some milestones to aim for which I
can celebrate achieving. Don't make the project feel like work - unless you
really enjoy ticketing up issues and code bugs, in which case: go for it!

[see end] - My longest running personal project is my constructed world. I've
been working on it for over four decades now: maps, societies, biology,
languages ... whatever takes my interest at the time. Many parts of it have
been attempted, then abandoned as my mind moved on to the next Shiny.
Languages have been started over from scratch multiple times as I realise the
current iteration just doesn't work as a "language". I tend not to throw away
stuff as I can never tell if it might spark a new idea, a new direction,
months or years later.

Nobody's ever going to use my constructed world. It will never make any money
for me. I do it because the work gives me pleasure - and helps me stop
conversations at social gatherings.

[http://www.rikweb.co.uk/kalieda/index.php](http://www.rikweb.co.uk/kalieda/index.php)

~~~
random_kris
Hey thanks for your response. I am currently having an internal battle between
just shipping a product and following the best engineering practices and
actually defining what I really want to do....

For example I am building a proof of concept lottery game using bitcoins...
Quite simple and straightforward but when it comes to actual implementation I
find my lack of planning hurt me

------
Roybot
Alright after working on several projects on my own for a long time and now
with a small group for close to 2 years I've seen how some projects succeed
and how others fail to ship. So here are few thoughts to hopefully help.

You stated it yourself, plan first. Define exactly what you are shipping. If
you don't do this - it's going to feel like the development is never going to
end because it never really will end unless you have a well defined stopping
point __or __a set of features that you just won 't ship without.

A lot can be said on how you plan - this can vary widely based on the type of
project you are working on. You mentioned building a simple web application so
here's my advice for that - be very clear with the objective of your project
then use a method like moscow to prioritize feature ideas. Our minds run wild
during brainstorming but lets reel it in to factor in our time constraint. So
throw out everything non-essential - and when I mean non-essential it should
make you feel uncomfortable with the amount of stuff you throw out.

TODOs are a good step - my only practical recommendation here is to go up a
level of granularity. Define user stories/scenarios and/or features (I go
without defining features and just leave it at user stories since this is
enough for me) and tie your TODOs to these stories. Don't underestimate this
work. This will help you make that context switch between development and the
bigger picture of your project and who your users are.

I use GitHub and use their board to to tie in my issues with pull requests. If
you use github do that - keep your TODOs close to your code maybe even track
it in source control. Up to you.

> between just shipping a product and following the best engineering practices
> and actually defining what I really want to do....

Here are thoughts for your concerns. boiled down to a few words.

> shipping product

Plan.

> following the best engineering practices

Forget the deadline.

> actually defining what I really want to do

Stop and ponder.

------
avilesj
Write down your main features as bullet points:

* User authentication * Users can post products to be sold * Making orders to _other_ users

Move on to the details of those features

* User authentication -> Social login OR email authentication -> Usual features like reset password/forgot -> Most other features will only be available when authenticated

I try to keep progress measured by features and use kanban boards to keep
track of it. I don't go overboard with keeping everything in their lane and
the checklists updated because I tend to not update things as much as I wanted
to.

