In my experience, this often doesn’t happen. So many developers are either inexperienced or cowboys, and there’s nothing inherently wrong with either. But at places where projects are small and numerous, teams often end up with nothing but a combination of the two.
As one of our office’s engineering “fixers”, I’ve taken over maintenance of several such projects. They usually have shattered remnants of code taken from other projects, open source libraries, internal libraries, stack overflow, and so on. Whole source files copied into the project, modified in ways that introduce impressive new failure cases while failing to add new functionality, and used in ways that completely ignore the features natively implemented in that code while those same features are bodged in as barely-working piles of if statements, balanced on a knife’s edge to avoid triggering the failure modes added by the project’s modifications of the copied code. I’m usually able to purge 20-30k lines of code from such projects in the first month, simultaneously closing multiple outstanding issues the PM had been led to believe were intractable.
That probably sounds like arrogance and/or shitting on everybody else’s work but it’s just reality at many workplaces due to a pace driven by unreasonable expectations from management. I just happen to be the person here that ends up sifting through the wreckage when a project reaches the inevitable osteoporosis phase, because of a natural disposition for reverse engineering. It would be great to escape for this and other reasons, as far as I can tell, most places aren’t that different.
This can work for junior devs who aren’t stuck in their ways. Unfortunately there are too many “senior” devs who are happy making crap. It’s hard to fight them constantly to do things properly (e.g. write actual commit messages rather than just “Fix #836”) so using tools like linters where possible is definitely a big improvement.
