What I learnt
Things I’ve learnt:
ABOUT MYSELF – When things go wrong - I want to start over again afresh, but not rework the existing system.
I hate when there’s unforeseen challenges, complexities, etc that cause a refactor or reshift in ways that the application as a whole works. I’d rather that there was a single way of conceptualising how the back-end and front-end work. That way I know what to build. I want to know of a way that prevents that to a minimum.
I think something like SOLID would be a good idea on this.
ABOUT MYSELF – Trade-off between reality vs vision - building a house versus building a mansion
Consider the building of the entire application like a house. What is it? A cottage or is it a mansion? I know that I don’t want to build a little house that looks crappy, knowing I’m going to be building a mansion, and building around that and changing things internally and externally to then finally get to a mansion. I want to tear down that house, redo the foundations and start building the mansion bit by bit. But what I think I’m realising is that is too much of a daunting task - especially when I’m still learning a lot of these things.
Both of these things are incompatible with each other - wanting to have a clear vision of this ‘mansion’ and building to that design only, and also being overwhelmed by that and then feeling unproductive and demotivated. What can I do for this paradox?
- Realising there’s always going to be a trade-off in development between vision vs reality
- Build in increments, don’t build the whole mansion. If you need to redo the foundations, just do it for that area - and understand how it’ll be done and then work to that.
- Understand that there’s a natural moment where we are lost in all of the details before it starts coming together. Having a mentor would help a lot with this.
- Be open to changing things up when needed
ABOUT WORKING – Work back-to-front. Or in other words, work from the bottom up.
Here’s a rough idea on what exactly they mean by this according to a suggested workflow by a user on Reddit.
- Back-end architecture (database)
- Back-end providers (data fetchers)
- Back-end controllers & API (data source helpers or endpoints)
- Front-end business logic / state or data updaters / handlers (handlers)
- Front-end design / presenation layer
SYNTHESISING INFORMATION – Creating an Iterative, Back-to-Front development workflow:
This means that for example - consider building the mansion versus the house.
The mansion will have multiple rooms, the house might have a few simple rooms. That means that even though we have a good idea on how the mansion looks, that we are only working on doing the foundations, and building that room. We’re making sure that that structure is watertight and has a solid foundation.
This does mean that we need to build lower-level “rooms” before moving onto the higher-level “rooms” or even considering putting a roof on it.
In development terms this means:
- If we have to redo the database design, we only change what’s necessary
- If we have to redo basic development (core modules) then we only change what’s necessary
- If we are creating new modules, this is done in isolation away from the main branch. Meaning we are creating a separate development environment that we have much quicker access to testing database design, data types, business logic, presentation design, etc.
- We test thoroughly before we start integrating to the main branch.
- When we do merge branches - we should only be changing what is absolutely necessary.