Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Solo devs, how do you plan your development?
338 points by going_to_800 on Dec 30, 2019 | hide | past | favorite | 182 comments
I'm wondering what framework do you use to plan your product development.

Right now I'm using just Trello with a 4 lists, Planned, In-progress, Staging and Production. Works ok but I feel I can do better, like adding a progress % or something to get a better overview of my tasks.

Are you using any agile framework that's simple and good enough for a solo dev (and maybe to support a team of max 3 more devs in the near future)?

Many comments are focusing on kanban procedures, but the most important parts of solo development for me are social milestones. For example...

* Who will I show X feature to?

* When will I show it to them?

* Can I show them a draft?

To me, the biggest risk of solo development is not how I manage a todo list, but that I'll build the wrong thing, because I waited to get feedback.

Some things that have helped me a lot...

* set up a time to show someone your progress on feature X before you feel totally ready to.

* ask someone to try and pick up and tweak some layer of your code (or pair with them)

* if you are developing a library--record hour long screencasts where you use it in a realistic way. Prioritize issues where you say, "oh, I should fix that...". Repeat but with another person driving.

I use github projects and a calendar (the calendar appointments feel more important!)

This is really good advice even if you are not a solo dev. A lot of devs that I have worked with (and this includes me at times) come with the expectation that they will be handed a task with a list of requirements, and all they have to do is check off the boxes and turn in the code. If QA found no bugs, then it's good.

Even when things really are that clear cut, junior developers still often need a lot of feedback that they are on the right track. Part of maturing out of that initial stage comes from when you can autonomously take a well defined task, break it down into steps, and execute it.

Maturing to the next stage requires that you be comfortable working in situations where the requirements are not clear or set in stone. At that point, your objective is not merely compliance with the spec (if there even is one) but that the code solves the problem as intended. Since developers are rarely in a situation to determine that for themselves, you have to become comfortable again with asking for feedback.

That makes a lot of sense!

> Part of maturing out of that initial stage comes from when you can autonomously take a well defined task, break it down into steps, and execute it.

It seems like this is the scariest part--since often whether a task is well defined feels more like an assumption. In a lot of ways, I think this is the value of social approaches--you have to answer, "how could I convince so-and-so that this is well defined?"

On validation: totally! Its nice to have a set of people who use your app regularly or at least at times you ask a related question. Many times the last, finishing idea of a feature came from a "tester".

100%. I'm essentially solo in a larger group of "stakeholders" and shoot & share videos on a semi-daily basis to verify progress. More frequent dependent on the complexity & uncertainty. But I try not to overestimate my own certainty on a feature.

People generally appreciate being kept in the loop, and that they can review on their own time. It also helps me to drive towards a level of completeness that I can show something in a 1-2 min video.

I have a file called todo.txt, with the current tasks at the top, and everything else below that. It is in version control.

As I finish stuff, I delete it out of the file.

I add new stuff towards the top if I want to do it soon, towards the bottom if I want to save it for later.

For things which are just ideas, I have a second file called brainstorm.txt.

I use a todo.diff - so the text editor color codes my lines started with `+` and `-`

Similarly, I use todo.md, and have VIM highlight "[ ]", "[x]", "[>]", "[v]", and "[-]" for bullet-journal-like TODO, DONE, Deferred, Dropped, and FAILED, respectively.

(too late to edit)

Like this: https://github.com/jodavaho/bashlog

wow. Thanks for the tip

That's such a hack, I love it.

So you add tasks starting with `-` and change them to `+` when they're "checked off"?

Nice!! There is a cool Todo plugin for Sublime that I used for like a year.

Love it: simple and easy to maintain. Thank you for this great idea!

I'm stealing this.

Pretty neat trick.

wow. great trick!!

This is what I do too. I tried using things like Trello but found the friction to be too high. I use org mode instead of a regular .txt file though.

+1 for org-mode. I also used Trello. Once I found beorg for iOS, I decided to switch everything to org-mode.

More love for org-mode for development. You can also schedule items for major milestones ( or anything ).

That's almost word-for-word what I like.

I'm actually pretty certain this approach, with the TODO file in VC, would work fine at least up until 4-6 developers, as long as everyone hits a basic level of competence -- but in practice, someone always suggests a more structured tool well before that point.

I'm old school, so I just constantly email myself replies to my past email with a reply to a past email with a past email with a todo list that I freshly created after finally crossing off the old ones.

It helps me sleep to add stuff to my todo list so I can offload anxiety about remembering said thing. It's great, I stole it a bit from a Buddhist meditation practice, but found I didn't trust promises I made to myself that if something is important I'll remember it later. Too much important stuff is planning and I don't like needing to burden others with reminding me to do things.

I use a similar approach, but with a VSC extension. I use this one: https://github.com/fabiospampinato/vscode-todo-plus, although I bet there are plenty others and for your editor of choice.

This is awesome! Thanks.

Does anyone else have a problem that this file just keeps growing?

It does grow quite a bit. Sometimes I go through the whole file and take out things which I've finished. I haven't found this to be much of a problem.

My problem is that I lose track of where all of my todo files are; I work on too many (client) projects to keep everything in a single file.

Luckily, over time todos tend to become todon'ts, so losing track of the old ones isn't generally a problem.


I use todo.md, and have VIM highlight "[ ]", "[x]", "[>]", "[v]", and "[-]" for bullet-journal-like TODO, DONE, Deferred, Dropped, and FAILED, respectively.

Mine is called SCRATCHPAD.md. :D

Writing down the brainstorm stuff is important to me because if I don't write it down, I am tempted to drop what I'm doing and work on my ideas or else lose them. If I went and implemented every random idea that popped into my head, I'd never get anything done as was the case for me in the past. I write these huge long essays to get my ideas and frame of mind fully described and that usually satisfies me to where I don't have to drop everything and implement the idea right there.

Literally exactly what I do. I also wake up at 3 am with an idea and put it as a reminder on my calendar.

Similar to that, but I try to group the tasks into upcoming releases. It's quite an effective way of forcing myself to do the unglamorous fixes along with the whizzbang new features.

based on your name, im guessing you have a `password.txt` also ?

Do you judge people by looking at their usernames, or by checking whether they end their sentences with "also" also? ;)

:) I find humour in odd places I guess, no ?

Yeah, I put once "experienced kamikaze" as a role in my resume. Frequency of interview requests did not change ...

I’ve been doing the same thing (todo.txt) for a while, surprised to learn it’s not just me. I like separating out brainstorm.txt, that would help keep it focused.

Same here, though I handle the ordering loosely.

Basically bubble sorting the list frequently based largely on a combination of impact and what I feel like doing at the moment.

