Ask HN: How do you organize work as a solo developer? | Hacker News Reader

Ask HN: How do you organize work as a solo developer?

61 pointslukev42 comments

I'm working on a large-ish project that is currently just me.

I find myself in a strange middle ground. Using standard software development practices (issues, backlogs, kanbans) definitely feels like overkill, way too much ceremony and a waste of time.

On the other hand, my overall velocity has definitely suffered due to disorganization and some churn. It's too easy to move back and forth between different objectives, spend too much time polishing, or to change my mind about priorities.

On the third hand, that kind of agility and flexibility is what makes working on a personal project fun in the first place, and the fact that I can always pick up what I find interesting on a given day.

Currently just using a single text file with checklists for features, tasks, plans, and ideas. But it still feels like I'm suffering from lack of planning and organization.

Any advice for wrangling this?

View on HN

I run a one-person SaaS company and have been using Trello as a simple planning/tracking tool for my work. For simple tasks, each card is just a title. For more complex ones, I add some notes in the description. My board has just 3 columns: Backlog, In flight, and Done. I spent an hour or so getting it all set up a couple years ago (mostly creating all of the cards for the backlog) and usually spend less than 10-15 minutes a week on the board. As customers submit new feature requests or I find bugs, I add a card and drag it to it's appropriate priority spot in the backlog. Besides that, I review the board every 1-2 weeks to decide if the priority of any items has changed. I try to keep it clean, and quickly archive/delete cards if I decide that I'll never work on them. This gives me a lightweight way to keep things organized without feeling like overkill.

What kind of notes do you take on the “done” column cards? I try to describe the “as built” as well as discovery process for my future self. It’s always valuable in the moment (“oh jeez, what have I done”) and sometimes down the road when/if touching the code again (“I’m so much smarter now! …oh wait.”).

what's your saas?

Text file seems fine for a smallish project, but not beyond that. It's just too difficult to keep track of various thoughts and references on each case as they move from concept to Production.

Switch to something more capable, like Trello (personally have used many systems and found nothing better than Asana). If you also keep the rest of your chores ("drop off dry cleaning") in there, you'll see benefits extending to the rest of your life and find this less onerous.

Bonus points: if you ever expand past working alone, you won't go insane.

It sounds more like lack of discipline than bad organization.

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

> It sounds more like lack of discipline than bad organization.

This is true of almost everything. People love the idea of a magic solution that solves what they perceive as the problem but the underlying issue (the lack of discipline) remains.

Find a reason to be disciplined and it’s amazing how many tools and systems start to work well.

Here's my experience from the last ~12 years as a full time solo developer:

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.

For solo projects, my code is the project planning. I use a bunch of #TODO or //TODO in different files throughout each project's codebase, that a small Python script picks up and compiles into a single HTML file.

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!

Kanban is good once you have multiple brains looking for idle work. Until then, my recommendation as a driven, solo-starter who has created 3 ~huge projects more-or-less solo, is to rely on a `notes-todo` file where you religiously and often and frequently log the date and time and then write some notes. Append to the TOP of the file so you can see the latest words at the top, and then you scroll down and it's like a historical feed. You can put what you accomplished in the log to start. Eventually you will have design questions, debates, breakthroughs, and even just long treatise on what you want to accomplish. All this is amazing. You need a written record that helps you sort out where you are in the process. Remember, when working it's microscopic zoom mode surgeon style, and when reflecting it's telescope mode from the space station. You need to be kind to yourself moving between the two, and the answer is NOTES

It helps to understand that you're doing multiple jobs. You're a developer, but also a marketer, a product manager, a designer, you run business operations, etc, etc. I've found it very helpful to not do more than one job at a time and to have breaks between switching roles.

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.

> Currently just using a single text file with checklists for features, tasks, plans, and ideas. But it still feels like I'm suffering from lack of planning and organization.

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.

On Scoping Work

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'm a maintainer of a large open-source cyber-security projects XENA. I don't use Jira nor similar software. I leave notes with TODO comments across the codebase, from to time I'd search and see if something should be done from those. I have a single notes.txt where I write anything, I tend to keep it short and prune anything I do not feel confident about anymore. My priorities about the project are ordered in a simple fashion. At first place comes any bugs. Then I work on a singular feature until it's stable then I release it and move on. The way I decide which feature goes in or not is based on the "10 year" rule. Basically I think if this feature would be used in a decade, if so then I'm keen on introducing it. That's pretty much it. if bugs.length > 0 { fixBugs() } else { feautre = new Feature() if feature == good_enough { feature.implement() } }

I may not be suitable to answer this question at present. More than a month ago, I was fired by the company. Then, I entered the exploration stage of independent development. Currently, I am learning SEO and learning to build websites. (I have been doing server-side development for many years before) I found that there are many things to learn every day. In addition to development, I also need to explore needs, promote, interact with users, do data analysis, and continuously optimize products. Now I work day and night, almost 80 hours a week, which is longer than when I worked in a company. Although there is no progress yet, independent development is destined to be the path that suits me.

I use Google keep. I usually follow all the latest trends and best practices even for trivial projects (Just not CI/CD, that might cost money!), but I don't really apply the same idea to project management.

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.

If you’ve got some underlying issue - organization, planning, whatever - you aren’t going to solve it with more tools and process. Keep the single text file as long as you can, because that way at least the cost of your issue is contained in one place and you don’t need to pay even more context switching tax.

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.

For me, the best thing with the best balance is a 5x7 legal pad. Here's why:

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

Same, but I have a clipboard and a stack of printer paper. I usually write the name of the project and the date on top and usually just do some design work, diagrams or interface doodles on it. The when I have a clear direction, I make it digital (typing it out, or drawing it properly) for cleaner follow through and collaboration.

And as others have said, what you want is the process, more than the tools. The act of getting your thoughts and plan out in the open before acting on them.

The medium is less important. The ceremony is more important.

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.

> it still feels like I'm suffering from lack of planning and organization.

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

Is it a goal to ship this project? If so, has it shipped yet? If not, then center on the _minimum_ needed to ship. And focus solely on that.

I run a physical Trello of post it notes running across the bottom of my ultra wide monitor.

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.

Sublime markdown file with monthly goals, immediate priorities, and stream of consciousness notes

This. I also put a priority on things, the format is "- P0: do thing" and it's just checked into git daily with a script.

All of the organization suggestions are great, but maybe an accountability buddy would be helpful as well? (I need one for self managed projects at least) There’s tons of people out there also working on a solo project. Just having someone else be aware of the commitments you make to yourself could be juuust enough pressure to keep things on track in the early stages.

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!

David Allen's Getting Things Done as a Method is still the GOAT of self organization for me. I personally use a hacked together Obsidian Notebook because it was the only tool that was flexible enough for me.

I'm in a similar boat and I"m not doing it full-time. So my time is precious.

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.

The work organizes itself. I only do what is worth doing right now.

Exactly my approach after years of trying various things. Midwit meme applies: just do-complexity-just do.

I've tried Notion Databases. It's great to see history of projects. Notion feels clunky nowadays but ok.

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 try to avoid overcomplicating things as (a) it takes time and effort and (b) I won't stick to it. For a to-do list I use a notepad + pen. If I need a plan, I'll make something in excel then print it off. If I need to track lots of bugs, I'll use <insert your favourite bug tracking software here>.

I just do minimal kanban. If somethings needs to get done create a todo, then either do it or you have a note for what to do later.

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

The trick is to get a breakdown structure that you can see progress from. The GTD, tickets that are appropriately sized, etc. GTD and separating today from your single file everything will help.

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 use obsidian with the boards plugin, it's basically Google docs + Trello.

I don’t. My way of deciding what’s worth doing roght now is to just read through all the sources again at “morning”. It establishes all sorts of contexts and priorities automatically. There is a TODO.txt, but I mostly see it as an unfinished source file.

All of mine are managed like your typical open source project, I'm just the sole contributor. Liberal use of PRs, Issues, branches, etc.

I can't make drawings to save my life, anything I write would go to SCM. Ideally as code... TODO.md is acceptable

"Currently just using a single text file with checklists for features, tasks, plans, and ideas"

This, but I made an app where I convert the checklists into quests using AI.

Care to elaborate?

Took a week to make it. First part of the app is a checklist. Wire the checklist to your favorite LLM, train it on some tabletop adventures, it turns it into a quest. Here's a recent one for writing a pentest report:

    A wave of goblin skirmishers has stormed the perimeter, their tactics cunning and their numbers vast. It is a siege unlike any before, and only by fortifying our defenses can we ensure the survival of this fortress.

    1. The Battle Plan: Executive Summary
    The first step in any siege is to study the enemy. Analyze the goblin warlord's strategy, identifying their strengths and weaknesses. This will serve as the foundation for our own countermeasures.

    2. Siege Weapons: Methodology
    The goblin horde relies on a range of siege weapons, each designed to breach our defenses. Uncover their tactics and understand how these weapons work, and determine what countermeasures are needed.

    3. Breached Defenses: Findings
    Assess the damage inflicted by the goblin siege. Identify the weak points in our defenses that have been exploited and determine the extent of the damage.

    4. Reinforcements: Recommendations
    Formulate a plan to reinforce our defenses, taking into account the goblin's tactics and the damage they have inflicted. Identify the resources needed and prioritize the most critical repairs.

    5. Victory Conditions: Conclusion
    The final stage of the defense is to lay out the conditions for victory. Determine what must be achieved to drive back the goblin horde and ensure the safety of the fortress.

I also have another part of the app that breaks down a block of text into the task list.

one - understand that software is a living organism that morphs and evolves everyday.

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.

Bear (markdown editor) only.

I dislike bureaucracy wich many companies adopt.

Hipster PDA

Reply on news.ycombinator.com