It's a serious handicap to trust people you can't have a dialogue with. And yet, we're basically forced to. While it's nice to have sources you can trust, it's a good start to just learn from a lot of sources with different viewpoints. Better still, sources that directly contradict one another. No, reading two news sites about the same event doesn't count. At the very least, read up on the history of everything. Nothing suddenly happens. We're all subject to a very long history that heavily influences where we're at and where we're going. Go read materials over two hundred years old. They'll help you escape the current context and examine the world through fresh eyes.
I mentioned in my post on How to Practice that Finding good tests is honestly the hardest part. Well, here's such a test. For every point you don't immediately understand, you've got studying to do.
This is one of those pieces I add to the sadly poorly studied practice of software rewrites. I think rewrites are both too common and not common enough. They're far too common when a new batch of hires who don't understand the system come into contact with it and the institution doesn't have enough pressure to prevent them blindly rewriting it without first understanding the inherit complexity of the thing.
At the other end of the spectrum, they're too infrequently done by developers after they've built a system but repeatedly patched it in response to the real customer needs until it's full of things that only make sense in the context of some future ideal state and two other legacy designs they still haven't moved off of.
The two key variables in play seem to me to be experience of the developers with the codebase and size of the change required of the codebase. Sadly, I only know of a few fairly old and limited studies on the empirical evidence associated with rewrites. Don't get me wrong, there's a lot on refactoring, but rewriting as a concept has become a taboo word we should reclaim. There are absolutely times where both the fastest and highest quality outcome lies in rewriting the software based on the understanding of what the customer seems to need now they've used the existing software.
Please stop trying to make self documenting code a thing. It's never going to be a thing. Naming your functions after the opening to War and Peace doesn't make it any easier to understand. Just write documentation.
I still remember when someone told me they honestly couldn't understand how you could create a web app without React. Sometimes I wonder how anyone manages to build anything while contently undermining the foundation. Maybe they're secretly engaged in a pursuit to generate perpetual employment?
