The hardest part of getting my Sinatra project off the ground was sorting out my database schema. I knew of course that I could always make modifications later (and I did!), but I spent a ton of time really thinking through my relationships. The project is done now (or at least, the project-focused MVP) and frankly I’m not at all sure I made the right choices.
The real hard part for me is thinking deeply enough that I feel confident I’ve thought through all the future cases, but not so far that I newb-overarchitect the living daylights out of things.
I landed somewhere in the middle: my schema accomodated all the features I wanted to add, and I can see a path to the future ones I will add, but parts of it are overly complicated because they’re accounting for future things I may never do.
The whole exercise has also been one where I kept having moments like…
Ohh, now I totally get why that app I use isn’t adding that feature that seems super easy to me as an end-user.
and…
I finally get why that super simple feature at work took that long for the engineering team to implement.
And in some cases…
Nope, that was just poor technology choice, that app could’ve worked way better.
TL;DR I’m definitely still a critic by nature, but I’ve gotten far enough into app-building that I’m developing much more sound empathy for the folks who write the apps I use day to day.
For my app I chose to build something I could actually use, but I feel confident that if I kept building and got it much closer to what it’d need to be to be real-life useful, I’d very soon discover that Sinatra wasn’t the right tool. And it’s not that I’m down on Sinatra—more that too many times along the way I’ve hit a wall where a colleague just said “Oh yeah, that’s much easier in Rails, you’ll see.”
So I’m looking forward to the next module, and to maybe even rewriting this very app in Rails. I’ve learned a ton building it, and feel world’s ahead of where I was after the first module.
Onward!