diff --git a/content/blog/boolean_names.md b/content/blog/boolean_names.md
new file mode 100644
index 0000000..f587e65
--- /dev/null
+++ b/content/blog/boolean_names.md
@@ -0,0 +1,30 @@
+---
+img: /img/settings.png
+title: "Boolean Variable Names"
+author: Jeff Russo
+pdate: FILL_IN_DATE
+desc: Choosing a good boolean variable name
+---
+
+Choosing good names for variable is important.  They are a form of documentation and can remove [complexity](http://localhost:1313/blog/complexity/) from code.  Using a bad name for a variable leads to confusion, bugs, and wasted engineer time.  In this blog post I will discuss what makes a variable name good or bad, for [booleans](https://en.wikipedia.org/wiki/Boolean_data_type) in particular.
+
+## Purpose
+A boolean's purpose is to toggle between true and false.  Therefore, the name should represent something that is true or false. 
+
+## Good Boolean Names
+
+
+## Bad Boolean Names
+
+Variable names for booleans: avoid names that are already a negation (notReady, headless).
+
+find examples in OSS (Gitea notify)
+
+
+Read PoP and PoSD for bool blog post
+Use an unambiguously negatable name.  No context should be needed for understanding.  Ex: “FlexibleName”
+Going between configs is problematic. Ex: confA.UseProd = !confB.NoProd
+Should be in the affirmative (useProd, not noProd)
+
+
+answerable with yes or no (true or false)