If the person you're working for (i.e. yourself) says that today you should do whatever sounds more fun to do that day, then it's no surprise that when this thing is not fun anymore, it will be paused and put back into the backlog, and velocity will suffer as a result.
If you work strictly only on the fun stuff, that's something you'll have to accept. If you want velocity, you'll have to come to terms with doing unfun stuff from time to time. If you want only fun, you'll have to come to terms with sacrificing velocity in exchange for whatever short-term dopamine hit your brain wants to receive in this particular moment. If something stays fun for a long enough time to deliver, then that's either a nice coincidence, or you somehow found a way to force yourself to have fun even when you dislike something.
Working for others (employer or customers) usually doesn't have this problem because then they would make it easier to prioritize tasks that need to be delivered to bring in some expected value (whether that value is the same as expected, is another thing). Something is wrong and should be fixed, or we need to do this because it's been requested a lot, etc. And the possibility of losing income (or something else, physical or not) tends to give a large boost in discipline.
(EDIT: Added emphasis in some words.)
As I'm working on a lot of projects, the important thing for me is keeping it easy to start/stop working on a project, and make sure that when I have time to make a pass on a project I don't have to also deal with the additional headache of keeping the codebase and my todos in sync.
Not sure if this is really helpful though. Good luck!
1. I use Github issues to track features and bugs that I am working on. It's useful because sometimes I come back to a feature months (or even years) later, and I don't have to start from zero again.
2. I've tried a lot of systems for planning work, but I found nothing that beats pencil and paper. Plans always change anyway, it's good to just spend 5-10 minutes planning your day before you start working.
3. It doesn't matter if you move back and forth, change priorities, etc, as long as you keep making progress. You only find out after the fact which of the features were the ones that really made a difference.
4. At some point I realise that I'm getting close to a release, then I switch into "release mode", I stop working on new features and just fix bugs until the release is done.
In terms of managing development tasks, I use a kanban board in Notion. I'll put on my product manager hat, analyze my product, and define high level requirements for ideas. Then I'll switch to developer mode and work on a single idea until it's complete. I have a completely separate kanban board for marketing work.
I also don't do different roles on the same idea back to back because I have recency bias. So if product manager me comes up with an idea today, I won't even prioritize it until tomorrow.
I use a wiki, with a different page per project, to keep all of this stuff. I have an "overview" wiki page that is a directory to all of the projects and is where I keep my "Top 10 task" list across all projects.
Scoping work is just as vital as work itself. If you are going apple picking you must go to the correct orchard. You cannot go to a forest bereft of apples and start picking what is not there. Nor can you pick all the apples in one day, or maybe if you do you will be so fatigued that you cannot work any more days that week. Scoping work is the ability to "bite off exactly as much as you can chew" and add "buffer time" so that you can successfully complete that delicious morsel. Indeed, the only way to success is to celebrate small victories, and you must now regulate what those are on your own. That means biting off not too much to chew, and overcelebrating what goes right. And finding the most essential meaningful path to your goal via junctures where you work on just enough of the project to accomplish either the: knowledge gain required, the app upgrade required, or the app creation required. Bit of a free-flow ramble for ya, but hope it helps.
I like to do more waterfall than Agile, so I know what I want to build pretty early and often just focus on one subsystem at a time.
I don't do spike solutions or proof of concepts or prototypes, unless someone else wants me to do so, I build to an architecture even if it means I have nothing to show for weeks other than some classes and tests.
I do try to get to a minimal GUI fairly quickly even if some features are missing, since that makes manual testing easier and it's the part Momoa likely to need iteration.
I’m guessing your problem is lack of clarity and direction. You can’t plan if you don’t have an objective. And you can’t pick an objective if you don’t have a target. Do you want people to use this project? Your priority should be to get it into their hands as soon as possible. Then the clarity will come naturally as you see people using the product and understand the gaps.
- pen & paper makes adding and crossing off tasks frictionless
- compact & portable
- the small size limits scope, which gives you a quick & easy-to-read bird's-eye view of what needs to be done
Fill a page with tasks, then STOP and get to work. Each task should take no more than two lines to specify. You may have more tasks to add after filling the page, but that doesn't matter because one page gives you more than enough to get to work. You may only accomplish half of them anyway before you realize some facets of your project will need to shift direction. Once those tasks are complete, tear off the page and repeat.
You don't need a lot of ceremony. But adding some ceremony is making all the difference between feeling unorganized vs. feeling on track.
Work requires planning. You probably already have the tracking work part covered. You should also improve the planning of work, as a ceremony.
Building a system to track work, regardless of the medium where you do it, will pay dividends. You should also write down the system you chose, and from time to time review and improve upon your system.
There are multiple tools you can borrow for your system from the field of project management. Specifically for the planning and the tracking phases.
One example out of many can be WBS.
IF that's really the pain point here, then I doubt the choice of tools is the bottle neck.
I would suggest getting crystal clear on exactly what is important and what you want to build. That could be a mockup in figma , a diagram of the dataflow through your code (or future code) or a written narrative about what you are building and why. A really crisp narrative should clarify your thinking and make it obvious what the next most important thing to do is.
(some of these links are focused on product management rather than software engineering, but the principle is the same).
https://notes.andymatuschak.org/zAf4oNSV9qB38ncSvYEZGAb
https://www.svpg.com/coaching-tools-the-narrative/
https://www.linkedin.com/pulse/beauty-amazons-6-pager-brad-p...
Priority descends from left to right.
When finishing a task, I pick the next one from the left that fits the time/attention/deadline budget I have available.
It works mostly, at the expense of some crumpled up paper.
You’d need to find someone where you’re both interested in what each of you are doing, but commit to not significantly contributing to each other’s thing. Set up a recurring time to fill each other in on progress and next steps, and be each others cheerleader!
For simple, lightweight, fast organisation, I'd recommend maintaining a single file as a todo list.
A file per project. This can be markdown (todo.md) with checkboxes or just a simple todo.txt
This helps you add/edit stuff to the list rather quickly.
This is no answer. Just do things.
I keep it simple in terms of planning and organisation. I use a set of Markdown text files for now since I'm alone and I develop as if I was on a team. I don't cut corners in setting up projects, repos, and code quality.
I'm afraid of bogging myself down and slow my development speed but at the same time there's going to be a point where another person will join me.
You're probably doing just fine. Just be on the look out for not putting more planning before its time.
Your todo list is your backlog, no need for sprints or any of that overhead, but it is nice to keep a list of your todos and their state and context in case you come back to it a couple of weeks later or so
Doing what feels fun is always going to create a path where what you want to do will be different than the annoying thing you need to do.
I can't make drawings to save my life, anything I write would go to SCM. Ideally as code... TODO.md is acceptable
This, but I made an app where I convert the checklists into quests using AI.
two - use a simple todo list. it should not be prioritized. just like when you're writing - ideas come and get refined. your todo-list, will be that - sometimes you will add something, do it, and cross it off. other times, you will simply mark the todo item, as not necessary as you work on your stuff.
I dislike bureaucracy wich many companies adopt.