Add 'drafts/adding-value.php'cgi

1 files changed, 53 insertions, 0 deletions

diff --git a/drafts/adding-value.php b/drafts/adding-value.php
new file mode 100644
index 0000000..bc496cf
--- /dev/null
+++ b/drafts/adding-value.php
@@ -0,0 +1,53 @@
+Outline
+
+- write software to do one thing and do it well
+
+  - prefer general-purpose, reusable solutions to complex one-offs
+  - see: the UNIX philosophy
+  - probably also prefer that the software does a small thing
+
+- invest time into researching, learning, and knowledge-sharing
+- spend time on simpler projects with short time to added value vs complex ones
+  with long time to added value
+
+  - as the team's experience and expertise grows with a larger toolset, those
+    complex problems become simpler
+
+- using existing work to leverage new projects adds value
+  - existing impls reused with new automation reduces manual labor in new fields
+- look for "wins" that use what we already know
+  - extend existing functionality exposed to users into self-service portals to
+    push ticket time back onto business units
+- additional expose leads to new expertise and better results
+
+- engineering expertise + programming ability + use-case insight = added value
+  in the form of sustainable, extensible, and reusable software
+
+# Successful and Effective Enterprise Automation (for non-programmers, or managers of programmers)
+
+I am a software engineer at a three-letter company. I work primarily as a
+developer working on "enterprise automation". My clients are architects,
+operators, and systems administrators who are frequently performing repetitive,
+time-consuming, or laborious manual tasks. My job is to take those tasks, define
+a standardized process for them (if none exist), and write software to carry out
+those tasks with little to no human interaction. To do this, the software my
+team and I build needs to work quickly, correctly, and efficiently. Some of the
+projects I have been a part of have been more successful than others. Here are
+some of the lessons learned working on these projects these past three years.
+
+## Use-Case Insight
+
+Early on we received requests for projects or features that solved one problem
+for one or a few people. We would take their request, build a solution to carry
+out the task as quickly as possible, and then hand it off to the user. Maybe it
+got used occasionally, maybe it didn't. Projects like these probably weren't
+worth the time in research and development that it took to build them. Pet
+projects or "would be nice to have" projects are dangerous that way, because the
+benefit (or _value_) that they provide doesn't justify the cost to create them.
+One of the first larger projects our team worked on was more successful because
+we were able to gather a collection of use-cases and build something
+general-purpose to solve many problems instead of just one.
+
+Our company has call centers. Those call centers record their calls for business
+reasons. Let's say the software we use to manage those call recordings is called
+Calamity.