Hey. So many people ask me for advice as a beginning programmer. I honestly never answered the question though, not because I was busy but because I didn't know how to word a response that illustrated how I felt until now.
-------------------------------------------------------------------------------------------------
Here's my advice for beginning owners and programmers:
1. Don't tackle the problem head-on with a solution. Analyze the problem first and try to gain an understanding of it, then divide it up into manageable pieces. Big problems are overwhelming, so break it down.
2. You will not get a perfect solution working (most of the time) for challenging problems on the first tackle. It's a trial and error process. Refine your algorithm and try again - you'll get closer and closer to getting the correct solution. Do you think the light bulb was invented on the first try?
3. Build upon the knowledge that you've already acquired. Research into new solutions and find similarities with solutions you already know from previous problems. Don't go too far outside your range of understanding.
4. Eliminate processes that don't fit the requirements of the project. You'll find yourself constantly thinking about solutions to problems or requirements in the project. It's your job as a programmer to eliminate wrong solutions and to develop a solution that will fill the requirements of the project. Make lists or excel books if it's hard to manage.
5. Thinking outside the box will get you far. Our minds are trained to limit thought and to specify rather than to generalize or expand. Most of the best ideas and solutions come from thinking outside the limits you restricted yourself to.
-------------------------------------------------------------------------------------------------
I also want to share with you my way of designing applications. It's not a new concept, but this is how you would prevent yourself from restarting your project over and over again (like I used to).
Step 1: Requirements - analyze the problem and define the problem's needs (inputs and outputs).
Step 2: Design - determine how you're going to approach and solve problems that arise.
Step 3: Implement - code and document the program. Use basic testing as you go.
Step 4: Test - test the solution and formulate algorithms that will solve the problem.
Step 5: Maintenance - fix the problems and test again. Fix bugs that you might of missed in the implementation phase.
If you don't spend enough time in the Requirements and Design phase, you're going to find yourself running into many many problems (like I have been with my previous projects). Take it slow and develop your ideas before you attempt to implement them.
-------------------------------------------------------------------------------------------------
Tips:
1. Make a chart of hierarchical Input and Output. How are classes going to be organized and fetched from different documents / namespaces?
2. If you want to use multiple projects for core algorithms, use the same namespace. Make a chart like above for dependency. DO NOT USE CIRCULAR DEPENDENCY!! Use one way dependency or you will run into many problems (like Impulse's NPC project in his 5165 source but much worse).
3. Use pseudocode if you're going to help someone. They won't improve much unless they build upon what they know. Also, it can be very helpful for you in organizing how you're going to design an algorithm.
4. Use "desk checks" / breakpoint tests. "Desk Check" is the term for walking through a solution (step-by-step). You can do this by setting up a breakpoint. That's how most people debug and test solutions as they implement.
5. There's nothing wrong with making diagrams for your understanding. Nobody expects you to memorize everything about your project or research. Make resources... I mean hell, I made an entire wiki to organize mine. It's more for me than anyone else.
That's all that I can think of atm about programming.
For everyone who ever asked, that's my answer and I'm not repeating it.
-------------------------------------------------------------------------------------------------
As far as making a private server goes... it's all about power management and support.
1. Don't make a server that you cannot handle. Gather support before you organize it on a VPS that you need to pay for. Don't waste your money! I've seen it happen time after time again.
2. Have fun. Don't look at it as just a business. Have fun programming and creating and have fun with your community. I don't think I have to repeat what's been said before about managing your GM powers, but I will anyways. Your GM powers don't belong on your main character if power is a problem for you.
3. Support is important. Listen to comments that your players leave for you. They took time to develop an idea for you, so spend at least a second to read it.
That's it for now.
Good luck.
Sincerely,
Fang
PS: Useful links:
Additional Explanation of pseudocode:
So let's say you have a problem. You know what the solution will be, but you don't know how to get there really. You would use pseudocode to fill that. Pseudocode literally means "fake code". It's like a proof in math. You're going through each step and explaining it in English instead of using mathematical formulas and solving it directly. It helps organize what you need to do to find the solution.
-------------------------------------------------------------------------------------------------
Here's my advice for beginning owners and programmers:
1. Don't tackle the problem head-on with a solution. Analyze the problem first and try to gain an understanding of it, then divide it up into manageable pieces. Big problems are overwhelming, so break it down.
2. You will not get a perfect solution working (most of the time) for challenging problems on the first tackle. It's a trial and error process. Refine your algorithm and try again - you'll get closer and closer to getting the correct solution. Do you think the light bulb was invented on the first try?
3. Build upon the knowledge that you've already acquired. Research into new solutions and find similarities with solutions you already know from previous problems. Don't go too far outside your range of understanding.
4. Eliminate processes that don't fit the requirements of the project. You'll find yourself constantly thinking about solutions to problems or requirements in the project. It's your job as a programmer to eliminate wrong solutions and to develop a solution that will fill the requirements of the project. Make lists or excel books if it's hard to manage.
5. Thinking outside the box will get you far. Our minds are trained to limit thought and to specify rather than to generalize or expand. Most of the best ideas and solutions come from thinking outside the limits you restricted yourself to.
-------------------------------------------------------------------------------------------------
I also want to share with you my way of designing applications. It's not a new concept, but this is how you would prevent yourself from restarting your project over and over again (like I used to).
Step 1: Requirements - analyze the problem and define the problem's needs (inputs and outputs).
Step 2: Design - determine how you're going to approach and solve problems that arise.
Step 3: Implement - code and document the program. Use basic testing as you go.
Step 4: Test - test the solution and formulate algorithms that will solve the problem.
Step 5: Maintenance - fix the problems and test again. Fix bugs that you might of missed in the implementation phase.
If you don't spend enough time in the Requirements and Design phase, you're going to find yourself running into many many problems (like I have been with my previous projects). Take it slow and develop your ideas before you attempt to implement them.
-------------------------------------------------------------------------------------------------
Tips:
1. Make a chart of hierarchical Input and Output. How are classes going to be organized and fetched from different documents / namespaces?
2. If you want to use multiple projects for core algorithms, use the same namespace. Make a chart like above for dependency. DO NOT USE CIRCULAR DEPENDENCY!! Use one way dependency or you will run into many problems (like Impulse's NPC project in his 5165 source but much worse).
3. Use pseudocode if you're going to help someone. They won't improve much unless they build upon what they know. Also, it can be very helpful for you in organizing how you're going to design an algorithm.
4. Use "desk checks" / breakpoint tests. "Desk Check" is the term for walking through a solution (step-by-step). You can do this by setting up a breakpoint. That's how most people debug and test solutions as they implement.
5. There's nothing wrong with making diagrams for your understanding. Nobody expects you to memorize everything about your project or research. Make resources... I mean hell, I made an entire wiki to organize mine. It's more for me than anyone else.
That's all that I can think of atm about programming.
For everyone who ever asked, that's my answer and I'm not repeating it.
-------------------------------------------------------------------------------------------------
As far as making a private server goes... it's all about power management and support.
1. Don't make a server that you cannot handle. Gather support before you organize it on a VPS that you need to pay for. Don't waste your money! I've seen it happen time after time again.
2. Have fun. Don't look at it as just a business. Have fun programming and creating and have fun with your community. I don't think I have to repeat what's been said before about managing your GM powers, but I will anyways. Your GM powers don't belong on your main character if power is a problem for you.
3. Support is important. Listen to comments that your players leave for you. They took time to develop an idea for you, so spend at least a second to read it.
That's it for now.
Good luck.
Sincerely,
Fang
PS: Useful links:
|
|
Additional Explanation of pseudocode:
So let's say you have a problem. You know what the solution will be, but you don't know how to get there really. You would use pseudocode to fill that. Pseudocode literally means "fake code". It's like a proof in math. You're going through each step and explaining it in English instead of using mathematical formulas and solving it directly. It helps organize what you need to do to find the solution.
