chore: fix some typos in markdown file

ideology-and-subjectivity.md

@@ -29,7 +29,7 @@ can be broken down into iterative smaller changes.
 
 It is ok to develop a large feature branch with broad sweeping API changes, but
 it will need to be broken down into smaller pieces that maintain backwards
-compatability in order to be merged.
+compatibility in order to be merged.
 
 
 ## Community Support

mutability.md

@@ -24,7 +24,7 @@ way?
 
 The answer has two parts.
 
-First, *internally* by being disciplined, we can avoid entire classes of bugs that *can* arrise inadvertantly due to the use of mutability.  While the example above doesn't have any immediate issues related to mutability, it isn't unreasonable to imagine a refactor to the function above which ends up introducing a bug due to the use of mutability.
+First, *internally* by being disciplined, we can avoid entire classes of bugs that *can* arrise inadvertently due to the use of mutability.  While the example above doesn't have any immediate issues related to mutability, it isn't unreasonable to imagine a refactor to the function above which ends up introducing a bug due to the use of mutability.
 
 Second, *externally* we want to set an easy to follow example.  We have plenty
 of 3rd party contributors and they take cues on how to write new code based on
@@ -50,7 +50,7 @@ Anytime you have an explicit reason to do so.  Some good reasons are:
 ## Types of multability and how to avoid it.
 
 
-### Programatic generation of various collection data structures
+### Programmatic generation of various collection data structures
 
 The use of lists
 
@@ -64,7 +64,7 @@ def get_things(all_items):
 ```
 
 We use `tuple` in place of lists and generators or comprehensions in place of
-`list.append` for programatic consprogramatic.
+`list.append` for programmatic consprogramatic.
 
 
 ```python

naming-things.md

@@ -39,7 +39,7 @@ for key, value in thing.items():
 ### Confusing Plurals
 
 For short names, the simple plural form *can* be ok but if often visually
-confusing, making it easy to inadvertantly swap one of the variables for
+confusing, making it easy to inadvertently swap one of the variables for
 another.
 
 ```python

opsec.md

@@ -11,7 +11,7 @@ The following minimum security practices should be used.
     accounts against hijacking.  In some cases, simply knowing someone's mobile
     number and appearing in person at one of their carrier's stores is enough
     to hijack their account.  Accounts can also be socially hacked by knowing
-    the mobile number in addition to a few publically available details of the
+    the mobile number in addition to a few publicly available details of the
     account holder's life which are commonly used in account recovery processes
     (father's middle name, mother's maiden name, model of first car, etc.).
 - Setup auto-signing of your git commits

style-guide.md

@@ -394,7 +394,7 @@ result = (
 
 ### Comprehensions
 
-When a list/dict/etc comprehension exceeds the 100 character line lenght it
+When a list/dict/etc comprehension exceeds the 100 character line length it
 **should** be split across multiple lines with the `statement/for/in/if`
 each on their own lines.
 

testing.md

@@ -104,7 +104,7 @@ def foo(bar):
     return quux
 ```
 
-We have a function `foo` that computes a value based on an input `bar` by executing an auxillary routine for some number of rounds `ROUND_COUNT`. To test the auxillary routine (here the body of the `for` loop), we can extract it from `foo`.
+We have a function `foo` that computes a value based on an input `bar` by executing an auxiliary routine for some number of rounds `ROUND_COUNT`. To test the auxillary routine (here the body of the `for` loop), we can extract it from `foo`.
 
 ```python
 def _compute_quux(baz, i):
@@ -144,7 +144,7 @@ Mocks **can** be ok when all other options are exhausted, or it is the pragmatic
 
 ### But maybe don't mock things
 
-A recurring pattern in our projects is a Backend Pattern, where you can swap in providers of functionality. Instead of mocking things that the code wasn't designed to do, try implementing the Backend Pattern, and swap in a dummy backend to stub out responses as fixtures. This provides most of the benefits of mocking, without sidestepping big swaths of code. You have more confidence that the majority of the feature was tested with the dummy backend. Then when you need to test a "live" backend, you can add use a few, targetted tests.
+A recurring pattern in our projects is a Backend Pattern, where you can swap in providers of functionality. Instead of mocking things that the code wasn't designed to do, try implementing the Backend Pattern, and swap in a dummy backend to stub out responses as fixtures. This provides most of the benefits of mocking, without sidestepping big swaths of code. You have more confidence that the majority of the feature was tested with the dummy backend. Then when you need to test a "live" backend, you can add use a few, targeted tests.
 
 ## Tips and Tricks