[HN Gopher] Ask HN: How do you organize work as a solo developer?
___________________________________________________________________
Ask HN: How do you organize work as a solo developer?
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?
Author : lukev
Score : 16 points
Date : 2024-09-07 14:02 UTC (8 hours ago)
| jeanturgeon wrote:
| 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.
| kingkongjaffa wrote:
| > 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...
| achempion wrote:
| The work organizes itself. I only do what is worth doing right
| now.
| kazcaptain wrote:
| Exactly my approach after years of trying various things.
| Midwit meme applies: just do-complexity-just do.
| kesor wrote:
| 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.
| sova wrote:
| 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
| sova wrote:
| 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.
| leros wrote:
| 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.
| davidclark22 wrote:
| 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.
| newaccount74 wrote:
| 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.
| jncfhnb wrote:
| Sublime markdown file with monthly goals, immediate priorities,
| and stream of consciousness notes
| winrid wrote:
| 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.
| delduca wrote:
| Bear (markdown editor) only.
|
| I dislike bureaucracy wich many companies adopt.
| bravetraveler wrote:
| 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
| graypegg wrote:
| 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!
| quectophoton wrote:
| 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.)
| dtx1 wrote:
| 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.
| cmgbhm wrote:
| 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.
___________________________________________________________________
(page generated 2024-09-07 23:02 UTC)