I use Trello, then it gets messy, switch to Keep to start over, that gets confusing or messy, I have a txt file with my todos, that gets messy, I try a project management tool like Basecamp, doesn't do the trick, start over fresh on Trello, that gets messy.... I think you see where I'm going with this.

I have a very similar process, except I also insert "Let me start (over) building something to manage this properly" into each cycle.

Allocate a few minutes everyday to clearing up and planning the trello board. Same as you would a kanban board.

I actually settled on 2 text markdown files. One for short term and one for long term tasks and notes. I usually have a list pending tasks and a list of done tasks in each file somewhere (usually at the top). Sometimes I include some very detailed notes in there too, giving each one it's own h2 title (##) and new sections almost always get added to the top of the file rather than the bottom. I also never delete anything, but I have an '## Archive' section at the bottom where I'll periodically move stuff to. I'll also rearrange the sections sometimes to make them all hang together better.

It gets messy, but it's flexible, and when I run it through a markdown formatter it looks fairly nice.

I also use a text file to keep a daily development note, like a blog post but keep it in the project’s root just for me to see what’s I’ve done and what I’m planning to do in the next day.

Do you add a new entry every day to the top of the file? Do you check this into git?

Almost everyday, or days when I work on the project. To the bottom of the file.

I do this in all projects usually.

Someone else mentioned using a little post-it notes. I do that at work but never considered the extent to which it helps limit how much I can write, forcing me to more pragmatic about my list.

I sometimes try to plan things on a bigger piece of paper or on my computer in txt file but it always gets super messy. I usually prefer to use a post-it note anyway, so I never really thought it about it.

Could you elaborate on how things get messy?

For me:

Trello: boards get stale

Txt file todos: more todos are added each day, none get removed because of new ones added!

Basecamp: same issue as Trello.

In this second half of my career I've dealt mostly in startup development. MVPs just pivot too much. It's a ride.

what do you think about auto delete tasks?

I’ve been using Notion to integrate the kanban board, free form notes & references, client proposal documents, etc. all into one place.

I use Restyaboard to integrate the kanban board, probably the best looking and working kanban out there.

Same happened to me. For me outliners were a good enough solution. (Like moo.do)

Most tools have a lot of overhead. As a solo dev, your advantage is speed, but a little friction and grist is needed sometimes.

It takes only an hour or so to restructure it for more than one person, so cross the bridge when you get there.

For to do lists I use Sublime+PlainTasks plugin. It's fast, sticks in your head. If you want something cloud, Workflowy might be good too.

Without a product manager or scrum master it's also easy to get into tunnel vision and stray. I sometimes enjoy having an extra person to bounce ideas off and tell me to keep on track. If it's a startup, get a co-founder, give them 10%-50% just to tell you listen to you. It seems a little unfair, but it's worked for me.

Another trick would be a design doc to remind you of design decisions. I'm happiest with this format: https://random-character-generator.com/whatisthis

I agree, for my open source it's based on what I need and I throw code in and out quite fast. I have a mental "list" of things that bother me so I try to do these when I have a moment. If I forget something in the list, it was never important by definition.

This is mostly for projects made for fun though, I would not recommend this for a startup-like solo dev.

Edit: I also do an overview from time to time of the projects as a whole and decide if a larger feature is important.

I use the concept of demo days - where I demo something to myself. Some people would think of it as a sprint, but a demo enforces that it is something I can actually show. Like "I can launch the program and have it say print 'hello'". In my experience this works much better than stages or percentages. Lots of things just fall out. A demo that has bugs is not a demo for example.

I use a stack of demos, each as a 3x5 card. Low overhead, easy and quick to modify, etc.

As a solo dev it is was too easy to get lost in the process and tools, but this works well for me.

As many other have suggested, I found ClubHouse [1] to be the best balance for solo dev.

I have tested and worked with many. Asana, JIRA, Trello were all tested alone and with small or medium sized teams. None were as simple to use and clean as clubhouse.

It was always hard to keep the big picture while going into details with theses software. But with Clubhouse am using Iteration to define the big picture and the planning of the upcoming weeks and it just works great.

Their support team is on Slack and reactive to feedback. The software seems really progressing well and the UX is polished and well thought. They really are building a cool product.

Note that I have no affiliation of any kind with any of theses software. It's just my personal taste and experience of the last ~ 10 years of software development and project management (am a Product Owner in a software company).

Wondering what will be the next one I'll use after Clubhouse.. time will tell!

[1] see https://app.clubhouse.io for more

I will second Clubhouse as a great tool. It’s far better thought out than Jira and attuned to software life cycles unlike Trello.

I use github projects with a Research/Maybe, Todo, In Progress, Testing, and Done columns. Each item has a checklist of steps needed to complete the item. For example, I might have an item that is "Workers have an inventory" and a bunch of steps to do that "Add an inventory component, add a take item event, etc." that are markdown checkboxes.

This lets me do some 'design' via listing out all the classes/touchpoints, while still giving me the flexibility to tear stuff up, shuffle it around, and not lose state.

I'll also often keep one text file with very tactical todos, stuff I was in the middle of typing out when interrupted, so I can quickly get back into flow state.

I do pretty much the same manually with Kanbanflow (columns represent days, leftmost is "now/current", rightmost is whatever's pushed later to my next sprint). I combine this with a pomodoro color-code for "short/easy" (1 pomo), "medium" (2-3 pomo), "long/hard" (4+) and plan my day.

I took this from uncle Bob, you just give things a rating (unitless). "Oh, that's a 6, no less!", "oh that's a 2 at most". It's enough for development (I find it's only management that wants more 'reporting' and 'estimates', being solo I do that in medias res, i.e. on the spot).

However you got me curious with github projects. It seems it would integrate better for programming / design. I definitely have to experiment! Any tips to boot?

I use an org-mode text file for simple project management. It has two sections: Todo and Release. The Todo section has the todo items; some are marked as #feature for high level functionality and as #bug for bugs. Todo's have a life cycle of TODO/WORKING/DONE/CANCELED. When a release is made, the done items are moved to the Release section. A release has two lists: Feature and Changes. The done features are moved under the Feature list and other done items are moved under the Changes list. The Todo section manages the current tasks and the Release section captures the history.

Add new feature or ideas to the end of the todo list. Add related todo's under a feature line. Add bugs as they are found. The order of the todo items is the priority. Move them around as needed. When canceling a todo, record the reason, so in case if it comes up again, you have a record of decision. That's it. It's pretty simple.

