|
First, make sure each task you're doing fits into a conceptually coherent whole. [0] This saves you time and effort learning that it isn't from the customer feedback. This also creates a motivational point beyond "I need this to make monies", since now building the software means you get to see an abstract philosophy come alive. Second, design a schedule for yourself that both lets you take out and put away the project. If you aren't hugely inclined to solve programming puzzles that are created by other people's code, it's understandable; the trick is in making it not be the number one priority(because a boring task like this is no longer the fun learning stage of coding), but rather to make it one of many chores on your list. You have a household; there is always something to maintain in it, whether it's dry shoe leather, mildew on the walls, a load of laundry. Allocate 10 minutes each hour to that stuff, then return to the coding with the momentum from that. Huge blocks of screen time never helped anyone. (And yes, overall health matters. Getting more sleep, exercise, correcting a nutritional deficiency, can all be huge for motivation.) During the coding, aim to finish it badly(placeholder level) and then go back and fix it in steps. These tasks get worse when you have to juggle a whole pile of new abstractions all at once: skip to a preset result and then work backwards from that into something that is configurable. Good code doesn't come out of your forehead fully formed, it takes some iteration. If you don't have an estimate for how long anything takes, that's also a demotivator. You can calibrate one by finding a similar project, getting its start-to-release dates, and working backwards to get milestone dates. Don't worry about time per task, worry about the overall product coming into shape. Placeholders as milestone goals can help hugely in getting you to dig into the design and make it its best. [0] http://ludamix.com/dive/ |