diff --git a/docs/chart_template_guide/named_templates.md b/docs/chart_template_guide/named_templates.md
index daea98b19..1dc9c7618 100644
--- a/docs/chart_template_guide/named_templates.md
+++ b/docs/chart_template_guide/named_templates.md
@@ -170,87 +170,6 @@ metadata:
 
 Now `{{ .Chart.Name }}` resolves to `mychart`, and `{{ .Chart.Version }}` resolves to `0.1.0`.
 
-## Creating override-able sections with `block`
-
-Say we want to create a template in our `_helpers.tpl` file, but then override part of its behavior in our template. This is what blocks are for. Sometimes we don't want to just insert a template with `template`, but we want to sketch out a default and let another template override our default. This makes it possible for one chart to define a base template, but allow another chart to strategically override some of its behavior.
-
-Blocks are declared like this:
-
-```yaml
-{{ block "NAME" PIPELINE }}
-{{ end }}
-```
-
-Here, "NAME" is the name that a `define` block can use to override it, and PIPELINE is the pipeline that will set the scope. So let's rewrite our `labels:` section to use this strategy. We'll create a basic labels section in our `_helpers.tpl` file, but add some extra labels in the `configmap.yaml` template.
-
-Let's start with `_helpers.tpl`:
-
-```yaml
-{{- define "my_labels" }}
-  labels:
-    chart: {{ .Chart.Name }}
-    version: {{ .Chart.Version }}
-    {{ block "my_extra_labels" . }}extras: false{{ end }}
-{{- end }}
-```
-
-Inside of our `my_labels` template, we now declare a block called `my_extra_labels`. By default, this section will have one extra label: `extras: false`. If we were to execute this using the same `configmap.yaml` file from last time, we'd get this:
-
-```yaml
-# Source: mychart/templates/configmap.yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: tinseled-womba-configmap
-  labels:
-    chart: mychart
-    version: 0.1.0
-    extras: false
-data:
-  myvalue: "Hello World"
-  drink: "coffee"
-  food: "pizza"
-```
-
-But inside of our `configmap.yaml` template, we can override `my_extra_labels`:
-
-```yaml
-{{- define "my_extra_labels" }}chart: {{ .Chart.Name }}{{ end -}}
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: {{ .Release.Name }}-configmap
-  {{- template "my_labels" . }}
-data:
-  myvalue: "Hello World"
-  {{- range $key, $val := .Values.favorite }}
-  {{ $key }}: {{ $val | quote }}
-  {{- end }}
-```
-
-On the first line, we redefine `my_extra_labels` to include `chart: {{ .Chart.Name }}`. If we
-run this, we will get:
-
-```yaml
-# Source: mychart/templates/configmap.yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: ignorant-scorp-configmap
-  labels:
-    chart: mychart
-    version: 0.1.0
-    chart: mychart
-data:
-  myvalue: "Hello World"
-  drink: "coffee"
-  food: "pizza"
-```
-
-Gone is the `extras: false` section, since that part of the template is now overridden by our new template, which placed `chart: mychart` into the output.
-
-Blocks are not frequently used in Helm charts. But they do provide one mechanism for creating "abstract" charts, and then selectively overriding parts of the abstract template with concrete implementations.
-
 ## The `include` function
 
 Say we've defined a simple template that looks like this:
diff --git a/docs/chart_template_guide/subcharts_and_globals.md b/docs/chart_template_guide/subcharts_and_globals.md
index 69d828c11..26e9a60cb 100644
--- a/docs/chart_template_guide/subcharts_and_globals.md
+++ b/docs/chart_template_guide/subcharts_and_globals.md
@@ -175,57 +175,33 @@ Globals are useful for passing information like this, though it does take some p
 
 ## Sharing Templates with Subcharts
 
-Parent charts and subcharts can share templates. This can become very powerful when coupled with `block`s. For example, we can define a `block` in the `subchart` ConfigMap like this:
+Parent charts and subcharts can share templates. Any defined block in any chart is
+available to other charts.
 
-```yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: {{ .Release.Name }}-cfgmap2
-  {{block "labels" . }}from: mysubchart{{ end }}
-data:
-  dessert: {{ .Values.dessert }}
-  salad: {{ .Values.global.salad }}
-```
-
-Running this would produce:
-
-```yaml
-# Source: mychart/charts/mysubchart/templates/configmap.yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: gaudy-mastiff-cfgmap2
-  from: mysubchart
-data:
-  dessert: ice cream
-  salad: caesar
-```
-
-Note that the `from:` line says `mysubchart`. In a previous section, we created `mychart/templates/_helpers.tpl`. Let's define a new named template there called `labels` to match the declaration on the block above.
+For example, we can define a simple template like this:
 
 ```yaml
 {{- define "labels" }}from: mychart{{ end }}
 ```
 
-Recall how the labels on templates are _globally shared_. That means that if we create a block named `labels` in one chart, and then define an override named `labels` in another chart, the override will be applied.
+Recall how the labels on templates are _globally shared_. Thus, the `labels` chart
+can be included from any other chart.
 
-Now if we do a `helm install --dry-run --debug mychart`, it will override the block:
+While chart developers have a choice between `include` and `template`, one advantage
+of using `include` is that `include` can dynamically reference templates:
 
 ```yaml
-# Source: mychart/charts/mysubchart/templates/configmap.yaml
-apiVersion: v1
-kind: ConfigMap
-metadata:
-  name: nasal-cheetah-cfgmap2
-  from: mychart
-data:
-  dessert: ice cream
-  salad: caesar
+{{ include $mytemplate }}
 ```
 
-Now `from:` is set to `mychart` because the block was overridden.
+The above will dereference `$mytemplate`. The `template` function, in contrast,
+will only accept a string literal.
+
+## Avoid Using Blocks
 
-Using this method, you can write flexible "base" charts that can be added as subcharts to many different charts, and which will support selective overriding using blocks.
+The Go template language provides a `block` keyword that allows developers to provide
+a default implementation which is overridden later. In Helm charts, blocks are not
+the best tool for overriding because it if multiple implementations of the same block
+are provided, the one selected is unpredictable.
 
-This section of the guide has focused on subcharts. We've seen how to inherit values, how to use global values, and how to override templates with blocks. In the next section we will turn to debugging, and learn how to catch errors in templates.
+The suggestion is to instead use `include`.