diff --git a/getting-started/mix-otp/ets.markdown b/getting-started/mix-otp/ets.markdown
index 140d2d394..f58d8f0e4 100644
--- a/getting-started/mix-otp/ets.markdown
+++ b/getting-started/mix-otp/ets.markdown
@@ -101,7 +101,7 @@ defmodule KV.Registry do
       {:ok, _pid} ->
         {:noreply, {names, refs}}
       :error ->
-        {:ok, pid} = KV.Bucket.Supervisor.start_bucket()
+        {:ok, pid} = KV.Bucket.Supervisor.start_bucket
         ref = Process.monitor(pid)
         refs = Map.put(refs, ref, name)
         :ets.insert(names, {name, pid})
@@ -192,7 +192,7 @@ To fix the failure we just need to make `KV.Registry.create/2` synchronous by us
       {:ok, pid} ->
         {:reply, pid, {names, refs}}
       :error ->
-        {:ok, pid} = KV.Bucket.Supervisor.start_bucket()
+        {:ok, pid} = KV.Bucket.Supervisor.start_bucket
         ref = Process.monitor(pid)
         refs = Map.put(refs, ref, name)
         :ets.insert(names, {name, pid})
diff --git a/getting-started/mix-otp/supervisor-and-application.markdown b/getting-started/mix-otp/supervisor-and-application.markdown
index 57266eda8..6954cc0c5 100644
--- a/getting-started/mix-otp/supervisor-and-application.markdown
+++ b/getting-started/mix-otp/supervisor-and-application.markdown
@@ -220,7 +220,7 @@ We have now successfully defined our supervisor which is automatically started (
 Remember however that our `KV.Registry` is both linking and monitoring bucket processes in the `handle_cast/2` callback:
 
 ```elixir
-{:ok, pid} = KV.Bucket.start_link()
+{:ok, pid} = KV.Bucket.start_link
 ref = Process.monitor(pid)
 ```
 
@@ -267,7 +267,7 @@ defmodule KV.Bucket.Supervisor do
   # A simple module attribute that stores the supervisor name
   @name KV.Bucket.Supervisor
 
-  def start_link() do
+  def start_link do
     Supervisor.start_link(__MODULE__, :ok, name: @name)
   end
 
@@ -296,7 +296,7 @@ Run `iex -S mix` so we can give our new supervisor a try:
 ```iex
 iex> {:ok, _} = KV.Bucket.Supervisor.start_link
 {:ok, #PID<0.70.0>}
-iex> {:ok, bucket} = KV.Bucket.Supervisor.start_bucket()
+iex> {:ok, bucket} = KV.Bucket.Supervisor.start_bucket
 {:ok, #PID<0.72.0>}
 iex> KV.Bucket.put(bucket, "eggs", 3)
 :ok
@@ -311,7 +311,7 @@ Let's change the registry to work with the buckets supervisor by rewriting how b
     if Map.has_key?(names, name) do
       {:noreply, {names, refs}}
     else
-      {:ok, pid} = KV.Bucket.Supervisor.start_bucket()
+      {:ok, pid} = KV.Bucket.Supervisor.start_bucket
       ref = Process.monitor(pid)
       refs = Map.put(refs, ref, name)
       names = Map.put(names, name, pid)
@@ -343,7 +343,7 @@ This time we have added a supervisor as child, starting it with no arguments. Re
 
 Since we have added more children to the supervisor, it is also important to evaluate if the `:one_for_one` strategy is still correct. One flaw that shows up right away is the relationship between registry and buckets supervisor. If the registry dies, the buckets supervisor must die too, because once the registry dies all information linking the bucket name to the bucket process is lost. If the buckets supervisor is kept alive, it would be impossible to reach those buckets.
 
-We should consider moving to another supervision strategy like `:one_for_all` or `:rest_for_one`. The `:one_for_all` strategy kills and restarts all children whenever one of the children die. This would suit our case but may be too harsh as there is no need to crash the registry once the bucket supervisor dies since the registry supervises every bucket and would be able to clean itself up. That's when the `:rest_for_one` strategy is handy: `:rest_for_one` will only restart the crashed process along side the rest of tree. Let's rewrite our supervision tree to use it:
+We should consider moving to another supervision strategy like `:one_for_all` or `:rest_for_one`. The `:one_for_all` strategy kills and restarts all children whenever one of the children die. This would suit our case but may be too harsh as there is no need to crash the registry once the bucket supervisor dies since the registry supervises every bucket and would be able to clean itself up. That's when the `:rest_for_one` strategy is handy: `:rest_for_one` will only restart the crashed process along side the rest of the tree. Let's rewrite our supervision tree to use it:
 
 ```elixir
   def init(:ok) do