What's your personal programming workflow? How do you plan/plot/track?

If you have a programming idea you want to hash out, what's your general workflow to go about it?


I have a problem with organization (or lack thereof), compounded by obsessive attention to detail + raging perfectionism. I quickly get lost in the details and lateral-movements. I feel I need some type of project-management software or system, whether dedicated software or a general workflow for planning/plotting/tracking progress.

In the past, I've haphazardly stuck bulletpoints up in the headers of whatever file I'm working on. This usually leads to an overgrown, disorganized mess of miscellaneous ideas, features, thoughts, etc.

So I'm looking for any workflows/methods/suggestions/ideas/software to assist in planning, plotting, and tracking projects, whether some personalized workflow done via Notepads, to dedicated project-management software suggestions.

What are you trying to accomplish with the project management software? Project management software for one person working on a single project is likely going to be total overkill. I'd instead focus on something with lower overhead like https://trello.com/ or even a basic TODO app, if you must include a separate app.

However, it sounds like most of the issues you highlighted could be solved simply by keeping a README file in the root of your project directory where you can keep your ideas, future features, notes, and other TODO-type items in a single location.

For basic concepts, I prefer to leave a TODO comment inline in the code. Configure your text editor or IDE to highlight these lines for you so you can quickly find them. Bigger ideas need to go in the README.

If you're talking about a personal project on your free time I'd just use pencil and paper or a whiteboard. But it depends on if its for a client or work, but for home just let that shit flow all over a piece of paper.

Getting caught up in the details is something you just gotta stop doing. Read about product MVP(minimal viable product) get things working in general use that to find value and then you can re-iterate.

A few options come to mind:
- A document object -- Word, OneNote, Excel
- A feature/bug tracking application -- Bugzilla, FogBugz
- A workflow tracking application -- Trello, ToDoist
- Some hybrid options -- CodePlex (i.e. code, docs, change logs, etc.), Jira (and its various addons)

Any of these could suffice for a brain dump of ideas to revisit in the future, and keep them out of your source and source control. Some of your decision could be weighed by the amount of visibility that you want external people to have.

Knowing that you are somebody who gets lost on tangents, why on earth would you ask us to supply you with more tools to be distracted by?

Your goal should be reducing the things you do to achieve the desired result, not increasing them.

Using all of these tools will most likely, as hofan41 mentioned, lead to further distractions. I don't place a lot of emphasis on tools for planning in an individual work environment. If I were working on a team, that would be a different story. If you're having the problems you're describing, I would examine your method of organizing and the process you're taking to accomplish your tasks, rather than the tools you're using.

The key, at least for me, is recognizing that how you organize the overall high-level project should be a separate step/process from how you organize the individual low-level tasks your project is comprised of. Figure out what you think your application is going to look like structurally. What pieces do you need? Worry about components in terms of what interfaces they provide and consume and what you expect their behavior to be, not how these components will be realized. If you're a visual person, feel free to use a tool like Visio to make some UML diagrams or other types of modeling, but remember to use these as visual references, not exact descriptors of your project. If this is your own individual project, it would probably be a good idea if none of this is set in stone, but the idea here is to have your own plan of attack. This is the 'What am I going to do?' planning phase.

When you're ready to start writing code, it's time to change your perspective a little. If I'm the only one working with a particular task, I don't have a lot to really worry about 'planning'. I sit down at the onset and figure out my requirements, define my interfaces, stub out my classes and immediately translate the requirements into unit tests. Once I have my classes and interfaces stubbed out and my unit tests written, there is no planning left...I just write code until all the tests pass and refactor. The unit tests are nice because the provide you with a measure of progress/a measure of doneness. Once you've gotten the tests to pass (assuming your unit tests are sufficient, of course), you know you don't need to worry about any more details with that part of the problem and can move on to the next problem. This is the 'How am I going to do it?' planning phase. Maybe you'll run into a problem here and go back to your 'high-level plan' to re-work it, and that's definitely a good thing to be willing to do. Realistically, you'll probably iterate back and forth between your two planning phases several times.

Think about how you would design something other than code. If a manufacturing company came to you and asked you to design a machine that assembles golf clubs, how would you solve that problem? Hopefully, you wouldn't sit there worrying about every detail regarding how you'll press the logo onto the handle before you've even figured out when you're even going to be putting the logo on the handle and how the pieces are going to get to you. Hopefully you'll reason that at some point you're going to need an assembled golf club. On a high level, what do you need for a golf club? You probably need a grip, a shaft, and a clubhead, so let's plan on having a unit which receives those parts and puts them together into a club. Then let's figure out what pieces we need to make those pieces. Once we've figured that out, what do we do once we have the golf club? We're going to want the to put our logo onto the grip and package it, so we'll have units that do that, too. After you've figured out what units you have, then you can take any individual unit and start figuring out how it will work.

The first iteration of the first part of the process (planning things out on a high level) can often be the most difficult part, and sometimes you're ambitious and ready to go and you just want to start writing code. But you have to find a way to break your large problems down into smaller problems so that you can focus on them properly. If it's a small enough problem, there isn't a lot to get distracted by. There are lots of methodologies out there which focus on iterating between planning and programming, such as XP and TDD. The specific details of how you do these things aren't really important, so I'm not going to guide you towards any particular one (and I could be stoned for saying this, but I feel following any one methodology verbatim rather than taking the elements that work best for you is a bit silly and zealous anyways). What is important is that you break your problems down into smaller ones so that you can stay focused.

hofan41 said:

Knowing that you are somebody who gets lost on tangents, why on earth would you ask us to supply you with more tools to be distracted by?

Click to expand...

Took the words straight out of my mouth. When/if the OP has a project of some demonstrable magnitude, I think we can start to talk about organizational methods, but not sooner.

I start modeling some piece of core data that I want to hold with suitable structs or conses whatever is suitable. Then I write code to fill it with the real data that is floating around. Then I start doing something with that data that I will probably need later.

The project will never not compile for more than 2 minutes and not run for more than 1 hour.