This is not about DevOps, but straight software development, I assume.

I want to understand the culture better

Well, the big thing in straight development (without the "DevOps" angle) is certainly "agile", i.e. for the most part SCRUM. You might do worse than to sit down and read the Agile Manifesto or a primer on SCRUM, or Kanban for the more day-to-day, bugfixing, maintnance jobs.

Aside from that, speaking of "culture" at all is, coming from the dev side, mostly a DevOps specific thing. Yes, we have our evangelists as well, specifically for newer stuff like ruby or golang, but not as extreme as in the DevOps/Cloud world, where there are actual paradigm shifts going on.

and how you digest the sheer number of files in your projects

Having worked on nontrivial ruby applications myself, that's no biggy. See, those files are not just strewn around nilly-willy, but there's a hierarchy, conventions and all that. You never actually need to have all those files in your head at a single point in time, for a well-designed project. If you work at a specific area, it is usually pretty clear where the relevant files are, and you can zoom in on them pretty easily. Same should go for other modern programming environments.

In bad applications, that is different, but then the developer won't actually "digest" anything, but just stumble around in a frenzy all day until he quits. ;)

This is not about DevOps, but straight software development, I assume.

I want to understand the culture better

Well, the big thing in straight development (without the "DevOps" angle) is certainly "agile", i.e. for the most part SCRUM. You might do worse than to sit down and read the Agile Manifesto or a primer on SCRUM, or Kanban for the more day-to-day, bugfixing, maintenance jobs.

Aside from that, speaking of "culture" at all is, coming from the dev side, mostly a DevOps specific thing. Yes, we have our evangelists as well, specifically for newer stuff like ruby or golang, but not as extreme as in the DevOps/Cloud world, where there are actual paradigm shifts going on.

and how you digest the sheer number of files in your projects

Having worked on nontrivial ruby applications myself, that's no biggy. See, those files are not just strewn around nilly-willy, but there's a hierarchy, conventions and all that. You never actually need to have all those files in your head at a single point in time, for a well-designed project. If you work at a specific area, it is usually pretty clear where the relevant files are, and you can zoom in on them pretty easily. Same should go for other modern programming environments.

In bad applications, that is different, but then the developer won't actually "digest" anything, but just stumble around in a frenzy all day until he quits. ;)