I'm not convinced scripting languages are not suitable for large projects. It's said a lot, but I've never seen proof one way or the other. I suspect unmanageable code-bases derive from uncontrollable project forces, ignorance, or not caring, but not because of the perceived short comings of a scripting language.
For beginners, this is the last book to start with. I'm a big fan of Doug Crockford, but this book is opinionated and the examples are often not well explained.
There should be no shared code and all projects should be totally isolated from eachother. If you need shared code, fork it and maintain it to your needs.
Yes, it is about the deadlines. That's what keeps me getting a paycheck, which is the reason I'm working. What you describe as teamwork is just every day development activity. There is no discipline to attending a meeting when the meeting is mandatory.
I can always spot someone who 'runs teams' by the way they prioritize the company and piss on the workers in the name of the customer and 'teamwork.'
This is why you can't trust a manager. You can't seperate their nose from the company's ass.
More often than not, I see code without any comments. There's this idea of writing self documenting code that really changed the commenting world.
And that whole thing was evangelized by Uncle Bob and the Agile wrecking crew. Before long it was bad to use comments, switch statements, or new up an object. This, in turn, led to the TDD movement, Agile only movement, enterprise patterns for all projects movement, and I'm sure there are others I'm forgetting.
Please comment your code. Tell me what you're trying to accomplish with this block of code. The function name doesn't always suffice. And I don't want to stare at it for 15 minutes, or re-format your 160 column LINQ statement, or Google your regex so I can read what it does on StackOverflow.