If there are sections of code that are too complicated for everyone to safely modify then that is a failure of whoever wrote it and whoever reviewed it. At the

If there are sections of code that are too complicated for everyone to safely modify then that is a failure of whoever wrote it and whoever reviewed it. At the time, they may have patted themselves on the back but they need to understand that clever != good. It isn't clear the hierarchy or size of your team or the longterm strategy/goals of the product development. Someone on the team should be pushing back on these changes as they are being planned out or before they are getting merged in. Ideally, you have a respected senior/staff/cto engineer that can mentor these "clever" programmers. This person needs to be able to grok all the code and see at a macro level how the whole codebase is evolving. Re: reading code - I am the same way. I spent years writing objective-c when xcode had the best code completion out there so long names weren't an issue. Long function and variable names and tons of whitespace - it is how all of Apple's libraries were written and how the projects templates were setup ¯\_(ツ)_/¯. Best recommendation is to adopt a strict style for your codebase and ruthlessly apply it to all new code. Linting should happen automatically. There are tools that will run the linter on just the edited files so you can adopt coding styles 1 file at a time.