While I'm writing code, I have to constantly remind of scope. The scope of my variables, the scope of my functions, and the scope of my ideas.
The scope of my variables and functions can be easy to fix. If my program isn't working as I expect, I follow steps to debug that issue. The scope of my ideas can be a much bigger problem to tackle.
When creating a project, an assignment or for fun, I dream big. Nothing wrong with that. Building a program with lots of functionality and cool features is a noble goal for any programmer.
My process starts with the baseline idea: What do I want to build? What purpose will it serve? In my case, I decided on a basketball league stat tracking app.
My next step is to establish how I want my program to perform: How will it display information? What type of information will be displayed? How will my website look? What will my backend look like? How do my models interact? Can my program take user input? How will I gather that input? Are there any validations for that input?
This step is usually where scoping, and my dream big mentality, become a problem. The programmatic way to deal with this is to abstract that step into much smaller steps, such as wire framing, establishing models and associations and finally moving onto user-facing side of the app.
As a total newbie, that is not what happened the first time I sat down and plotted out my app. Eventually I got an idea of what I wanted to do and how I was going to do it.
I started with the database, and some seed data. I set up games and seasons, but I skipped over an important piece: player data and team data. A game can't have statistics if I player doesn't exist to score some points.
Once I got my faulty seeds set up I moved right into adding functionality, like displaying the information about the game. My program was not working as I expected it to, and I began to second guess my whole idea. The functionality I was adding relied on foundational work I hadn't laid out yet. I recognized that if I was going to add really cool features to my program having a working program as the foundation was the key.
I spent too much trying to figure out what was going on before realizing that I should focus on the smaller pieces of a program that serve as building blocks, before tackling the "cool and exciting" part of a program.
If I could go back in time, I would tell myself to create an ordered list of things I needed to do. The list of cool features would be at the end, and the necessary but not as exciting bits would be at the beginning.
Top comments (0)