Many of us know this, man, the problem is, 80% of the time, leadership who indeed (as you said) asserts “if it ain’t broke don’t fix it”. The other 20% are spoiled programmers that constantly have to touch their code out of some misguided sense of perfection or vanity.

The job of us the senior programmers should also be to educate. Use any analogy you can – car needs changing of oil and while doing that the mechanic might notice a bigger problem is a good example that I found stuck with a good amount of business people – and do your best to get the message across.

We have to find a way to communicate the challenges of just letting the code sit and never get updated. Because unfortunately people come to tech with a lot of uninformed bias and prejudice and they have to be either educated out of it, or we should leave. Or we can just make peace with it, collect paycheck and do the minimum – I don’t blame the people doing it because fighting with leadership is (a) not everyone’s goal in life and (b) very hard.

Testing is a first class citizen in Elixir and same for Phoenix framework as well.

Elixir’s founder, Jose Valim even pointed out in his talk about his future with Elixir, that Types don’t solve the errors or help greatly with refactors, it’s the tests that enable us to have the fearless refactors. (See: Types lead to fewer tests)

Testing is so well integrated that the code examples mentioned in the documentation are verified as well, so they don’t end up breaking later on!!

Testing with Live View takes it to whole another level, i.e. you test your whole site in parallel, and without a headless chrome or browser instance slowing your tests down!!

But man it depends on the company, I have been part of 2 such companies in my 7+ years of experience and they make us work as if the world is about to halt without their products and services.

Sprint after sprint with no breathing room, while “SCRUM Master” tersely explains, after office hours, that the ticket needs to go by this sprint & that deployment needs to happen by weekend.

And the beautiful architecture you dreamt for yourself, gets thrown into the mixer. It gets unrecognisable with each sprint.

Business use cases gets so twisted that even the browser groans while rendering your simple form, while it happily plays shadertoy or youtube on the side.

GitHub action pipeline consists of shallow metrics, that is so detached from reality that it shows a green tick even when the changes made will fail at runtime.

The application so unnecessarily distributed that you can’t make heads from tails. Good luck running distributed testing on a graph of micro services that’s so dense, even OOP inheritance gets put to shame.

So perhaps testing is not the root cause of our fear, rather its Scrum, Sprints & Microservices!.

I believe ousting people who have no business in Software Engineering and getting rid of the scrum bi-weekly waterfall model, for development, will be a step in the right direction.

And to top it all of, maybe we should return back to monke Monoliths, with a dash of Tests on the side.

…or just the programmer is too busy, has a family, multiple jobs, multiple customers, other priority projects, other personal issues so he won’t update its code unless it’s requested by leadership/customer: “it’s broken, fix it!”. IMO, this happens 99% of the time.