![\"CindyLonemanCoder\"](\"https:\/\/cindypotvin.com\/wp-content\/uploads\/2015\/03\/CindyLonemanCoder.jpg\")
<\/p>\n
So, to prepare for my coding journey, I’ll be going through the following steps to maximize my chance of technical success and waste as little time as possible:<\/p>\n
- \n
- Defining the quest:<\/strong> To go somewhere meaningful, you need to have a clear idea of where you’re going so you’re not wandering aimlessly around. In my case, I already defined my quest: I want to build event scheduling software for conferences<\/a>.<\/li>\n
- Painting a pretty picture:<\/strong> To make your path even clearer, you should mock the important parts of your product so you have something to work from. In you head, everything may fit correctly, but reality has a way of foiling expectations. It’s better to find out from a mockup that your concept is impossible than from a few weeks of coding the UI. You can check out the mockup I did for my own product in the post defining my project<\/a>.<\/li>\n
- Testing the moving parts:<\/strong> You should prototypes the parts that you are not sure about and that are vital to your product so you don’t fall in the Pits of Technical Risk just when you were starting to get somewhere. This may be an unnecessary step if you’re already familiar with every technology and pattern you’re planning on using, but for most projects there is a least one or two thing really worth testing. That way, you can start coding at full speed later without having to worry too much about what’s lurking in the corner. I already wrote about the prototypes I planned in my previous blog post<\/a>.<\/li>\n
- Writing a map:<\/strong> You need to map out what is needed to get your product to a usable state. Each task or feature should be kept small so you can complete it fast and keep the momentum going, especially if you’re working on this in your spare time like me. I’ll start planning my tasks when I’m done prototyping since I’ll have a better idea what needs to be done and how long it will probably take.<\/li>\n<\/ul>\n
When everything is ready, I’ll finally be able to jump into it and build the real thing. For now, I’ll be starting with the following guidelines. Since I have not reached this part of the project yet, I’ll have to make sure this evolves as I learn new things.<\/p>\n
- \n
- Crank out the code:<\/strong> This is where you put your nose to the grindstone and do the real work of writing the code for a small feature on your map. Since all the parts in the map should be important for the final product, you should work on the task that’s best suited to your current energy level and motivation to optimize your efforts.\n<\/li>\n
- \nJournal your journey:<\/strong> I don’t believe in zero documentation. Having just enough documentation so you can remember why you did something can be very useful, especially for a project that’s worked on in small units of spare time stretched out over a long period. Since you’re working alone, you won’t have a team to help you remember, so anything you don’t remember and didn’t document is be lost forever. It doesn’t need to be long and boring: for my project, the documentation will mostly be blog posts like this one.<\/li>\n
- Focusing on workmanship:<\/strong> Each feature should be complete in itself and work without breaking anything else. What you’ll be making here is only the start, so you need to make sure you reach the end of the road with good, maintainable code. It’s better to have a few features that works well and that are properly documented than a few half-baked things that will break the first time a user tries something a bit different than what you planned.<\/li>\n<\/ul>\n
After all of this is done, I’ll hopefully be able to ride into the sunset with a good software product that’s in a usable state. This will only be the beginning of the rest of the life of the software: the quest for users will start and the software will need to be maintained, which is a completely different game. Sign up to my newsletter to stay tuned until then, there are still a lot of steps to complete!
- \nJournal your journey:<\/strong> I don’t believe in zero documentation. Having just enough documentation so you can remember why you did something can be very useful, especially for a project that’s worked on in small units of spare time stretched out over a long period. Since you’re working alone, you won’t have a team to help you remember, so anything you don’t remember and didn’t document is be lost forever. It doesn’t need to be long and boring: for my project, the documentation will mostly be blog posts like this one.<\/li>\n
- Painting a pretty picture:<\/strong> To make your path even clearer, you should mock the important parts of your product so you have something to work from. In you head, everything may fit correctly, but reality has a way of foiling expectations. It’s better to find out from a mockup that your concept is impossible than from a few weeks of coding the UI. You can check out the mockup I did for my own product in the post defining my project<\/a>.<\/li>\n