> You can't reliably deduced anything about what your current problem is, if the things it depends on are flaky.
Interesting, as a junior dev I always start thinking about the fun architecture stuff first and end up being slow to complete a project. I figure that deploying one place vs another is so different you want to deploy early and often for testing. Maybe I should just start getting the basic functionality and tests down before packing it up into docker containers and running it on kubernetes and all that?
Each part you add must be rock solid before you move on to the next that depends on it.
That doesn't mean you have to do everything... merely make it solid and reliable.
Say you plan to depend on a subsystem that is going to do something wonderful and flashy.... but you don't need it right now, you just need to build the place where it's going slot in....
Then don't put your sketch of the wonderful shiny thing into your dependency tree, put a mock that might do nothing, but does nothing utterly reliably.
If you have something flaky firing bullshit events and rubbish into your whole system while you're trying to get the rest going... you're just going to hurt yourself.
You can add a feature toggle or chicken bit to switch the new shiny/flaky stuff in when you want to contemplate it, and switch it out when you're working on the rest of the stuff.
Interesting, as a junior dev I always start thinking about the fun architecture stuff first and end up being slow to complete a project. I figure that deploying one place vs another is so different you want to deploy early and often for testing. Maybe I should just start getting the basic functionality and tests down before packing it up into docker containers and running it on kubernetes and all that?