becoming burnt out
i find myself starting a new project with tons of ideas and motivation. as time moves forward i become burnt out and less motivated. then i stop working on the project yet it is not even close to finished. how do you (or how would you) combat this?
I do the same and I'm afraid I've yet to find a solution besides forcing yourself to keep going, but I don't want to do that. Typically I just work on something else until I feel like going back to the old project.
Well, results! Sometimes, I make sloppy code just to get to the result. Sounds really bad... but it's not usually what I publish.
| then i stop working on the project |
I have exactly the same problem, stoping a project for more than one day leads to less and less interest or even no interest at all, the solution that works for me is to try to implement something new and unknown instead of known into the project, something that was not intended in the first place.
trying to implement something new and unknown usualy leads me to browse google to learn about that new stuff and then trying to implement it into my app.
that way I don't ahve to blindly look into the code all the time and think what to do next, I browse the net, see what's new, no hurry!, then go to msdn or whatever website and read new stuff, then switch back to code and simply do it. when I get bored with code or stuck, I switch back to browser and repeat the process.
the whole process doesn't take a lot of time and it feeds me with as you say new ideas and motivation.
maybe it sounds silly but it works for me..
| Sometimes, I make sloppy code just to get to the result. |
most of the time that is the root of the problem. when you write sloppy code to try to get to the solution as fast as possible, it can become unreadable and when that happens and you want to improve on it later or add things its almost impossible unless you rewrite all of it and most of the time i don't want to rewrite it. is that just me?
I always write the sloppy code first to make sure I can actually get the result in the first place, then I scrap it and write the code properly because I know how best to do it. If you try to write it properly first it's gonna be a lot of staring at the screen and thinking hard on what you even need to write.
^ +1
I never expect my first attempt to work completely. Once it compiles and runs, I can worry about refining it.
I never expect my first attempt to work completely. Once it compiles and runs, I can worry about refining it.
I can't say this will work for everyone but it worked to keep me motivated and going in developing a game 66 days consecutively. I worked on a project in UDK (coding with UnrealScript) and through simply writing down a list of accomplishments I made each day, I stayed motivated to keep working on the project for such a long time. Even though I did not come close to completing the game as I designed in its GDD, just having something to look at to see my progress since starting made all the difference in the world to me.
I've tried writing a basically-working version instead of getting it right the first time and it didn't work out for me. Usually my perfectionist tendencies take over, or the prototype is bugged, or it works but refactoring introduces new bugs which take longer to fix than if I had just written it neatly the first time around.
What I'm starting to do now is to write isolated components and write a simple program solely for that component, much like a unit test. Hopefully when each component is working I can put them together like Lego. You still have to refactor components if, say, the interfaces of two components turn out to not fit very well (e.g. say you're writing an emulator and the interface for your emulated GPU turns out to not support the functionality you want when you start writing the CPU core), but that's easier. [edit] Also it's more difficult when you have components that should be separate but still rely on one another. For example, going back to the emulator example, it would be a good idea to separate the emulated GPU from the rendering code, but you would have to have your renderer finished in order to test the GPU and see the results.
What I'm starting to do now is to write isolated components and write a simple program solely for that component, much like a unit test. Hopefully when each component is working I can put them together like Lego. You still have to refactor components if, say, the interfaces of two components turn out to not fit very well (e.g. say you're writing an emulator and the interface for your emulated GPU turns out to not support the functionality you want when you start writing the CPU core), but that's easier. [edit] Also it's more difficult when you have components that should be separate but still rely on one another. For example, going back to the emulator example, it would be a good idea to separate the emulated GPU from the rendering code, but you would have to have your renderer finished in order to test the GPU and see the results.
Last edited on
It really depends for me as well... but that's generally my first step. I do have a few projects I've left on the backburner but I feel that it's mostly due to time constraints now a days...
EDIT: Also, I suppose I should mention that I started programming at a really young age. As I got older, my patience grew and I noticed I was able to stick it out in some projects. Although, now that I'm living on my own and working all the time, patience is thinning out. Damn you real world!
EDIT: Also, I suppose I should mention that I started programming at a really young age. As I got older, my patience grew and I noticed I was able to stick it out in some projects. Although, now that I'm living on my own and working all the time, patience is thinning out. Damn you real world!
Last edited on
I'm working on a php project and a c++ project at the same time. When i get frustrated or bored with one i just switch over to the other.
Another good option is to find some good friends to work on it with you. Even if its not coding, but screen designs or art or something else to do with your project, the fact that you aren't the only person working on it somehow seems to make you want to keep working.
I tend to start off with sloppyish code, too, though I normally get down with a piece of paper first and work out where the new feature would fit nicely. That way, I can just fix up the feature itself - its often too much effort to have to refactor everything because you later realize that you have problems with where you put it. Of course, that doesn't stop the problems, but it helps to negate some.
I tend to start off with sloppyish code, too, though I normally get down with a piece of paper first and work out where the new feature would fit nicely. That way, I can just fix up the feature itself - its often too much effort to have to refactor everything because you later realize that you have problems with where you put it. Of course, that doesn't stop the problems, but it helps to negate some.
Topic archived. No new replies allowed.