<p>This is a sign of the growing maturity of infrastructure engineering as a field or a profession. If you consider any of the more traditional forms of engineering such as mechanical, civil or electrical, the bulk of the knowledge is is paper book form, that is how it is taught, practicing engineers consult reference books. That is because once the underlying principles are understood and codified, the details of implementation are specific only to a particular application or installation. You can consider any engineering artefact - a skyscraper or bridge, a jet engine, an aircraft carrier. Enormously sophisticated, requiring great skill to construct, but built using general principles that now they are understood, change only over the course of decades, and would be readily understandable to an engineer from decades ago. </p>

<p>Making it more DevOps specific - it really doesn't matter if you implement configuration management with CFEngine, Chef, Puppet or anything else, the principles of configuration management are well understood enough now that they can be written down and applied to any actual tool. </p>

CC BY-SA 3.0
2017-09-04T18:52:41.387Z
2017-09-04T18:52:41.387Z
Gaius
<p>In most cases, the recommended books are not about technology. While technology changes, the fundamental principles behind organizations like system thinking, leadership, common sense, etc... do not change as often.</p>

<p>Books such as <em>The Goal</em>, and even <em>The DevOps Handbook</em> do not mention much technology on their pages but rather ways to manage work being performed by people.</p>

<p>Many problems are technology related, topics such as Microservices, Architecting large-scale systems, Infrastructure as Code, etc... these don't talk about a specific tool and/or technology but rather about an architectural topic. A field of knowledge that people who build large systems need to know in order to build the system correctly. This knowledge is rare, and its great the books are written about these subjects - just disregard the tools mentioned, or translate into their new-er reincarnation.</p>

<p>One of the better books about creating quality software (imho) is <em>Agile Software Development, Principles, Patterns, and Practices</em>. And while the language used in this book (Java) has moved along quite a bit, the examples provided in the book are timeless and can be easily translated into any other language of choice.</p>

<p>Some of the problems the DevOps movement tries to solve are involved with common ways work is managed in organizations that just doesn't make any sense. As Eliyahu Goldratt often said (author of <em>The Goal</em>) "Common sense is not very common".</p>

<p>These books teach principles of thinking correctly about problems and human relationships in a system setting so that the whole system is improved. The lessons are old, and unfortunately, only rarely there are people who work in the field who actually learned them.</p>

<p>Naturally, there are also authors who wrote books about such and such fizz-bang tech tool that is new and relevant to the field, like AWS or Docker or Jenkins or whatever and just want to push their book sales ... but I try and exclude these kinds of blog posts from my answer.</p>

CC BY-SA 3.0
2017-09-04T19:08:09.997Z
That quote was originally Voltaire, I have never heard of this Goldratt
Gaius
CC BY-SA 3.0
2017-09-04T19:15:12.650Z
@Gaius Goldratt was quoting many smart people.
Evgeny Zislis
CC BY-SA 3.0
2017-09-04T14:42:15.880Z
2017-09-05T02:12:48.867Z
2017-09-05T02:12:48.867Z
Evgeny Zislis
<p>I have seen quite a few of the blogs I follow recommending more and more books over time.</p>

<p>I enjoy reading fiction and have no aversion to books but where a blogpost can be updated/rewritten when tech moves on these books which are normally ~£20-30 cannot.</p>

<p>Is there a particular quality to DevOps related titles which is missing from the online world or is everyone but me nuts?</p>

CC BY-SA 3.0
2017-09-04T14:49:38.300Z
The DevOps subject of matter is highly subjective and fluid. Which gives a lot more opportunities for book writing than other, more established fields. Many of such references are plain advertising, it doesn't necessarily mean they really are must-read references in the field (even if they're explicitly called like that).
Dan Cornilescu
CC BY-SA 3.0
2017-09-05T02:39:05.667Z
In general you don't know if it's snake oil until after you've bought it.
corsiKa
CC BY-SA 3.0
2017-09-05T07:42:03.947Z
DevOps duties start before the monitors are turned on    :-)
mcalex
<culture>
Why are books so prevalent in the DevOps community?
Briansbum
# Why are books so prevalent in the DevOps community?

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

I have seen quite a few of the blogs I follow recommending more and more books over time.

I enjoy reading fiction and have no aversion to books but where a blogpost can be updated/rewritten when tech moves on these books which are normally ~£20-30 cannot.

Is there a particular quality to DevOps related titles which is missing from the online world or is everyone but me nuts?

**Tags:** culture

> **Comments:**
> **username_1**: The DevOps subject of matter is highly subjective and fluid. Which gives a lot more opportunities for book writing than other, more established fields. Many of such references are plain advertising, it doesn't necessarily mean they really are must-read references in the field (even if they're explicitly called like that).  
> **username_2**: In general you don't know if it's snake oil until after you've bought it.  
> **username_3**: DevOps duties start before the monitors are turned on    :-)  

---

## 2 answers

### Answer by username_5 on 2017-09-04. Score: 16 | Accepted answer

In most cases, the recommended books are not about technology. While technology changes, the fundamental principles behind organizations like system thinking, leadership, common sense, etc... do not change as often.

Books such as *The Goal*, and even *The DevOps Handbook* do not mention much technology on their pages but rather ways to manage work being performed by people.

Many problems are technology related, topics such as Microservices, Architecting large-scale systems, Infrastructure as Code, etc... these don't talk about a specific tool and/or technology but rather about an architectural topic. A field of knowledge that people who build large systems need to know in order to build the system correctly. This knowledge is rare, and its great the books are written about these subjects - just disregard the tools mentioned, or translate into their new-er reincarnation.

One of the better books about creating quality software (imho) is *Agile Software Development, Principles, Patterns, and Practices*. And while the language used in this book (Java) has moved along quite a bit, the examples provided in the book are timeless and can be easily translated into any other language of choice.

Some of the problems the DevOps movement tries to solve are involved with common ways work is managed in organizations that just doesn't make any sense. As Eliyahu Goldratt often said (author of *The Goal*) "Common sense is not very common".

These books teach principles of thinking correctly about problems and human relationships in a system setting so that the whole system is improved. The lessons are old, and unfortunately, only rarely there are people who work in the field who actually learned them.

Naturally, there are also authors who wrote books about such and such fizz-bang tech tool that is new and relevant to the field, like AWS or Docker or Jenkins or whatever and just want to push their book sales ... but I try and exclude these kinds of blog posts from my answer.

> **Comments:**
> **username_4**: That quote was originally Voltaire, I have never heard of this Goldratt  
> **username_5**: @username_4 Goldratt was quoting many smart people.  

---

### Answer by username_4 on 2017-09-04. Score: 4

This is a sign of the growing maturity of infrastructure engineering as a field or a profession. If you consider any of the more traditional forms of engineering such as mechanical, civil or electrical, the bulk of the knowledge is is paper book form, that is how it is taught, practicing engineers consult reference books. That is because once the underlying principles are understood and codified, the details of implementation are specific only to a particular application or installation. You can consider any engineering artefact - a skyscraper or bridge, a jet engine, an aircraft carrier. Enormously sophisticated, requiring great skill to construct, but built using general principles that now they are understood, change only over the course of decades, and would be readily understandable to an engineer from decades ago.

Making it more DevOps specific - it really doesn't matter if you implement configuration management with CFEngine, Chef, Puppet or anything else, the principles of configuration management are well understood enough now that they can be written down and applied to any actual tool.


---