Below is a sample from one of my side projects (solo dev).

    * Todo
    ** DONE Filter out Export Panel page when doing session snapshot.
    ** DONE Add command "Optimize Tab Favicon" on the Utilities tab in Preferences.
    ** DONE #BUG cancelled dialog causes double event firings on the next dialog action.
    ** WORKING #FEATURE dark theme mode support.
    ** WORKING Add light theme, dark theme, and default theme.  Refactor CSS.
    ** TODO Apply theme to components.
    ** TODO #FEATURE session push to remote devices.
    ** TODO #FEATURE Localization.

    * Release 2.11, 04/02/2019
    ** Feature:
    - #FEATURE Package the custom Web Components with the addon distribution.
    ** Changes:
    - #BUG All the dialogs are not showing, due to the missing custom components in the distribution package.
    - #BUG Error when a pinned tab is restored with the 'discarded' flag set, for lazily loading.
    - Restore active, reader-mode, or pinned tab as fully loaded tab, no lazily loading for them.

    * Release 2.10, 03/14/2019

    * Release 2.9, 02/21/2019

I use two paper notebooks per project: one for planning/architecture/schematics which is used for more long form writing.

Second notebook is for todo items (like add name validation for model Item). When I finish something I cross it out. I usually scan past two or three pages, so many things are left in void. Thats actually a good thing, if something is important I just write it again on fresh page + I occasionally go through wider history to check if something important was not left behind.

+ I keep Notes app open all the times with note per project. Here I keep list similar to the Todo notebook but it contains things that have to be done. Once I am done with task I delete the line.

Basically paper notebooks are for development of fresh features and Notes is for bugs and fixes of production code.

Fancy tools are for teams, because everyone editing todo.txt eventually gets messy. It is not like you can't use the fancy tools, but if you expect them to somehow improve your work flow, prepare to be disappointed.

The thing about working solo is that you can get away with a lot less communication and writing stuff down. Depending on your memory you probably still should put a few core ideas on paper/file. As long as you are prepared to delete as necessary, putting ideas in code right away might work.

I've been experimenting with a TODO for every branch and then merging the TODO into the main TODO when you merge to master. For example, you have a main TODO that has the general things you want to do. When you open up a new branch, you create a new TODO file named after the branch in the TODO directory. You move the TODO items that you are going to do into the new file (and add extra details). You work on that TODO and when you are finished with the branch, you move any not-DONE items into the main TODO file. This will cause occasional merge conflicts, but since you should probably inspect the priority of close items, it's not really a problem.

I've mostly done it just for myself, but have occasionally tried it with 1 or 2 other people. It seems to work reasonably well. The only real downside that I've found is that if you want to take the TODO items out of the master branch when you are working on them, it requires another commit to master, which is unfortunate. However, in doing that, your master branch has a TODO file for every branch that it in active development, so it's not really that bad...

I've not really lured anybody away from Trello, though. People like their specialised GUI ;-) Org-mode/MD just doesn't do it for a lot of people.

I eventually learned (the hard way) to start getting users from day 1. Before I start coding something, I start with paper and pen and find a user.

I build (quickly, usually always hardcoded stuff) it and show to user. They like / dislike it, and I go back and I fix it.

At the same time, I get more users (usually through meetup groups and making friends). People are flaky, they stop using my app eventually so I plan to make a steady stream of friends / users.

Eventually I find someone who wants to help. We go out to get users together and share weekly what features are most requested.

Now I have 8 developers. The people who interacts with the most users have the biggest say in what to work on next, whether it be refactoring, bug fix, or feature build. We started using post-its, but now we are using gitlab issues list and monthly milestones.

I hope to continue this forever so I don't lose touch with what is good for the user. I don't care about data nor the people who create the data, I want to always interact and make friends with my users so I can always make vision driven decisions and not get manipulated by misrepresented data.

A trick I've come up with is to "fake" the initial product. One time I put a loading time of 1 day to process some data, but I'm actually doing it manually when I got home. Eventually, to save my time, I write a script to automate my work away.

I use github's kanban board and like the concept of Kanban overall. Some people don't realise that Kanban is quite the opposite of Scrum.

One variation that has worked for me / peers over the years is having a "Next 5" column. i.e. something bigger than Current but smaller than the backlog.

That enables always having a practical, prioritized mid-term plan (assuming you regularly tweak the Next 5 selection).

At the same time you don't stress about a supposed deadline for forthcoming work. You just pick the next card, only when the current one is done. That's called "Flexibility in prioritization" as per asyncmanifesto.

Me too. I recently realized that you can have user level projects instead of repo level. This was a sticking point for me because sometimes a project goes across repos.


I’ve tried almost every tools out there but for some reason the one that makes me the most productive is just a plain old pen and a notebook. It is what keeps me in line and focused.

I don’t even write much useful stuffs on it but it keeps me actively engaged on my tasks. So I just have it next to me at all times.

I don’t even look at previous pages so I tend to write what I need to be doing that day.

Same for me. I feel like all these tools just get in your way and you end up spending more time writing cards and todo items than actually crossing them off the list.

I'm insane, so I just create a parent task in taskwarrior: "build real estate app for client x"

Then anything that falls directly under that is a blocking task:

- "build backend to serve api"

- "build frontend" (this might be blocked by the one above, or not, depending on what it really does) - repeat ad naueseum until those big tasks are broken down enough for me to visualize

Using a project might be nice to get a progress bar, but sometimes something I need to do doesn't fall exactly under this project, or might affect existing projects:

- increase block storage for shared server

So I just use a single, parent task, and have child tasks that block it. That way I always know what to do next, and I keep going until it's all done.

This is the same process I use on a whiteboard to plan out complex projects at work with my team. It's a nice way to see what tasks can be worked on simultaneously in non-solo work too.

As a side project I'm currently working on a tool to do this planning visually.

My sole gripe with TW is the lack of a pretty GUI and a power mobile app. Both problems I can solve on my own, mind you, but still...

Plus I know it'll be a huge problem if I ever have to work with anyone else.

Personal Kanban: http://personalkanban.com/pk/personal-kanban-101/

Try the book.

After the book, you’ll be better equipped to scale from 2 or 3 devs to 20 or 30 devs while remaining low overhead, because you’ll understand the essence of iterative and collaborative development versus what’s been watered down and ceremonialized into Agile/SCRUM.

Thank you! Finished the book already since reading your comment. Very simple, and encourages (and shows examples of) personalized variants, experimentation with the system etc. I like it. Gonna start today.

I've been just deleting things from TO DO lists when done.. which isn't very satisfying!

I use Google Docs. It's accessible from my laptop and phone and anywhere I go. It also has offline mode and auto-syncs when I reconnect to the Internet. Here's my format:


