This is something that I have been musing over for the past few years and something I feel I need more opinions on. Almost everyone who uses these forums have programmed sometime in their life (obviously =P), so I think this would be the best place to ask these questions.
I don't know if it's just me, but for some reason after starting a project and getting about 1-2 weeks into it, there is a severe tapering off of enthusiasm to get it done. It seems like everytime I start one, I'm very confident that I can get it done and have fun doing it. Yet, as time progresses, the details of everything starts to bog me down. It starts to become a chore, and as I am doing this in my spare time, other options to spend my time become increasingly more likely for me to choose (as they are simply more fun). Although I realize that I want to learn programming and many more things A LOT more than I know now (and actually finish a game =/), knowledge seems to take a back seat to fun. Is this just me? Would it be easier to focus if it wasn't just me working on it? Or maybe it's because I'm still a student in high school (no programming classes at my school)?
Also, confidence really doesn't seem to be helping things. The majority of things I try to make myself end up not nearly as efficient as they should be, so I just end up looking at other people's code and copying that. Is this just a byproduct of teaching myself how to program, or is it just in my personality to favor simplicity and basic-level things over advanced, hyper-efficient, complicated things?
As always, all replies are welcome. I hope I do not come across as too "Oh woe is me", as I just want to see other people's opinions, ideas, and thoughts on this as I've really never heard anything other than my own ideas, thoughts, and opinions on this subject. This does not have to pertain to programming specifically, as most other projects of mine go down the gutter as soon as they become work.
Enthusiasm, Confidence, and Programming
All jobs are like that. Everything you enjoy starts out fun, and then becomes progressively less so as you wring out all the juicy bits.
Getting things done despite the boredom and monotony is a difficult (but crucial) skill, and it'll come with time, discipline, and overall maturity. Since you're young, I'd say it's a safe bet that you'll develop a more productive attitude over time... especially if/when programming starts paying your bills. It's a lot easier to buckle down and "do it" despite the grind when you have a mortgage and car payment to make.
As for confidence... be careful there. There's nothing wrong with being certain of your own skills, but a vastly more important thing is to know what you don't know. Understanding your limits - and stretching them - will make you a better programmer, better employee, and dare I say a better person overall. Overconfidence is a nasty thing.
The last point I'd make is that you should be perfectly comfortable starting with small, basic, simple, less-than-perfect solutions, and working your way up to more advanced, refined technique. It takes most people a solid decade to become half-decent programmers, and longer than that to start really truly putting out great code, so don't worry if you constantly find things that seem "better" than your own work. In fact, you should seek out those things, and learn from them - that'll factor into the stretching of your limits that I mentioned above.
Getting things done despite the boredom and monotony is a difficult (but crucial) skill, and it'll come with time, discipline, and overall maturity. Since you're young, I'd say it's a safe bet that you'll develop a more productive attitude over time... especially if/when programming starts paying your bills. It's a lot easier to buckle down and "do it" despite the grind when you have a mortgage and car payment to make.
As for confidence... be careful there. There's nothing wrong with being certain of your own skills, but a vastly more important thing is to know what you don't know. Understanding your limits - and stretching them - will make you a better programmer, better employee, and dare I say a better person overall. Overconfidence is a nasty thing.
The last point I'd make is that you should be perfectly comfortable starting with small, basic, simple, less-than-perfect solutions, and working your way up to more advanced, refined technique. It takes most people a solid decade to become half-decent programmers, and longer than that to start really truly putting out great code, so don't worry if you constantly find things that seem "better" than your own work. In fact, you should seek out those things, and learn from them - that'll factor into the stretching of your limits that I mentioned above.
Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]
Thanks for your reply =).
Haha, yeah, I figured that. I just thought that since a large number of people here, as myself, do programming as mainly a hobby thing, that maybe there's some way to eliminate/ignore monotony. Normally the only way for me to enjoy things is for there to be a large variety; games, activities, etc. get extremely boring as I do them more (I'm sure lots of people are like that), so it's just kinda hard for me to, like you said "buckle down and do it".
Couldn't agree more here. There definitely should be an equilibrium here: too high confidence and learning stops, too low confidence and you'll probably feel discouraged to do anything (kinda where I'm at, though the fact that no one's really learned anything until they tell themselves that they don't know and try to fix it really helps).
Good point. I didn't really think that it took that long of a time to get really good, so I guess I'm not that far off the average =P. It's just kind of disheartening to work on a project for 2 weeks and then discover this weird bug, learn that there's a massively better way to get things done, and then have to learn a ton of stuff to know how it works. Ah well, thanks a lot for your reply. It makes a lot of sense =).
All jobs are like that. Everything you enjoy starts out fun, and then becomes progressively less so as you wring out all the juicy bits.
Getting things done despite the boredom and monotony is a difficult (but crucial) skill, and it'll come with time, discipline, and overall maturity. Since you're young, I'd say it's a safe bet that you'll develop a more productive attitude over time... especially if/when programming starts paying your bills. It's a lot easier to buckle down and "do it" despite the grind when you have a mortgage and car payment to make.
Haha, yeah, I figured that. I just thought that since a large number of people here, as myself, do programming as mainly a hobby thing, that maybe there's some way to eliminate/ignore monotony. Normally the only way for me to enjoy things is for there to be a large variety; games, activities, etc. get extremely boring as I do them more (I'm sure lots of people are like that), so it's just kinda hard for me to, like you said "buckle down and do it".
As for confidence... be careful there. There's nothing wrong with being certain of your own skills, but a vastly more important thing is to know what you don't know. Understanding your limits - and stretching them - will make you a better programmer, better employee, and dare I say a better person overall. Overconfidence is a nasty thing.
Couldn't agree more here. There definitely should be an equilibrium here: too high confidence and learning stops, too low confidence and you'll probably feel discouraged to do anything (kinda where I'm at, though the fact that no one's really learned anything until they tell themselves that they don't know and try to fix it really helps).
The last point I'd make is that you should be perfectly comfortable starting with small, basic, simple, less-than-perfect solutions, and working your way up to more advanced, refined technique. It takes most people a solid decade to become half-decent programmers, and longer than that to start really truly putting out great code, so don't worry if you constantly find things that seem "better" than your own work. In fact, you should seek out those things, and learn from them - that'll factor into the stretching of your limits that I mentioned above.
Good point. I didn't really think that it took that long of a time to get really good, so I guess I'm not that far off the average =P. It's just kind of disheartening to work on a project for 2 weeks and then discover this weird bug, learn that there's a massively better way to get things done, and then have to learn a ton of stuff to know how it works. Ah well, thanks a lot for your reply. It makes a lot of sense =).
Prove me wrong so I can know what's right.
I just thought that since a large number of people here, as myself, do programming as mainly a hobby thing, that maybe there's some way to eliminate/ignore monotony.
As I get older, I increasingly realize the importance of the social aspect. If you work in the framework of a larger free software project, for example, those personal interaction can be a huge motivation to get down to the more tedious detail as well.
Widelands - laid back, free software strategy
I don't know if it's just me, but for some reason after starting a project and getting about 1-2 weeks into it, there is a severe tapering off of enthusiasm to get it done...[/quote]
I was like that with many projects in my first year of programming. I was able to get by by doing projects that only took me a week or two at most. Each project I started I would take as much code as I could from the last project, stripping out the application specific parts, and put them into a Utilities library that would grow and become more refined with each project. Eventually, last summer to be precise, I started a more ambitious project, making a game. Somehow I was able to not let myself do anything else in the evenings and on weekends. I pretty much filled every waking moment that I wasn't at my normal job working on this game. There were saturday mornings when I was quite tempted to play a game or do something else, but I convinced myself that what I really wanted was to finish this game. I managed to get it to where I wanted it after ten weeks. It was certainly more fun overall than the free time I've spent not programming, but there were tough days when it wasn't fun.
So what I learned from this was that I could actually start something and finish it. I learned that it did help not to take breaks from it. I did take one weekend off but managed to get back into it monday night. It helped to take on something manageable, that would quickly have rewards. I put together a buggy and simple but playable game in the first week using stolen graphics which I think really helped. The next nine weeks I was just improving and rewriting something that already worked. (I did make my own graphics before releasing.)Also, confidence really doesn't seem to be helping things. The majority of things I try to make myself end up not nearly as efficient as they should be, so I just end up looking at other people's code and copying that. Is this just a byproduct of teaching myself how to program, or is it just in my personality to favor simplicity and basic-level things over advanced, hyper-efficient, complicated things?[/quote]
Nothing wrong with copying other people's code especially when you're learning how to do things. Eventually you'll start writing things from the ground up yourself, but looking at online samples I think is good.advanced, hyper-efficient, complicated things[/quote]
Don't bother with this. Keep it simple, don't try too hard to make it efficient. Make something that works, and if it's too slow, then figure out why and fix it. I've stuck to this in all the projects I've finished, and almost never have I even needed to rewrite something to make it efficient. Eventually you'll need to, but if you're programming for yourself, and if you're trying to learn, it's not worth the effort yet.Would it be easier to focus if it wasn't just me working on it? [/quote]
I don't imagine it's wise to try to find other people to work with you on a hobby project. Chances are they'll be better than you and be able to do it better on their own, or they'll be worse than you and won't be too helpful.
This is all just my experience and opinion and I'm not the best authority on the subject.
There is a favorite quote of mine from CS Lewis. I couldn't find it exactly but to paraphrase, there is an intense excitement from a child when he dreams of flying in the sky. As the child grows older and begins to take flying lessons, that intense excitement is reduced and replaced with a much deeper love and respect for piloting an aircraft. When that person becomes a pilot, the initial rush is gone, but in the end a much stronger emotion is left.
I always thought the same way about making games (or any program for that matter). When you first have the idea or concept, there is a big rush of excitement. As you start to actually create, the monotony kind of kicks in and that rush fades away. But ultimately, the much deeper excitement of having a finished project which took time and dedication to complete and which people get enjoyment out of, is magnitudes greater than that initial excitement.
I always thought the same way about making games (or any program for that matter). When you first have the idea or concept, there is a big rush of excitement. As you start to actually create, the monotony kind of kicks in and that rush fades away. But ultimately, the much deeper excitement of having a finished project which took time and dedication to complete and which people get enjoyment out of, is magnitudes greater than that initial excitement.
These are all good suggestions, and you really should work on long term commitment. I have some short term tips to add.
First, make a todo list, and don't let it get too far ahead. Only add things that you could work on at the moment if you weren't already doing the first thing on the list. Continue to come up with cool ideas, but don't let them take priority over more important issues.
Second, show your game to as many people as possible, repeatedly. Update them on what is new and how you did it. Maybe ask for suggestions, or what they think of it.
Last, if you get stuck try to fix the problem yourself before getting help. Usually I spend half a day on some wierd bug I find, then I go online and ask for help, but I continue working on it myself. Its funny because I often find the bug just after I make the post.
First, make a todo list, and don't let it get too far ahead. Only add things that you could work on at the moment if you weren't already doing the first thing on the list. Continue to come up with cool ideas, but don't let them take priority over more important issues.
Second, show your game to as many people as possible, repeatedly. Update them on what is new and how you did it. Maybe ask for suggestions, or what they think of it.
Last, if you get stuck try to fix the problem yourself before getting help. Usually I spend half a day on some wierd bug I find, then I go online and ask for help, but I continue working on it myself. Its funny because I often find the bug just after I make the post.
Thank you everyone tons for your replies. Sorry for the extreme length of this post (I like to respond to people that I have something to say about).
As I get older, I increasingly realize the importance of the social aspect. If you work in the framework of a larger free software project, for example, those personal interaction can be a huge motivation to get down to the more tedious detail as well.[/quote]Second, show your game to as many people as possible, repeatedly. Update them on what is new and how you did it. Maybe ask for suggestions, or what they think of it.[/quote]
I agree, I normally combine these two. I'm no artist, so I normally ask one of my two friends (who are amazing artists) to help me with graphics for anything I need. The social aspect of telling someone what you have done, and then seeing their reaction is a pretty good motivator.I was like that with many projects in my first year of programming. I was able to get by by doing projects that only took me a week or two at most. Each project I started I would take as much code as I could from the last project, stripping out the application specific parts, and put them into a Utilities library that would grow and become more refined with each project. Eventually, last summer to be precise, I started a more ambitious project, making a game. Somehow I was able to not let myself do anything else in the evenings and on weekends. I pretty much filled every waking moment that I wasn't at my normal job working on this game. There were saturday mornings when I was quite tempted to play a game or do something else, but I convinced myself that what I really wanted was to finish this game. I managed to get it to where I wanted it after ten weeks. It was certainly more fun overall than the free time I've spent not programming, but there were tough days when it wasn't fun.
So what I learned from this was that I could actually start something and finish it. I learned that it did help not to take breaks from it. I did take one weekend off but managed to get back into it monday night. It helped to take on something manageable, that would quickly have rewards. I put together a buggy and simple but playable game in the first week using stolen graphics which I think really helped. The next nine weeks I was just improving and rewriting something that already worked. (I did make my own graphics before releasing.)[/quote]
Yes, this is good advice. Now I break my projects into smaller sections, get each section working before I go back and add in every minute detail, etc. It seems to make it more manageable.Nothing wrong with copying other people's code especially when you're learning how to do things. Eventually you'll start writing things from the ground up yourself, but looking at online samples I think is good.[/quote]
The problem I have with copying other people's code is that I learn majorly by doing it myself. Experiencing making it will help me understand the internal workings and why everything has to be the way that it is, rather than trying to understand someone else's code. Still, I guess that's one of the only way to really learn. Just difficult heh =P.Don't bother with this. Keep it simple, don't try too hard to make it efficient. Make something that works, and if it's too slow, then figure out why and fix it. I've stuck to this in all the projects I've finished, and almost never have I even needed to rewrite something to make it efficient. Eventually you'll need to, but if you're programming for yourself, and if you're trying to learn, it's not worth the effort yet[/quote]
The reason I said that I have problems with trying to make it complex, hyper-efficient, etc. is that I noticed I have a tendency to rely on very basic things (tons of if-statements, tons of integer variables controlling various things that I'm sure could be eliminated by doing something more efficient). Learning how to do more advanced techniques might come with time, it's just really confusing to be using all this "basic" things, and not really understand how to do the better solution. Just kind of the nagging side of myself saying that it has to be perfect =P.I don't imagine it's wise to try to find other people to work with you on a hobby project. Chances are they'll be better than you and be able to do it better on their own, or they'll be worse than you and won't be too helpful.[/quote]
Most definitely. This is something I've been musing over as well. I was just wondering if it might be interesting for it to be sort of a teaching method. Ah well, I've taught myself this far =P.This is all just my experience and opinion and I'm not the best authority on the subject.[/quote]
Experience and opinion is the best authority on this subject.There is a favorite quote of mine from CS Lewis. I couldn't find it exactly but to paraphrase, there is an intense excitement from a child when he dreams of flying in the sky. As the child grows older and begins to take flying lessons, that intense excitement is reduced and replaced with a much deeper love and respect for piloting an aircraft. When that person becomes a pilot, the initial rush is gone, but in the end a much stronger emotion is left.
I always thought the same way about making games (or any program for that matter). When you first have the idea or concept, there is a big rush of excitement. As you start to actually create, the monotony kind of kicks in and that rush fades away. But ultimately, the much deeper excitement of having a finished project which took time and dedication to complete and which people get enjoyment out of, is magnitudes greater than that initial excitement.[/quote]
Most definitely. I am really a lazy industrialist I guess: I want to create something, but I don't really enjoy the process to get to making it. But I guess I better learn to enjoy it =P.First, make a todo list, and don't let it get too far ahead. Only add things that you could work on at the moment if you weren't already doing the first thing on the list. Continue to come up with cool ideas, but don't let them take priority over more important issues.[/quote]
Already doing this =P. It's kinda hard to keep track of every bug you come across when you are testing something out, and I normally organize them into priorities, included with notes and documentation that I might get confused on later down the road.Last, if you get stuck try to fix the problem yourself before getting help. Usually I spend half a day on some wierd bug I find, then I go online and ask for help, but I continue working on it myself. Its funny because I often find the bug just after I make the post.[/quote]
Haha, it sure is annoying to spend half a day trying to figure out what's wrong with your program only to find out you didn't do something extremely simple; that has happened to me countless times.
Prove me wrong so I can know what's right.
What projects are you trying to do? Maybe you should make them open source and get others to work on it with you...to keep it interesting.
They hated on Jeezus, so you think I give a f***?!
Second, show your game to as many people as possible, repeatedly. Update them on what is new and how you did it. Maybe ask for suggestions, or what they think of it.[/quote]Strangely, I've always done the opposite. Maybe I've just gotten tired of seeing projects where people are talking about everything and then never end up releasing it, and I don't want to do that to people. I usually keep it to myself mostly until I have the first release out. Once it's released, then I tell people because they can use it. Every project I've released so far though, I've included my auto updating system, so I can keep improving it day by day as I get feedback.
In fact, that's one of the big motivators for me, now that I think on it. I get whatever I'm making into a usable state, and then release a public test version, where I make updates every day (or more than that) and they are installed for each user next time he runs it. If I get a bug report, I can often find the bug and release the update within hours or even minutes, and the user immediately has it fixed. Makes them happy, which makes me happy.The problem I have with copying other people's code is that I learn majorly by doing it myself. Experiencing making it will help me understand the internal workings and why everything has to be the way that it is, rather than trying to understand someone else's code. Still, I guess that's one of the only way to really learn. Just difficult heh =P.[/quote]
It works both ways. Benefits are you get exposed to other ways of writing code, you often learn new things if you look at what they did and wonder how/why/what they did.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement