A very long time ago, before recorded history, there was a tribe of cave(wo)men. In order to survive, each worked as they could trying to do their best. But the problem was they pretty much acted on their own, in a chaotic way, without a plan or leadership. Their work was chaotic and some chores, like hunting was a really (sometimes literally) PITA.

A smart man (it was a patriarchal system, they didn't listen to women) realised that they need to organise themselves, have a plan and a leader who will manage the group to reach the proposed objective. The group was split in smaller groups called teams and each team member had a specific role to fulfill.

This helped our ancestors to be much more efficient in solving their problems. The strong guys formed hunting and raiding parties, the women helped with food gathering and making, raising children and fighting the occasional war, defending their home. Some people learned how to process copper, then iron and made tools out of it. They became miners and smiths. Other were farmers, other begun to wonder why things are how they are, others made music and paintings. Some thousands of years later, their offsprings built great temples and monuments like the Pyramids.

What made all these things possible? The art of organising people and tasks. A leader would create a strategy (a plan) to achieve an objective. (S)He would group the workers in teams, each team with a specific minor objective and each team member with a clear role. The teams would be autonomous but collaborate one with each other in order to accomplish the big goal. The teams (and within them, the workers) would not step on each others feet, duplicating work or objective. And while some work was duplicated it was in a specific context, required for that specific goal.

The secret of maintainable code is good management. Writing good code, besides satisfying stakeholders' needs, it's a matter of code organisation. As a developer, you are the leader of teams (application modules), and most of the time you have the great advantage of creating its very own workers (the objects). It's not a matter of picking the right person for the right job, it's a matter of designing the right worker (objects, methods) for the job. You have so much power, imagine that, to create from scratch all the team's members, all fit for their respective role.

You can employ the SOLID principles to help you manage the code better, but you are still in charge. Actually, it's up to you to implement properly the principles where it makes sense. It's up to you to be a great leader and manager and the way you're organising the code it's the proof of your skill.

P.S: One of the reasons Hitler lost the war was conflicting command chain. Hitler was paranoid and he didn't trust his generals, so no general would actually command alone one big army corp. Hitler loved to pair generals with conflicting views so that they keep each other in check. Needless to say, that had a profound impact on the german army, ironically famous for discipline and efficiency.

P.P.S: In ancient times, the greek hoplites and then phalanx was the most powerful land unit. A tight wall of long spears and shields was the armored tank of the day. While it was virtually unbeatable from front, it was very hard to manoeuvre, very slow and vulnerable to flank and rear attacks. The romans managed to beat them by grouping their soldiers into maniples, a small semi-autonomous unit, armed with short swords. The maniples were very flexible and could flank the hoplites very fast, while other maniples were keeping it occupied in the front. The big roman shields protected them from the long spears, while they would get close to the greeks and hacked them with the swords, disrupting their lines. The phalanx failed because it was a very rigid monolith, although extremely powerful in frontal combat especially against other spearmen, its rigidity made it unable to adapt quickly to the changes on the battle field. The roman flexible organisation was simply better in the long run.