Do you make a work breakdown structure before programming?<p>Something like this<p><pre><code> - [ ] Project A
- [ ] Feature AA
- [ ] Component AAA
- [ ] Functionality AAAA Allows users to do something by doing something
- [ ] Functionality AAAB Allows users to do something by doing something
- [ ] Component AAB
- [ ] Feature AB
- [ ] Component ABA
- [ ] Component ABB
- [ ] Component ABC
</code></pre>
This is just dummy data to give an idea<p>Do you use markdown or do you use dedicated software?
JIRA because one has to at $JOB.<p>Personally I have the hardest time with breaking down in the sense of having a good estimate. Breaking down in terms of screens/pages works super well, backend vs frontend tasks. But more than that I have a hard time. The details I mean.<p>Ideally I would prototype, throw away and then do it properly. I'm very optimistic and create only 3 or 4 tasks, in the end its always 12 because of details that I missed.
I make a simple flat todo list if I'm not following any particular formal methodology.<p>Productivity porn is fun but not quite fun enough that I want to deal with more dedicated tools.<p>Generally I'll use Google keep, but I might also use a markdown file right in the repo, or sometimes, I will actually use my tablet and stylus in a Keep note, in an attempt to replicate some of the mental benefits of paper without going to quite that much effort and using the real thing.<p>Semi-real example from personal a project idea:<p>* Show nodes on map layers<p>* Click node to get inspector window<p>* API to create map layers<p>* API must have permission system<p>* Inspector window allows sending chat messages to node<p>* Telemetry data<p>* Persistence and history is handled by backend<p>* API let's host query history<p>"It's called a "Work Breakdown Structure" because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it."<p><a href="https://spacecraft.ssl.umd.edu/akins_laws.html" rel="nofollow">https://spacecraft.ssl.umd.edu/akins_laws.html</a>
Yeah, exactly that. Workflowy is perfect for this. Use my referral code to get 250 free items: <a href="https://workflowy.com/invite/fc6cd0b.lnx" rel="nofollow">https://workflowy.com/invite/fc6cd0b.lnx</a><p>We also do syncs and performance reviews where we reflect on work done in the past X weeks/months. So this kind of format is very useful because you can also see effort and frustration around cettain tasks.<p>I break it down further to sprints/weeks, days, which items are to be resolved on what days. Normally I try to plan for everything to be done by Wednesday, then it tends to expand into Friday lol.<p>Sometimes a list of tests that should pass as well to consider this item fixed.
WBS works great if you are building structures.<p>WBS fails hard if you’re trying to achieve an outcome.<p>For most engineering activities, I’ve found developing a knowledge point plan is a better mapping to the work being done.
I write a hierarchical structured task list (very similar to op) with a neovim plugin I wrote (<a href="https://github.com/gsuuon/note.nvim">https://github.com/gsuuon/note.nvim</a>). Sometimes I'll write these items as commit messages, make the changes and check them off as I commit. I mark the current task so that if I get interrupted I can recontextualize fairly quickly.
You should know what you're trying to do before you start programming, yes. (Unless you're exploring the options.) That could just be a task list, if it's a simple, well-known (to you) problem. If not, then you want more. You want a design, maybe even an architecture.<p>Don't code before thinking and planning. The bigger the program, the more time and detail in the thinking and planning before you start coding.