[1]: https://orgmode.org
[2]: https://pomoday.app
101–110 of 190 posts
[1]: https://orgmode.org
[2]: https://pomoday.app
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 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 `-`
Earlier quoted context omitted.
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 ?
All of that on the free plan. Gitlab is really THE tool to rule them all!
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..…
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.