- todo1

- todo2

#Dec 2019

Mon 2019/12/30

- Done

- Assessment

- Next

Sun 2019/12/29


I also have a big picture sheet for tracking multiple tasks at a high level. Each column is a project, and each cell is a milestone/task currently being worked on for that project. They are color-coded. If yellow, they're being worked on. If red, they're blocked by others. If green, they're done.

I also use Google Docs. I think it's the easiest and fastest to keep up to date and synced across devices. I put main milestones ("version" releases) at top with core features I want to implement and then a bulleted (and sub-bulleted) list of ToDos by prioritized feature below that. At the bottom I have a dump of both future ideas and resources. Has worked well so far.

I use a bullet journal.

I find that I can do the product and project planning much more efficiently with a pen and paper. Something about getting my eyes off of a screen really helps me refocus my thinking. I really like that, with a bujo, you have to periodically make an intentional decision whether to retain or forget any un-completed to-do items. (I've yet to find a technological solution that doesn't make it way too easy to accumulate clutter.) I like that the limited space forces me to focus on the essentials of each item, which helps me to stick to the agile principle of delaying decisions to the last responsible moment.

I don't bother with swim lanes, columns, task states, or anything like that when I'm working solo. All of those concepts were invented to help make it easier for a project manager (or scrum master, or whoever) to keep track of and coordinate the efforts of many people on a team. Humans suck at multitasking, so, if you're solo, you shouldn't have more than one or two items in progress at a time. Meaning you shouldn't have any need for techniques that are designed to help keep track of lots of things at once.

I don't find much value in a non-paper solution because the main advantage of electronic solutions is to help with intra-team communication on a geographically distributed team. If you're an army of one, there's no intra-team communication or geographic distribution to manage in the first place.

> (I've yet to find a technological solution that doesn't make it way too easy to accumulate clutter.)

