traditional code, so to speak, but the
process has become much more automated.
In the future these smatterings of
command-line snippets will be combined into one big program that automates the entire process. This tool
will be used as the basis for a Web-based self-service portal. This will allow users to do the task on demand,
seven days a week, even when the sysadmins are asleep.
Meanwhile, the other engineer, the
one who was “too busy to write code,”
is no closer to getting started.
The difference between these two
engineers is that one is willing to do
work manually just to get the task
done. The other is willing to do work
tions and augmented the command-
line snippets he had recorded.
As he repeated this process over
and over, the document evolved to be
much better. The example names and
numbers in the command lines were
replaced by variables. Ambiguous
statements such as “make sure everything is OK” were replaced by checklists of things to be tested, which were
soon augmented by commands that
performed the tests.
Soon this manual process was feel-
ing more and more like real automa-
tion. There was less thinking, more
following orders. Doing the process
“manually” was more like copying
and pasting command-line snippets
from the document and pasting them
in his terminal window. I call this Pas-
By doing this in the open, with collaborative document systems such as
a wiki or Git repository, coworkers are
able to join in: Mary fixes a command
line that broke on a certain class of
machine. Joe does some Web searches and soon a step that previously required a mouse click is replaced by a
As more and more coworkers adopt
this work style, the entire team contributes to the constant goal of better
This engineer, who began with
the same time pressure and other
obstacles as the other less successful engineer, has not yet written any