Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
etmac53yWow. Seems exactly what i would want to do. Couple of questions.
1. How long have you been programming?
2. How do you or rather how did you avoid getting overwhelmed?
camel283yI agree man. I'm kinda at the same place although I admit I'm way closer to 2 than 3, I still have the idealistic perspective that things will work out simply because a certain kind of process is followed which is shown to be more stable. I'm slowly breaking out of that as I get more experience, modifying existing processes based on logical assumptions of what will be more stable and what won't.
Though I do wonder, is there a fourth layer? What would that look like? After you've conquered city building, will it be trying to conquer space -- building systems or processes of thought/code yourself?
Hot damn. Very well written.
It's an evolution of your decisions slowly affecting more people. I'm still trying to get into the third layer myself. And it probably has been the most nerve-wracking thing ever. This time experiments have long-term impacts and that's the reason why probably it's a lengthy process.
Hobby since '88, semi-professional since... 91-92 or so I think? I started by making small batches of game cartridges for the Commodore 64.
I don't avoid getting overwhelmed, once every while I bring 20 sticks of butter to the office, get naked, and challenge everyone who has wronged me to a wrestling match.
xprnio3793yIt's uncanny how relatable this is. Great write. I feel like I've just recently reached L2, while still having a few things in L1 (still tinkering with stuff I barely know enough about, just because I know there's much more for me to know about how things work and how to make them work together much better). Reaching L3 is probably the biggest process of them all, so I'm glad I've still got most of my life ahead of me
fuyukine173ythere are useful patterns for legacy refactorings too. It`s nothing new. Developers have been refactoring systems for years now. Look up "strangler pattern" and the term "anti-corruption layer". Disclaimer: It`s not easy and Microsoft, Google etc. are fighting these kinds of problems day to day. Game engines have to fight this issue on a regular basis as well.
EDIT: I realize this wasn`t op`s point, might be of interest to the common passerby nonetheless.
I agree that strangling has advantages over fully rewriting.
The issue is that the "eliminate" phase of the strangler pattern is extremely difficult to get done: Even when you successfully move a service out of your monolith, you're still stuck with adapters in the monolith to make it successfully communicate with the spaghetti.
Engineers now have to deal with even more paradigms.
Then there's always the Complicated InfrequentlyUsedHighlyCoupledService — something which will take a few weeks to decouple into a nice separately deployable service, but management will never allow for that time allocation.
They won't see the weight of the technical debt of maintaining two paradigms, they only see a "that service is currently working fine and doesn't need a feature change, it can stay in the monolith"
The issue with incremental replacement is that some systems will never be visited, so you'll end up with an amalgamation of legacy+modern — which is arguably worse than a unified legacy system.
We had a similar issue with something simpler than microservice backends: CSS frameworks. First there was bootstrap. People hated it, so the idea was to replace it incrementally with every new/rewritten feature. People hated the replacement, so another alternative was chosen. Managers only visit & revisit popular places on the website for tweaks & rewrites — so now we have three CSS systems.