Keeping spirits up when working on a project
Pages: 12
I've been working on a cool hobby-project for a couple of months now, and so far the results have been very good, but the last week or so I've had to implement stuff that I wasn't familiar with, and its like I've hit a brick wall. Nothing about it seems to work, and nothing I throw at it seems to make even the slightest progress, and every time it does it just leads to something else not working. Does anyone have any tips on how to keep going through stuff like this? Right now I just feel like giving it all up, but I know it would be awesome if I could just push through somehow.
Fafner
Fafner
What works for me is first writing whatever crappy code actually works, and then when it works (or almost works) and I understand how it works, I scrap it and rewrite it with a much better design given my new knowledge of what I can and cannot do and how to do it.
I also recommend what Mats recommends below ;)
I also recommend what Mats recommends below ;)
Last edited on
I was going to ask a similar question. I think though when all work seems to be in vain, that is when important breakthroughs take place. Keep hacking!
Sometimes you hit a point where extensive knowledge and understanding of it, that you don't have, is required to continue on a project and it can be frustrating because it can slow you down a lot.
It's temping to treat this kind of situation with a little bit of denial and start looking for easy quick solutions or attempt to somehow push through it without knowing what you are doing. This can lead to a series of failed attempts and demoralization. Sometimes you just have to put your project on hold for a while and do a lot of reading and thinking.
Also, people here are usually more than willing to help people out.
It's temping to treat this kind of situation with a little bit of denial and start looking for easy quick solutions or attempt to somehow push through it without knowing what you are doing. This can lead to a series of failed attempts and demoralization. Sometimes you just have to put your project on hold for a while and do a lot of reading and thinking.
Also, people here are usually more than willing to help people out.
Last edited on
@htirwin: 99% of my projects are on hold for that reason, except that once I gained the knowledge of how to do it I lost the desire to apply it to the on-hold project. Now I just randomly return to old projects and add a commit or two and then get stuck again.
I've found it better to get a project to at least a finished 1.0 or Beta state before stopping.
I've found it better to get a project to at least a finished 1.0 or Beta state before stopping.
@htirwin: This project is definitely like that :P I'll take a break with it soon and read up properly.
@LB: Haha, I feel you, I have many old projects like that lying around as well.
@LB: Haha, I feel you, I have many old projects like that lying around as well.
It’s not a good sign if 99% of your projects are on hold...
When working on something voluntarily, motivation is the key. I think that most people have a hard time finishing something of non-trivial size in such situation, because there's so much other things to do.
The most important thing to succeed is probably to get results really fast. Don't strive for perfection. Use the highest-level language from the ones that are suitable for the task. Use libraries for anything that is not specific to this particular application. Don't bother with elaborate design, just make a list of critical features and code them as fast as possible. Don't make long breaks, if you don't work on a project for a week, you stop thinking about it, and you start thinking about something else, and that's very close to failing. From my experience, none of the things I abandoned for a few weeks or more was ever finished. I just don't like to return to the old code.
BTW, I don't consider myself to be a guru of getting things done ;) Probably the opposite actually, especially in the past. I'm still fighting with my bad habits, but it's much better than it was a few years ago, when I was doing matrix-vector multiplication in assembly, and using Windows C API to create window in my games, because with SDL/whatever it would not be "pure" ;)
When working on something voluntarily, motivation is the key. I think that most people have a hard time finishing something of non-trivial size in such situation, because there's so much other things to do.
The most important thing to succeed is probably to get results really fast. Don't strive for perfection. Use the highest-level language from the ones that are suitable for the task. Use libraries for anything that is not specific to this particular application. Don't bother with elaborate design, just make a list of critical features and code them as fast as possible. Don't make long breaks, if you don't work on a project for a week, you stop thinking about it, and you start thinking about something else, and that's very close to failing. From my experience, none of the things I abandoned for a few weeks or more was ever finished. I just don't like to return to the old code.
BTW, I don't consider myself to be a guru of getting things done ;) Probably the opposite actually, especially in the past. I'm still fighting with my bad habits, but it's much better than it was a few years ago, when I was doing matrix-vector multiplication in assembly, and using Windows C API to create window in my games, because with SDL/whatever it would not be "pure" ;)
Nothing wrong with unfinished projects in my opinion. I don't find any satisfaction in an immediate result. Just because something works doesn't mean its of quality or exactly what I would call satisfactory. When I have an idea or design, I want to implement that idea. The design or idea often affects the implementation so as to be efficient as well. If the implementation isn't efficient, it generally means I haven't properly implemented said idea.
| LB wrote: |
|---|
| I've found it better to get a project to at least a finished 1.0 or Beta state before stopping. |
| Abramus wrote: |
|---|
| From my experience, none of the things I abandoned for a few weeks or more was ever finished. |
I wasn't suggesting abandoning the problem. I was suggesting to stop banging your head against the table hacking away at a problem you are not ready to solve.
IMO it is faster and you get better results if you stop and learn the necessary information before continuing, in this kind of situation.
EDIT: fixed
Last edited on
You could try making some pseudo-code or program control flowcharts first, before trying to translate into commands you can clearly see all the logic behind it.
I've done the flow chart kinda thing myself but I've also made like maps for complex data types... Just sketched a bunch of boxes and arrows with labels on it. It really helps me to understand what I'm attempting to do rather than trying to keep it all in my head and getting confused.
I've done the flow chart kinda thing myself but I've also made like maps for complex data types... Just sketched a bunch of boxes and arrows with labels on it. It really helps me to understand what I'm attempting to do rather than trying to keep it all in my head and getting confused.
Last edited on
That's a good idea! I'll try that out. I still haven't figured out the problem that made me write this post in the first place, but luckily there are lots of other things I can focus on in the meantime :)
| fafner wrote: |
|---|
| That's a good idea! I'll try that out. I still haven't figured out the problem that made me write this post in the first place, but luckily there are lots of other things I can focus on in the meantime :) |
Why don't you try us? We're all on this forum to try and help each other out... Unless of course you particularly want to power through it on your own?
(I sometimes do that)
fafner:
I find that version control systems (I prefer Git) are really handy for experimentation if you don't want to screw up your project.
For example:
I'm working on a huge project, and I have never used variadic arguments before. If I use them, I'll have to refactor a lot of code to make it work. In git, I can just create a new branch, and refactor. If it doesn't work out, I can checkout my old branch, and delete the branch I experimented on, and I'll be where I was before. This makes it easy to undo changes that you may, or may not, want to keep, and makes the prospect of experimenting more.... friendly.
At least, that's the way it is for me. I encourage you, and anyone else who is reading this that hasn't used version control, to use version control systems.
I recommend Git: www.github.com is a fantastic tool, and Git is, in general, an excellent tool.
Also, if you're having trouble, a great reference:
www.cppreference.com
I find that version control systems (I prefer Git) are really handy for experimentation if you don't want to screw up your project.
For example:
I'm working on a huge project, and I have never used variadic arguments before. If I use them, I'll have to refactor a lot of code to make it work. In git, I can just create a new branch, and refactor. If it doesn't work out, I can checkout my old branch, and delete the branch I experimented on, and I'll be where I was before. This makes it easy to undo changes that you may, or may not, want to keep, and makes the prospect of experimenting more.... friendly.
At least, that's the way it is for me. I encourage you, and anyone else who is reading this that hasn't used version control, to use version control systems.
I recommend Git: www.github.com is a fantastic tool, and Git is, in general, an excellent tool.
Also, if you're having trouble, a great reference:
www.cppreference.com
Last edited on
So how is that different than making a copy of your project folder and saving it under a different name? Version control is fine if multiple people are working on a project, but it seems a bit overkill to me for a solo job.
I suppose making a completely fresh project folder and starting a new version isn't something to be undertaken lightly, for example not more than once per day. i know when I'm enthusiastically following a new idea, and re-writing some section of code, the overall code can change dramatically, several times in fairly rapid succession. Personally I'd be unlikely to have a fresh project at each stage, so the previous version which most interests me may not have been kept. Version control does for me simplify the keeping of intermediate versions which can sometimes avoid a lot of extra work in re-creating previous ideas.
Thanks for your suggestions guys :) I already use git, and its been really valuable in terms of going back if I do something horribly wrong!
Pages: 12