1. 7
  1.  

  2. 1

    I like a fair bit of this piece, especially this:

    Our job as systems or ops engineers should be on how to build, maintain, troubleshoot, and retire the systems we’re responsible for. But there’s been a shift building that has us focusing more on becoming experts at evaluating new technology.

    There are some good examples and perspective in there, but the second half of the essay is a mess. The section “Four Basic Requirements” comes of out of nowhere and this paragraph doesn’t make sense to me.

    Complexity has a tendency to bring about chaos. Due to the difficulty of people to understand the system(s). Incomplete visibility into what is happening. The number of possibilities within them, including both the normal events, mutability of the data, and the out of ordinary. That encompasses failures, people using the system(s) in unexpected ways, large spikes in requests, and bad actors.

    Did something get missed in publishing? The first half was really coherent. The second half is confusing.

    1. 1

      Thanks for the feedback and reading it again after a nights sleep I agree with you. I wanted to build on the comparison with other fields (one of which I worked in) to build up on the idea of applying the CRM training and some type independent review to start calling out trends.

      Obviously I hit git push too soon and I’ll rework the second half.