sandfox

Collection of critiques on "root cause"

Overview

This document contains links and excerpts from literature that provide critique on the concept "root cause" an addition to how the term is used. These references are from authors across a wide variety of fields (such as safety science, sociology, psychology, linguistics, and others) as well as many different domains (such as aviation, medicine, software, military, power generation, and others).

On the concept

Dekker, S., Hollnagel, E., Woods, D., & Cook, R. (2008). Resilience Engineering: New directions for measuring and maintaining safety in complex systems. Lund University School of Aviation, 1, 1-6.

James Edward Butler – Developer and SRE

I am an experienced developer and SRE with over 13 years experience designing architecture for, building and running web, mobile and cloud-based large scale infrastructures. I write application features as well as infrastructure-centric tooling. I have worked as an individual contributor and led technical teams, and would consider doing either in the future

Employment History

Centrica / Hive - Senior Developer

May 17 - June 22

Designed, rolled out and maintained fully automated end 2 end CI/CD pipeline + production infra for rollout of new web-based customer dashboard (JS + React) and development of supporting public facing HTTP apis (NodeJS deployed on AWS Lambda).


	Readers who are interested in the actionable aspects of this topic should probably read the last instalment in this series: https://commoncog.com/blog/accelerated-expertise/

	The basic idea is this:

	1. Deliberate practice only works for skills with a history of good pedagogical development. If no such pedagogical development exists, you can’t do DP. Source: read Peak, or any of Ericsson’s original papers. Don’t read third party or popsci accounts of DP.

	2. Once you realise this, then the next question you should ask is how can you learn effectively in a skill domain where no good pedagogical development exists? Well, it turns out a) the US military wanted answers to exactly this question, and b) a good subsection of the expertise research community wondered exactly the same thing.

	3. The trick is this: use cognitive task analysis to extract tacit knowledge from the heads of existing experts. These experts built their expertise through trial and error and luck, not DP. But you can extract their knowledge a

	const { Transform } = require("stream");
	// Splits buffers on utf8 newline character
	// If the maxLineLength is passed the current line is discarded and all further input is discarded until the next newline char is found
	// TODO: emit errors on overlong lines?
	class NewlineStreamSplitter extends Transform {
	constructor(streamOpts, opts) {
	super(streamOpts);

	opts = opts \|\| {};

	const sample = rate => () => Math.random() > rate


	// creates a sampler
	const shouldDoThing = sample(0.5)

	// true or false
	const result = shouldDoThing()

	#! /usr/bin/env sh

	##
	# Notes:
	# Log line:
	# REPORT RequestId: f420d819-d07e-11e8-9ef2-4d8f649fd167 Duration: 158.15 ms Billed Duration: 200 ms Memory Size: 128 MB Max Memory Used: 38 MB
	# [ report_label="REPORT", ..., label="Used:", max_memory_used_value, unit="MB" ]
	#
	# Test the metric filter
	# aws logs test-metric-filter \

	#! /usr/bin/env sh

	# The hackiest of hacks
	# travis NPM deploy tool can only accept config via .travis.yml.
	# travis.yml only supports inline encrypted env vars up 128 cars in length.
	# env vars are supported in stuff thats gets fed to bash,
	# travis NPM deploy tool read directly from travis.yml
	# artifactory tokens are 900+ chars

	# Depends on ARTIFACTORY_TOKEN env var being set

	openssl base64 -e -A -in MY_FILE -out ANOTHER_FILE
	openssl base64 -d -A -in ANOTHER_FILE -out MY_FILE

	#!/bin/bash

	for i in "$@"
	do
	case $i in
	-e=\|--extension=)
	EXTENSION="${i#*=}"
	shift # past argument=value
	;;
	-s=\|--searchpath=)

	phases:
	install:
	commands:
	- . codebuild_nvm_wrapper.sh
	- npm install
	- node -v