The more I code, the more I realize how important planning is. Having a good plan in place is the hard part. Writing the code that executes the plan is just a matter of experience and knowledge (Like those two things are easy to come by lol). But seriously, when tackling a new problem my planning skills are what determine whether the project is easy or difficult. With this recent project I skipped some of the planning and things went to garbage. Today I went back and re-thought out my design and things are looking much better. I hope I finally learned to never short-change the planning phase of a project. It will cause more problems that will cost more in the long run than rushing through it in the first place.
TLDR;
Okay, so here are the highlights of what I did:
- Practice -> Re-wrote my plans for the Battleship project. Writing out the smaller components first without fully walking through the program’s design made it difficult for me to make decisions with my code. I did not construct a thorough plan so I was confused at each step. Just because you try to decouple your code does not mean you don’t need to know how and what it will be used for.
Me Writing Myself Down From a Mini “Rage Quit” Moment
Q: What does the ship factory need to do?
A: The ship factory needs to construct ship objects for the gameboard.
Q: What external values does the ship factory need to construct a ship?
A: The ship factory needs a set of coordinates
I am feeling frustrated because I am trying to scope down my work and focus on specific object construction however, I cannot stop thinking about how the overall game is going to operate. I feel as though the decisions I am making are simply going to be wrong and will need to be corrected later on. If that is the case then wouldn’t this approach be incorrect. What exactly am I doing wrong here. Should I focus on the big picture items first or the small insignificant items first. Do the big picture items influence the small items or is it the other way around. Dealing with this issue is very frustrating. I do not know which is correct but I think that focusing on the smaller components first feels wrong. I don’t know why.
Q: Why focus on the small components first?
A: They are easier to complete and are less daunting to tackle.
Q: Why focus on the big components first?
A: Getting those right help to shape what is needed from the small components.
So, I think what I am missing is a proper breakdown of the Game loop I am trying to construct. I do not have a clear vision of what is needed from individual components and what will be provided. This likely stems from an unclear plan. I need to map out the flow of the game loop before proceeding to write the code for the smaller components.
Let’s have some patience and faith and give it another try. Since this is a new approach and methodology that you are implementing you need to put in extra effort in building out your plans so that you can refer back to them in the future when you may feel flustered and confused. It is annoying and time consuming but it will help you stay on track when things get difficult. Take your time and try to own the project. Don’t worry about how long it takes. This is about improving your process by trying new things not churning out another project.
To Do List:
- Write out the program flows in full sentences first to hash out my thoughts. (Don’t call it a game – this is a program taking user input)
- Write out the program flows using concise sentences.
Goal For Round 7 of the #100DaysofCode Challenge
This is my seventh round of the “#100daysofcode” challenge. I will be continuing my work from round five and round six into round seven. I am currently working through the book “Cracking the Coding Interview” by Gayle Laakmann McDowell. My goal is to become more familiar with algorithms and data structures. This goal was derived from my goal to better understand operating systems and key programs that I use in the terminal regularly e.g. Git. This goal was in turn derived from my desire to better understand the fundamental tools used for coding outside of popular GUIs. This in turn was derived from my desire to be a better back-end developer.
I have no idea if my path is correct but I am walking down this road anyways. Worst case scenario I learn a whole bunch of stuff that will help me out on my own personal projects.