Try NotePlan (https://noteplan.co)

I've been doing Trello.

Instead of a "Done" list, I make one with my next version number (e.g. 4.1).

Then, after I release 4.1, I move that list to a "Releases" board and replace it on the work board with 4.2.

Github issues and milestones for me.

Generally I put all features, ideas, bugs, etc into small granular issues that I can ideally complete in a day or two. I’ll group them into milestones representing high level goals (“implement video editor”, “v1.1 release”, etc) and then prioritize issues accordingly into a kanban dashboard.

I find that this method takes little extra time and lets me separate my development brain from my project management brain. I can come up with high level design and compose goals, then start hacking away later in tiny sprints without needing to think too much about how things fit together. Issue comments are also great places to record ideas when you’re e.g. at a bar with friends and have a sudden breakthrough that you want to jot down.

Most importantly though it helps with motivation, since it’s usually much easier to pick up my laptop knowing I’ll be able to achieve something that day rather than making incremental progress towards a larger goal.

There are two levels of organization. Time level (which projects when, meetings, sprints, time allocation) and project level (user stories).

For the time level stuff, I use Google Calendar. This allows me to plan development work for the various projects around any meetings that end up on my calendar.

For the project level stuff, I use JIRA in kanban format with Blocked, Backlog, In Progress, For Review, Done.

I've been doing it this way for more than a decade ...

> Works ok but I feel I can do better, like adding a progress % or something to get a better overview of my tasks.

JIRA will give you a burn-down chart automatically, but honestly, that stuff is worthless.

One piece of advice. Do not kick back user stories unless there was a defect in the work. If you want to add something or do something differently, make a new story and mark that one as done. It kills morale to see the same stuff over and over again, makes it look like you're not making progress.

Perhaps I'm too old school, but pen and paper works best for me at least for short term planning, for more general/longer term roadmap GitHub project boards do the job.

I've been a fan of regular github issues and milestones and labels.

I'll typically have milestones for the next 2 or 3 releases, and then use labels for tracking bugs, features and future items and nice-to-haves. I like this because it makes it easy to keep the code linked to issues the way I'm used to with my day job.

The nice thing is it lets me wear two separate hats. Some days I don't have the mental bandwidth to code, or I'm feeling extra creative when it comes to coming up with roadmap ideas, so I'll go into the issues and just write. On other days, I just open the issues, filter by bugs or features and grab an item and get to work.

I've tried Trello and Basecamp, but having that separate from the code just made too much overhead to keep track of. Having everything under one roof makes it so I actually end up adhering to the list of tasks.

I use pen and paper, it gets messy, then I pull out the paper and re-write the list on a new paper. Then I try and do the things written, but often start doing all kinds of new things that are not written, and only when I think of something that seems "cool" do I write it down to not forget.

I do this too. Having to rewrite old items every week or so once the front page is full makes me reconsider if they're worth doing at all. It's pretty effective.

Ironically I started doing it when I was working at a bank where online tools were forbidden and the programming environment sucked but it stuck with me even after.

+1 for a solo dev there's really no point in using typical "collaboration" tools. They just add work.

I tend to use a simple txt, it is always open on my editor, and I put there the TODO, or any bug I found, markdown format. If I have to persist this information I tend to use github issues and use a PR flows, but in general a txt is more than fine, just use that. If you get fancier than that I can assure you will get dizzy on tools. I've been working like that for 6 months in a row, alone. And I have to tell you when I'm tired of backend programming I move to the frontend , doing some visual adjustments, just for fun and mental health, then I switch back to the backend and so on, also this cycles are switched by testing, design, programming, flow design etc...

I use Taskwarrior (https://taskwarrior.org/) because it's digital, simple, customizable and open-source. Gives me just enough flexibility without complicating things. It's a shell-based tool which makes it very portable and easy to automate.

The workflow is centered around "tasks", which can be as simple as a description. You can add tags to tasks, filter by tags, set task priorities & due dates and assign tasks to a project. Much more to love, I recommend checking it out if the above description interests you.

I use github issues with custom tags (bug, feature, docs, tests, etc). I am not too picky about what goes into the issue list, as long as it has a good title and description. I use a github project board to prioritize what to work on with a simple kanban setup. The backlog column is ranked with upcoming items up top and never more than 2 features “in progress” at once. This setup helps me focus on what I need to knock out without too much mental overhead, and is especially helpful when I come back to a project after a break. I also use the github milestone feature to track issues that roll up into releases. At the end of the milestone, I copy the list of completed issues more ore less verbatim into the changelog. I keep the setup as lightweight as possible, and avoid 3rd party integrations at all costs. The linking UX between the 3 features I use (issues, projects, and milestones) makes navigating the project convenient, without feeling like I am locking myself into github as a vendor. I avoid putting too much work into the kanban backlog beyond what’s in progress or next up for this reason, and releases are kept small so I could recreate them in a few minutes in a text file if I moved to another platform like sourcehut. In general, I avoid getting too far away from a basic todo list. Tools like Jira or Asana have loads of features that provide little value to a developer and a lot of lock-in.

Why 2 features in parallel and not just one?

Do you have external dependencies that block your progress, or is it to be able to switch between them and not always do the same thing? Or something else entirely?

Sometimes I like to alternate between two features or bug fixes just to stay motivated with a bit of variety. It does break the kanban spirit a bit, but I avoid allowing anything to hang out too long in the “in progress” column to prevent procrastinating on a tough issue. Most of the time I only have one issue in progress at a time.

As someone who recently started working for a startup with no computer science/coding background, this thread has been insanely helpful and relatable based on my experiences working in accounting/healthcare.

It's almost enlightening hearing similar problems across industries when it comes to task completion and execution of strategies/development ideas. I can't tell you how many times I would update our "tracking log" (a basic-ass Excel spreadsheet with project owner, general information, and date to complete task columns) to no avail. Someone would miss a deadline and tasks were constantly added without dropping off any tasks or moving them to the "complete" stage.

Trello is only as great as the work being done to execute on the assigned tasks. I really think it just comes down to getting shit done.

One technique I found very helpful is physically writing down the tasks you want to complete on a little 1x1 sticky note. This helps you stay concise with what you NEED to get done that day/week and keeps you from adding things you know you CAN'T accomplish within a respectable time period. Once you finish that task, you then cross it off. There's something uber satisfying about crossing things off with a pen.

I think the main goal is to set realistic expectations and hold yourself accountable for those tasks. Try not to overburden and add tasks to the never ending list. It just gets daunting and stifles your creativity or willingness to execute.

Take a look at Clubhouse, I think it might be right in the right range for you: https://clubhouse.io/

I think the right 'process' for each person is more important than the 'tools' etc.

The tools that will suit your needs , you will learn/make/find over time of use.. The process though is the foundation imo.

I have a few habbits that I absolutely know could be improved on, optimised etc, but they make me comfortable, they are my solid automonomous actions, meaning I never need to worry about them.

Autopilot mode kicks in.

That takes time and just noticing what you don't like and removing / changing those things.

Good luck.

PS: Beer helps! o7

> I think the right 'process' for each person is more important than the 'tools' etc.

This can't be overstated. We often get stuck into looking for "the perfect tool" for things, when the tool is rarely the most important thing. The process is king, and any tools should be chosen to support the desired process.

Kinda depends on how large your product / project is. I work as a (mostly) solo dev on very large projects that are typically completed by teams of 5-10 and take 6-12 months to complete (even for a those teams).

* Pivotal Tracker is IMO the best agile PM system.

* I break each project into Epics, then down into discrete Stories, basic agile stuff.

* I only score stories at 1, 2, 3, 5, 8, 13. Anything larger MUST be broken down.

* Any story scored 8 really should be broken down into smaller pieces. Any story scored 13 MUST be broken down.

* I use Harvest to track time against individual stories, and require that any subcontracted developer do the same. This allows me to determine for any given dev, including myself, how much actual time a given point weighting equates to.

It's a lot of work to do this at the outset of a big project and feels very waterfallish. And it's tiring to think so deeply into implementation details. But it's very much worth the effort.

My personal pattern is to whittle the project down in multiple passes. So Pass #1 is just breaking things into Epics. Pass #2 is breaking the Epics into 8 or 13 point stories. Pass #3 is breaking those 8/13 pointers into 1/2/3/5 stories.

I absolutely do not open an IDE until this process is done. It's so tempting to just start writing code. Avoid that temptation. :)

> I absolutely do not open an IDE until this process is done

How do you deal with changing requirements? Or when your understanding of the problem changes midway into the project? I find that one or the other happens frequently. It's nobody's fault (most of the time), just the result of the reality that customers don't always know what they want and are frequently unable to accurately communicate what they want.

Oh that happens all the time, sure. I'm referencing what I do at the start of a project.

Emacs Org Mode is nice for note taking planning and todos, the calendar timestamping features is nice to recognize time spent in various tasks and keep accountable

One of reasons I did my Sciter Notes (https://notes.sciter.com) is to track ideas and progress (see checkmark list button). Idea definition frequently require hyperlinks, images, etc. so todo.txt is not enough in case of UI related stuff.

Also to track customers, their licenses and services.

Sciter Notes is storing data strictly on local drive and so the data is not shared with third parties.

I just have a text based notes file for each project that informally keeps track of everything in a pretty unorganized way.

I'm a big believer of keeping old text around too, so I don't delete things after I finish them because that added context for later usually helps a lot.

I use this to actively juggle 5-6 freelance gigs and a bunch of personal projects. I find it really easy to jump into any of those projects and get up to speed quickly.

In general I keep "busy work" to a minimum. Often times I would rather get into the code and even add pseudo code comments or TODOs instead of kanban boards and other things.

For project planning (pre-single line of code) I just brain dump stuff into a text file and go from there. I once live recorded myself doing this for a project a while back at https://nickjanetakis.com/blog/live-demo-of-planning-a-real-....

I also like that my notes file is local instead of an external service. It lets me jump between that and my code very quickly since I can use my code editor to interact with it.

My process is similar. I use Trello with four lists: Backlog (further out feature ideas, ambitious or less important refactors, edge case bugs), To Do (basically an extension of Backlog for things I plan to work on imminently), In Progress and Done. I also have labels: Feature, Bug, Refactor (user-impacting things like improving performance), Developer (non-user-impacting things like importing infrastructure into Terraform) and Marketing.

One thing that has helped me immensely is using checklists on Trello cards. Unless a task is very simple, I generally make two checklists: one for implementation and one for QA. The act of making an exhaustive QA checklist in particular has helped me figure out edge cases that affect feature development, and going through each and every scenario outlined before releasing has caught a ton of bugs. As a bonus, I get a progress meter on each task.

It's enough structure that I have a good handle on everything, but loose enough that I don't spend much time appeasing my product management process. I'm only coordinating with myself here, so I think adding more tools or processes would just slow me down.

I use dynalist.io (similar to Workflowy but more actively being developed) - I've found that the lists-within-lists patterns maps well to the way I think - if there's more than one layer of subtasks, Trello tends to not map well. I usually keep a 'Today' list that I fill every morning and work through.

I'm planning to try out notion.so though - I have a feeling it might help with the friction that I currently feel when duplicating items from my long term 'how should the product work' structure and the 'currently working on' structure.

My most important insight as a solo dev is that you need to manage your own motivation, and that what is required to do so varies. I've found that I easily procrastinate in the beginning of a new project, when nothing is defined yet and it's mostly research, trying to figure out what is even possible and what is desirable. In later stages it's easy to motivate myself, since I get that dopamine kick every time I tick something off from the todo-list. But in the beginning, there are no small, well-defined tasks, just research and analysis - to my brain, that feels like wandering the desert with no end in sight. So I motivate myself by doing pomodoro technique instead. That way every time I finish a pomodoro (25 mins of focused work). I get that little dopamine kick from that instead. Long story short, it's best to track and reward progress, but when that's hard or impossible to do, track and reward effort instead. I use this app on my computer to keep track, but I'm sure there are other good ones: https://apps.apple.com/gb/app/be-focused-pro-focus-timer/id9...

I use Todoist to log work for my company ChipBot.

I have a groups like feature requests and backlog for catch-all tasks. Then for deadlines I use "Mid January" or "End of January" and move tasks into them, based on a rough hour estimate. Story points doesn't matter because I'm not quantifying complexity across a team members. It's just me working on it.

I work on the tasks that have the highest priority, build locally, test them in a QA instance, and then ship them to prod. I usually run smoke tests in prod just to make sure I don't break something.

I used to use GitHub tickets and JIRA, but over time I needed organization that didn't cause a lot of busy work. For myself, Todoist (paid plan) works.

If I need to add members in the future, I'll go back to using GitHub (kanban, labels, milestones). Most likely my marketing team will need a Kanban before I add another developer.

Other notes:

Use tools that get objectives done and don't create micro tasks.

Finally, create tasks during off time like during lunch, while working out, or on a walk break. I generally plan 2-3 days in advance on the exact work I need to get done. Don't over work yourself.

1. Come up with a feature.

2. Code it.

3. Test it.

4. Release it.

Occasionally: Think if there's any process/code problem you keep running into, and spend some time fixing that.

Don't overthink it. Most of the process ideas that exist out there exist to facilitate communication, which is completely irrelevant if you're the only one.

Also, don't create a process for people who don't exist yet. They may never exist, and if they ever do exist, your process will need to accommodate their needs. Having a process already in place creates a "this is how we do things" that creates opposition to accommodating the needs of new members, and puts them in the position of having to change a process they never agreed to and had no part in creating.

Remember, agile isn't a process, it's a set of principles[1]. "Individuals and interactions over processes and tools" means that you find the individuals first, and collaboratively build a process that works for everyone involved.

[1] https://agilemanifesto.org/

It depends on the situation but like some of the commenters here, I use two whiteboards for rapidly putting things together. I have a larger one for drawing out the architecture—relationships, expected behaviors, purpose statements, that sort of thing.

Then, I've got a smaller one that lets me design a rough skeleton for UI (when applicable). If I can wrap my head around how I can expect a user to touch various parts of the project, I can better plan for what data requirements I anticipate needing.

But when it comes down to development, it generally boils down to avid use of GitHub. I have an unhealthy obsession with checkboxes on GitHub issues and pull requests. I used to compile todo.txt files like others, but found that they fell out of date or that I never had any reliable means of tracking what I had previously worked on. If you delete the bullet points, it's hard to find when or why.

So I split features into PRs. One, two, or three thousand lines of changes on average for a small feature here or there. When I need to clean up bugs, I've gotten a bit lazy and will just sneak them into commits on master. Squash and merge lets me point back to the PR that I created and I'll throw a description of all my work into the body of the PR.

GitHub issues lets you know what work needs to be done and when the PR is filed, the issue gets closed (i.e. you put a small "This closes #N" in the body and when the PR is merged, GH takes care of the rest).

It might not be an efficient system but I've tried things like Trello or project boards in the past and I couldn't bring myself to shuffling a deck of a hundred cards every time I touched one small thing. As soon as you increase the distance between your code and your project board, it feels like going through that many more steps just to update everything. It works for some but everyone is different.

A major problem I've seen with Engineers following a TODO-like tasks is that you get lost in the small things and lose focus of the bigger picture.

While they are useful, I also try not to forget things that are vastly outside of the list like regular user testing, talking about it with other fellow engineers (dev testing?), try to make a workable MVP and sell it early, etc.

Need an overarching vision. Absolutement. That's why I like to simply keep track of what I am doing or want to do in a calendar-like way. I never delete things from my logue of completed tasks, I just keep adding new dates and new ideas/finished tasks/want-to-dos at the top. It works well when you have an overarching goal.

Whiteboard - For me, tangible writing helps with creativity and thought processing and a whiteboard saves on paper if it's not going to be a permanent thing (and even if it is, a simple photo of the board for retention).

Google Keep for quick notes on the go with a permanent pinned tabbed in my browser for quick access

Trello for day to day development management but not as detailed as I would in my work, simply as I don't need it to be. Speed is an advantage for solo projects and small teams so adding unneccessary processes reduces that advantage IME.

Specialised comments within Visual Studio to allow me to write comments and easily find them again without disrupting my flow (I believe IntelliJ and other IDE's may have analogous features) https://keyboardp.com/post/40190774577/using-task-list-token...

You can use email as a TODO stack. You take the top item of your inbox and react to it. You react by replying to it, archiving it, or by doing the task(s) described in it. To add a new item simply email it to yourself. Archived items are done. Inbox is the list of items you working trough. Send items is the things you are waiting for.

Perfect for those of us running our own email server :)

Over the years I have compiled a log of project metadata. Nowadays I use it to forecast and plan each project task. The key part is having the task to time forecast for your overall environment (people, company culture, country, …) .

Every project starts with a drilldown of requirements to tasks (just name and description), the more detailed the better. For each task I add a subjective complexity. The mapping of complexity to actual time is based on previous projects metadata.

I try to add a task for each time-consuming effort, documentation, HW procurement, HW shipping, cabling, development, validation, acceptance tests, baby-sitting, billing.

The metadata is a living document, it adds more rows as the project progress.

For tracking the metadata, I use a Google Sheet for each project as a tracking project management. TODO file in steroids. There are two levels, one for the task and another for steps in the tasks.

Each of the rows have more or less following information.

   * id, name and description

   * status

   * owner

   * area

   * initial perceived complexity.

   * final perceived complexity

   * external perceived pressure  

   * dependencies

   * total involved people

   * initial estimated time

   * dev starting time 

   * ending dev time 

   * real development time 

   * testing starting time 

   * test ending time
The tracking is updated daily (last action before going home) or when a new task appears. It doesn’t take much time.

Once the initial per task forecast is done, I have also try to put the high level tasks and its dependencies in a classic Gantt waterfall (using projectlibre). The Gantt gives an initial idea of the time, but it has never been fully accurate, because as project evolves, there are always new and unexpected tasks.

Note that the pressure column in the list above, is one of the principal inputs to forecast, due to Parkinson's law.

The main advantage of tools like this are that you can use them to communicate. When I don't have the need to do that, I don't use them. I try to use tools that will remember this sort of thing on their own.

I keep notes on ideas in a personal wiki (AwkiAwki), and I open up the recent changes page to remember what I was taking notes about. For anything past the planning or brainstorming stages, I just use `ls -t|sed 10q` on my directory full of editor session dumps. I always keep a scratch/memo buffer open in acme so there will be some brief notes, an outline of the behavior I planned to implement, or (more often) I can gather what was going on from which files were open and where the cursor is in those files. For non-code projects, there will at least be some text, so there will be a session dump.

Personally I use the Notes app available on the MacOS / iOS platforms. I organize it with a folder per project. I love it because it is simple, supports checkboxes, formatting, freeform drawings via iPad+Pencil, syncs across all my devices, allows password locking certain notes (though I don't really use this - I use 1Password to hold sensitive info via its Secure Notes feature) and is even available via the iCloud website if needed.

Within that folder I keep one note that acts as the ToDo list / Work Log that contains all the work items plus dates of completion. The rest of the notes are ad hoc and usually contain stuff like "Meeting notes - <subject> - <date>", "Follow ups", "Questions/Clarifications for later", and so on.

As a solo game dev, I've tried a number of various project management tools that I use in my DevOps day job... from Trello to Planner to Jira to Azure DevOps. I like Azure DevOps work items the best, but the reality is that for a solo developer, I've found all of these tools create far too much overhead (so that I spend more time managing the project rather than making actual progress on it).

So for practical use... I tend to write my ToDo list on a whiteboard near my workstation.

When I complete items from the whiteboard, I move them into an Excel spreadsheet where I can add greater detail about the resolution/solution.

When I'm ready to release a version update, I take the notes scribbled into that Excel sheet and turn them into properly formatted update notes.

I use a Google sheet + a todo.txt.

In the Google sheet I log the requests. Depending of the project I add columns with a 1-10 value (For exemple: "value for user", "cost reduction", "traffic increase", etc). I then sort all the requests by a column having a formula where each dimension has a weight related to its importance (= 5xd8 + 2xe8 + 10xf8). That way, I know which request are the most important without "thinking too much".

In the todo.txt, I break down the current tasks in smaller tasks. That way: It helps me understand tasks, I can track what I still have to do, it "structures" my work and it helps me not to forget "little important details" that must be done.

Instead of Trello you can use Github's Projects. It has kanban boards like Trello and it can create progress bars based off of each of your tasks. They also support various automation features based off actions with your branches to move cards around.

I use Restyaboard, an alternative to Trello, that has the same Kanban features, as well as other views such as a to-do list and mind map. I love the visual aspect of the boards and being able to make lists for each topic is nice.

I was shaping such system myself and after some time I understood that global kanban boards are enough, but what is more important is how do I focus (and return to the focused state) during the work.

To focus and return to the focus better, I'm using a mix of:

- project microtasking with kanban board (automatically handled using scripts/app) and TODO/FIXME comments

- lazygit utility

- global todo kanban board (think Trello, GitHub Projects etc.)

I was looking for a system that will maximize my productivity during few hours per day when I work for myself. I discussed this system before on HN: https://news.ycombinator.com/item?id=20780939

I organize todos in the note-taking tool I'm building, http://remnote.io/.

I have a main "unsorted todos" inbox that I can quickly add to from anywhere (I just hit CTRL + ALT + E). I then go through this list and organize it by moving the ideas to specific features that I'm building / designing. My high-level areas of focus are already set up, so this organization process is pretty fast.

I like keeping my todo list with the rest of my notes, because I can write long brainstorming docs paired with my todos. Additionally, I can make linked references to the todos from elsewhere in my notes.

Also using Trello and especially their checklists. Each 'iteration' has a checklist and as I'm done I check it off. I guess they are like issues in an issue tracker with less fuss.

Since I have all the 'iteration' there I also have a 'Future' iteration. As I'm approaching some self-imposed deadline I remove/add tasks from the current iteration to Future.

If I didn't do anything in quite some time I have the tasks right there waiting for me and I can pick one.

This mode of work for solo projects is quite good imho. Used it for openbeans.org / coolbeans.xyz, for mastodon.ro and for another project which doesn't have a website anymore (YaMeter).

There's already extensive commentary on the organizing side of planning, but for my personal projects, much of my planning is thinking through the problem and recording my thoughts.

I've found Inkdrop[1] is quite good for that; there are a ton of them out there, but it has nice tagging and the ability to set a Status so you can have a set of notes "in progress."

I've tried a few mind-mapping tools, and can't recommend them, unfortunately. And none of these tools really talk to each other, which is disappointing.

[1]: https://inkdrop.app/

The most important tools I've found is simply setting milestones and deadlines. The software almost never mattered - the mentality of setting myself accountable to deadlines was so much more important. When fleshing out smaller tasks for milestones, I've used Evernote, Clear, Notion, Trello, Google Docs, etc. All of those are great, but I never really cared about the % progress - only that I was going to hit the deadline and working as hard as possible to reach it. The tools end up being a way for me to not forget little things I decide to shaft in order to reach a ship date.

Todoist. I organize my projects in separate projects or sections in projects, depending if they have big or smaller scope.

I also import my Github repo's PRs, so I can plan everything in a single place.

Every week I plan the next one and I review my planned day while I commute.

I split tasks in several subtasks and I keep track of my progress looking at how short is the subtasks list per each task.

I also usually take few minutes a day to refine tasks to see if I missed some subtask or I can improve the description.

My workflow is heavily inspired in Agile/Kanban. My progress is measured overall with Todoist Karma.

This could work for more devs, as you can share and assign tasks.

With KeyDB I keep my todo list in my head. Once in a while I’ll go scour github issues or feature requests. So far no other tools have been necessary.

I think when things are small adding too much tooling or process is counterproductive.

I tend to use a simple txt, it is always open on my editor, and I put there the TODO, or any bug I found. If I have to persist this information I tend to use github issues and use a PR flows, but in general a txt is more than fine. I've been working like that for 6 months in a row, alone. And I have to tell you when I'm tired of backend programming I move to the frontend , doing some visual adjustments, just for fun and mental health, then I switch back to the backend and so on, also this cycles are switched by testing, design, programming, flow design etc...

After Jira (on demand), Asana, GoPlan App (which was quite good a long time), Trello, OTRS, RedMine and several others, i landed now, hopefully finally(?), at https://www.clubhouse.io

I like Jira at work if its self hosted, but on demand its that damn slow, its more or less unusable (every page load 10-20 sec. etc.).

Clubhouse is especially good since its free for very small teams while not limiting the number of projects/workspaces. And its mainly an SPA, so it feels really quick & responsive.

I just used (and still use) org-mode to track todos & projects, as well as keep time that was spent on each task.

I tried not to over complicate my task keeping, because I've always been more worried about getting the tasks done, than trying to track progress.

Anything that was in planning/needs more info state got a WAIT instead of TODO, with a note on what was needed. And I'd review my list every morning before deciding on what I needed to work on, or if I needed to start pushing for information on other tasks.

I still do all this btw, I'm just not solo anymore.

With trello, within a single card you can click "add checklist" on the right-hand side. Then add all your tasks, and check them off one by one - it shows you a progress bar on the main board.

I have a single TODO list of cards and i use the checklist within a TODO if its a large task that needs to be broken down.

I also arrange all of my links to libraries i've found online by dragging them directly onto trello or use the bookmarklet. I have about 30 boards on different topics, some with ideas, some with links all subdivided horizontally by topic.

I started using plain to do lists in org-mode, then tried using GTD (Getting Things Done), but ultimately ended up building a webapp which combines elements of both and which I can access from all my devices:


It's pretty basic, but it's the right balance for me. Feel free to try it out.

P.S. I also built it because I wanted to learn ClojureScript, and I can say it's been a very positive experience.

I write down all my ideas in a Trello board, and make sure that they're either easily actionable (can be done in a couple of days at worst) or tag them to split them up later.

My columns are Todo, In progress, Done and Backlog. Anything that's not a priority right now goes to the backlog. Every once in a while my Todo column gets empty, so I make a release and take stuff from my backlog.

Any time I have an idea, I instantly write it down and stop thinking about it. This lets me focus on my task at hand.

I really like to brainstorm by putting sticky notes on a wall (my process https://www.pluralsight.com/courses/agile-requirements-proce...), but https://app.storiesonboard.com/ is where I manage it after that.

I've used PivotalTracker in the past, but it's basically what you do with Trello. IMO, if you need to track progress %, your tasks aren't broken down enough.

My process looks like this:

* Ideation Box - informal idea description

* Icebox - Long term value, that a may or may never get to

* Backlog - Short to mid term items that I want to build

* Needs Design - when I've commit to do something, but it needs a mockup

* Ready for Development

* In Progress

* Done

* Staging

* Production

Depending on the project and my whims when I start, I might keep that all in one board or split it into two section (just after backlog).

I like to use a notebook for higher level thinking and Post-It notes for daily to-do lists that I cross off. I then stack them and occasionally throw them out. It's a great motivator to get that dopamine when crossing things off my list. Items I didn't get to are either carried over to the next day or broken down into smaller tasks. I try to either prepare the list for the next day the evening before or first thing in the morning.

Everything starts to sprawl into tree-like hierarchy. I think mindmaps are messy but if you can branch them by file it works fine. Freeplane with nodes that link to other files are best, then from there you can migrate some of that to kanban boards, which are more rigid and ordered. As a side note, that is also the best solution to multiple tabs, if you've ever had a pinned set in chrome. Best just to make them freeplane links.

I use todoist, with projects per major component to keep things organized, to capture ideas for feature development. Todoist supports group collaboration and has commenting per item.

I use GitHub/Gitlab's issue tracking for bugs. It's nice to have a stable URL to reference in code to help prevent the same bug from recurring.

I keep a Google doc as a diary with daily entries to track what I got done each day, and what I want to get done tomorrow.

I’m using https://linear.app. It plans “cycles” for you based on how much you accomplish.

What’s the secret to get past the Typeform and actually try this? Or should I seek out an invite link from a peer

Get yourself a large, high quality whiteboard. Working with it is great for visualizing things and it never gets too messy because you’re ultimately space limited. Every now and then you go through the upkeep - this way it doesn’t ever go stale. And it’s always right in front of you. No files to open.

I use a combination of the white board + Keep for more detailed stuff + per project TODO under version control.

I use a todo list, sometimes paper, sometimes orgmode [1] or taskbook, or some web version [2]. But I find it really distracting to use a kanban board for personal stuff, maybe because I don’t have so many stuff going on at the same time.

[1]: https://orgmode.org

[2]: https://pomoday.app

ZenHub has a free trial


GitHub w/ Slack is enough for me

Best of Luck ;)

I use Gitlab issue boards (they’re much like the github kanban boards, but for gitlab users) to track minor tech features (on a commit level) for each of my project that can be measured with code.

For everything else (like planning db models, endpoints, roadmaps, etc) I use Notion (switched from evernote) and I love it. The templates really help.

I use kanbanflow because 1 it's free 2. it works from mobile so I can note things down on the move (https://kanbanflow.com/mobile-app) 3. It's simple and a slight step above the todo.txt approach (my previous workflow)

I use Bugzilla to track both bugs and other wrok-to-be-done. When I close an issue in BZ, I also add a reference to which version control check-in addressed it.

Using Bugzilla as a general issue tracker makes it easier to prioritize both bug fixing and feature changes, as well as keeping a database of what work I've done, and when.

I use the principles outlined in Shape Up (https://basecamp.com/shapeup) and organize my project in Minimal (https://minimal.app).

The key is combining simplicity and focus.

Solo dev with an intermediate experience here!

I create a GitHub project (now that private repos and projects are free) with more or less the same type of boards like yours. With that triaged, I reference each card as an issue to my repo and work on milestones -- which shows the progress % :).

I used Asana before this, but I like GitHub now.

Loving Clubhouse. The cards in your kanban board can move columns automatically if you sync with your GitHub org – so for example, a card will automatically move to the completed column when you merge to master. Clubhouse gives you complete control of the granularity of the webhooks which is really nice.

I have make and CMake templates for C and MSVC C++ projects, respectively, and I create a Sublime Text template with a todo.txt for each project. I tend to only use VS for debugging, as it's easier to link SDL, Lua and other libraries through a CMake build than the Visual Studio UI.

I used to use XMind, which is some mindmapping software. But it got a bit unwieldily.

Nowadays a todo.txt tends to suffice.

I use "Note" for Android. I have a list for ideas as well as one per project. I don't really need anything more than that. I'm not a fan of Agile and don't think a framework is required for a team that small. Focus on outcomes and not process.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact