I tend to think that things like high level documentation, organizing libraries and functions into good abstractions, comments, and naming make a bigger difference than the programming language chosen, within reason. The goal can be to make things as easy as possible for all developers as opposed to using every feature in a language.

There's a bunch of developer bad habits that can make collaboration hard. The processes and standards around development seem to make a bigger difference than the choice of language. So many coders don't bother with high level documentation, comments, or decent tests, nor do they spend the time to refactor their code as they go along to clean up readability issues. So many people just don't seem to want to bother, regardless of language. Often you have to fight management for time. I've seen atrocious and unmaintainable code in many languages.

> I'd love to read more about that. Have you by chance documented your experience somewhere?

My experiences grew to leading a team that were automating the reporting and deployment of complex configurations on a few tens of thousands of network devices, things like routers, switches, and voip, with all kinds of functionality for reporting, auditing, deployments, dry runs, debugging, etc. Perl is well suited to parsing and manipulating complex text configurations and outputs over ssh and interfacing to other related infrastructure applications.

We were able to process devices an order of magnitude faster than HPNA (java) and ansible (python). Our code was easier to read than code using these other systems, and more sustainable. We were able to handle complex projects like mpls cutovers, 802.11x and qos migrations and upgrades, etc. We'd translate complex network architecture standards to idempotent configuration management code. We also did a lot of reporting and compliance auditing. Some of it on short notice, most of it long lived.

Our project scripts read like pseudo code, a mix of perl and templating. The flexibility in perl helped us focus on representing our domain space as efficiently as possible. Our customers, who might be network engineers, managers, or compliance officers, could even read their project scripts, following the business logic, in this case the network architecture standards and/or reporting/auditing specifications.

Several of us were senior engineers, and there were always several junior engineers. Senior engineers tended to work on back-end library modules and more complex projects, at least getting them off the ground. Junior engineers were mostly contractors working on less complex projects. We made things easy for ourselves, tagging to-do notes by name and category in our source code. Everything was grep'able. Our processes were not in our way. Senior engineers would do code reviews, for readability, test coverage, and maintainability, usually just adding clarifying comments during a screen share and a phone call, maybe seeing a better way to arrange something, and be a second set of eyes looking for gotchas. We'd pay attention to the depth and complexity of our abstractions, try to keep user and developer documentation close to the relevant code, and have consistent naming for variables and functions. Seniors more frequently checked up on juniors. We'd discuss things as a group when need be. Customers were responsible for signing off on correct integration test outputs. I bet that well over half our bytes were comments, documentation, and tests.

My email address is in my profile, if anyone is more curious.