| It depends on the situation but like some of the commenters here, I use two whiteboards for rapidly putting things together. I have a larger one for drawing out the architecture—relationships, expected behaviors, purpose statements, that sort of thing. Then, I've got a smaller one that lets me design a rough skeleton for UI (when applicable). If I can wrap my head around how I can expect a user to touch various parts of the project, I can better plan for what data requirements I anticipate needing. But when it comes down to development, it generally boils down to avid use of GitHub. I have an unhealthy obsession with checkboxes on GitHub issues and pull requests. I used to compile todo.txt files like others, but found that they fell out of date or that I never had any reliable means of tracking what I had previously worked on. If you delete the bullet points, it's hard to find when or why. So I split features into PRs. One, two, or three thousand lines of changes on average for a small feature here or there. When I need to clean up bugs, I've gotten a bit lazy and will just sneak them into commits on master. Squash and merge lets me point back to the PR that I created and I'll throw a description of all my work into the body of the PR. GitHub issues lets you know what work needs to be done and when the PR is filed, the issue gets closed (i.e. you put a small "This closes #N" in the body and when the PR is merged, GH takes care of the rest). It might not be an efficient system but I've tried things like Trello or project boards in the past and I couldn't bring myself to shuffling a deck of a hundred cards every time I touched one small thing. As soon as you increase the distance between your code and your project board, it feels like going through that many more steps just to update everything. It works for some but everyone is different. |