<p>Since you've tagged this question as "culture", I'm assuming you're not interested in a specific application, but in the broader questions of workflow and management.</p>

<p>I'd probably start with "The DevOps Handbook"; it's a good overview of different things to consider, without diving too deep.</p>

<p>"Continuous Delivery" by Jez Humble is also often referenced; I haven't read much of it yet, but it covers the concepts of source control &amp; automation of builds.</p>

<p>If you're starting to get into applications at scale (this may be too much of an assumption), another good book is "The Practice of Cloud System Administration" by Limoncelli et al.</p>

CC BY-SA 3.0
2017-09-15T21:53:56.770Z
I read about 60% of the Limoncelli book before losing it in a move. It definitely taught me a lot. I've also just started "The Phoenix Project" by Gene Kim et al., which is a surprisingly compelling read while also teaching a lot.
Stephen C
CC BY-SA 3.0
2017-09-16T01:56:32.270Z
I also liked the Google SRE book; it's actually a better fit for me at my organization than some of the DevOps stuff, but the book itself is disjointed.  You have to read it out of order, picking the chapters which appeal to you, and skimming the rest.
Stuart Ainsworth
CC BY-SA 3.0
2017-09-15T17:41:36.387Z
2017-09-15T17:41:36.387Z
Stuart Ainsworth
<p>This is not about DevOps, but straight software development, I assume.</p>

<blockquote>
  <p>I want to understand the culture better </p>
</blockquote>

<p>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.</p>

<p>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.</p>

<blockquote>
  <p>and how you digest the sheer number of files in your projects</p>
</blockquote>

<p>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 <em>should</em> go for other modern programming environments.</p>

<p>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. ;)</p>

CC BY-SA 3.0
2017-09-15T20:24:03.297Z
2017-09-15T21:57:29.470Z
2017-09-15T21:57:29.470Z
AnoE
<p>I schooled in CompSci where we were primarily taught Java, but what I <em>learned</em> there is that my passion is systems, so I've always worked the ops side. I'm handy with scripting, so I'm not looking for a site to teach me Ruby, but something to explain more in-depth what you devs do all day. I want to understand the culture better and how you digest the sheer number of files in your projects -- the intangibles. </p>

<p>If I learned today I was being moved to a development team on Monday, what would I want to read this weekend?</p>

CC BY-SA 3.0
2017-09-15T17:31:20.087Z
I'd start reading my "contract" ... even if it was only if you need to re-negociate your salary ... Apart from that, just a weekend is for sure not enough to read anything relevant, especially because you don't seem to know with what kind of "infrastructure" you'll be working with ... imagine it's a mainframe running all sorts of zLinux instances ... with the "z" being a shortcut for *zero downtime* (not negociatable) ... to keep airplanes in the air ...
Pierre.Vriens
CC BY-SA 3.0
2017-09-15T22:25:37.167Z
@Pierre.Vriens, Hilarious comment. Rest assured, this is not actually happening or I'd be busy with my LinkedIn account right now, but I don't think that sort of move would be extraordinary these days. Some organizations might really benefit by trading some staff members between dev teams and ops, and I'm sure some organizations do just that during drives to "implement DevOps."
Stephen C
<culture><builds><methodology><software-engineering>
Crash course in Dev for Ops?
Stephen C
# Crash course in Dev for Ops?

(Asked by: username_0 on 2017-09-15)

I schooled in CompSci where we were primarily taught Java, but what I *learned* there is that my passion is systems, so I've always worked the ops side. I'm handy with scripting, so I'm not looking for a site to teach me Ruby, but something to explain more in-depth what you devs do all day. I want to understand the culture better and how you digest the sheer number of files in your projects -- the intangibles.

If I learned today I was being moved to a development team on Monday, what would I want to read this weekend?

**Tags:** culture, builds, methodology, software-engineering

> **Comments:**
> **username_1**: I'd start reading my "contract" ... even if it was only if you need to re-negociate your salary ... Apart from that, just a weekend is for sure not enough to read anything relevant, especially because you don't seem to know with what kind of "infrastructure" you'll be working with ... imagine it's a mainframe running all sorts of zLinux instances ... with the "z" being a shortcut for *zero downtime* (not negociatable) ... to keep airplanes in the air ...  
> **username_0**: @username_1, Hilarious comment. Rest assured, this is not actually happening or I'd be busy with my LinkedIn account right now, but I don't think that sort of move would be extraordinary these days. Some organizations might really benefit by trading some staff members between dev teams and ops, and I'm sure some organizations do just that during drives to "implement DevOps."  

---

## 2 answers

### Answer by username_2 on 2017-09-15. Score: 8

Since you've tagged this question as "culture", I'm assuming you're not interested in a specific application, but in the broader questions of workflow and management.

I'd probably start with "The DevOps Handbook"; it's a good overview of different things to consider, without diving too deep.

"Continuous Delivery" by Jez Humble is also often referenced; I haven't read much of it yet, but it covers the concepts of source control & automation of builds.

If you're starting to get into applications at scale (this may be too much of an assumption), another good book is "The Practice of Cloud System Administration" by Limoncelli et al.

> **Comments:**
> **username_0**: I read about 60% of the Limoncelli book before losing it in a move. It definitely taught me a lot. I've also just started "The Phoenix Project" by Gene Kim et al., which is a surprisingly compelling read while also teaching a lot.  
> **username_2**: I also liked the Google SRE book; it's actually a better fit for me at my organization than some of the DevOps stuff, but the book itself is disjointed.  You have to read it out of order, picking the chapters which appeal to you, and skimming the rest.  

---

### Answer by username_3 on 2017-09-15. Score: 7

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. ;)


---

