diff --git a/_posts/2023-07-07-delete-your-code.md b/_posts/2023-07-07-delete-your-code.md
new file mode 100644
index 0000000..04c1c6d
--- /dev/null
+++ b/_posts/2023-07-07-delete-your-code.md
@@ -0,0 +1,31 @@
+---
+layout: post
+title: Delete your code
+date: 2023-07-07 13:20 -0400
+---
+One of the most consistent things I have observed over the last two decades
+while working with software engineering teams is an unwillingness to delete
+code.  Functions and files left long after they have been replaced.  Hundred
+line blocks of commented code held on to for years.  Single purpose tasks kept
+in place just in case.  We developers are always planning for the worst.
+
+Don't get me wrong. I have lived the same life.  Leaving around treasure troves
+of code I had carefully crafted just incase I needed it in the future. But what
+if the worst thing that could happen is that we have given ourselves more code
+to maintain.  Or that we have left behind an outdated trail to follow that
+influences are decisions despite drastically changed requirements.  Or that the
+dead code becomes a ticking time-bomb of likely untested code waiting to
+accidentally be interpretted.
+
+Code is only an asset when it is directly providing the required functionality.
+Anything beyond that is a liability.  Even if it is never run in production,
+it still needs to be maintained.  It needs to be reviewed and updated when
+deprecations pop up, revisited when its automated tests start failing, or
+breakfixed when it somehow halts the application boot cycle.  Every line that
+is not executed is maintenance cost waiting to be incurred that provides no
+value.
+
+These days, I aggressively delete lines of my code bases as much as the teams I
+work with allow for.  I strive for PRs that have more deletions than additions.
+And if I ever really need that deleted piece of code?  That is what version
+control is for.