Planning and Being Strategic?
My Big Thinking and Planning 🤔
It’s probably been about a month since I started building out my CRUD-type project. So far, it has been fairly productive. I feel like I’ve committed a lot to muscle memory using nvim. It really allowed me to focus back on the code rather than the physical typing dexterity. At the same time, I think I’ve also gotten a nice grasp of Go; it’s like what the internet says – it’s very much like “easy” C. So far, I like it quite a lot!
Now that most of my personal objectives are on track – I definitely have more time to look back on how I started planning for this project versus today.
At the start, I probably spent the most time planning out the database. What tables do I need? What columns should exist? What other useful things might I want to keep? So many questions to ask myself. As I then began to write the first lines of code, I kept running back to the database wondering if I needed things like NO NULL, UNIQUE, and triggers. Yes, I added all that and some. Maybe in the future, I’ll try to simply just code and add onto the database as I go – perhaps there’s some efficiency gain to be found? However, I don’t feel like it was time wasted. After all, once the DB setup was done, it was a lot easier to code around; the structure was already well-enshrined in my mind. Better yet, I haven’t had to modify the database schema in a long time! I’m not doubting that a well-planned database early on will allow you to maintain a higher level of productivity, especially when going deeper into the project.
Another Thinking Moment 🕧🕜🕝
As the app started to grow, you know you’ve started leaving boilerplate territory as soon as you start thinking about your business rules and validation. While keeping mindful of my design choices, eventually my “best choices” became a victim of circular dependency. I wanted the write operation’s results to be reflected into the database, but I made my columns NO NULL from the start because logically something like a name should never be null. Should I make an insert into the database first and add the name afterwards? Well, no, in my case, something like a file write has priority and would determine the output of the remainder of the function.
graph LR; SQL[DB]--DB generates filename-->F[File system] F--File system generates filename-->SQL
I could have removed the NO NULL from the column and gone down that route, but it would break what I think are good design choices. So, the only option I had was to completely rethink about what my field could look like. That’s so simple in hindsight! The very act of thinking outside the box was the simple solution. Originally, I was rigid on a naming convention; it never came across my mind. By removing the naming convention, it didn’t break my database column, and on paper, still looks to be a high-performance implementation.
All this pondering took some time. I don’t think I was happy with each solution that came into my mind. Maybe just going with the flow and letting the river take you wherever you need to go is what I need. Sounds simple, but it’s been a lot of work going back and forth fixing up code all over the place.
Again, not a lost cause. All of the back and forth reinforced my learning and has been building my experience. I haven’t done programming on such a lengthy project, daily, consistently before. I consider myself still inexperienced; I have a long way to go!
Part of the reason for this blog’s existence is to journal my thoughts about things like this post - I recognize these as incredibly valuable learning moments I wish to look back on regularly.