diff --git a/website/src/daily-emails/2022-11-20.md b/website/src/daily-emails/2022-11-20.md
new file mode 100644
index 00000000..4d88bbea
--- /dev/null
+++ b/website/src/daily-emails/2022-11-20.md
@@ -0,0 +1,25 @@
+---
+title: >
+  Version-controlled commented-out code
+pubDate: 2022-11-20
+permalink: >
+  archive/2022/11/20/version-controlled-commented-out-code
+tags:
+  - git
+---
+
+Today, whilst debugging some legacy code within an application, I found several blocks of commented-out code.
+
+Some were previous debugging code which had been commented out, and some were old components or previous implementations - but instead of being removed when they were no longer needed, they remained in the codebase as commented-out lines - inactive but adding noise and complexity around the code that I was trying to understand and debug.
+
+To make it easier for me to figure out this code, I'd like it to be as clean to read and as simple to understand as possible.
+
+The codebase is version-controlled, so why would there be a need to comment out and keep the lines?
+
+Version control systems have a log of each change, so if you need to see previous changes, you can view the log and see what changed, when, and by who.
+
+You can also see any other files that were changed in the same commit, and usually, there will be a reference to the issue or ticket that required that change.
+
+If you need to re-add a change that had been removed, you can either do this manually or by reverting the commit.
+ 
+Should there be commented-out code within a codebase if it's version controlled? I'd say no unless there's a good reason for it to be there and it's providing some additional context or for a specific purpose. If it's an outdated implementation, some old debugging code, or a component that's no longer needed, I think that it should be removed, and people can use version control tools to find or re-introduce those changes if needed.