Update headings

app/(main)/blog/posts/a-tale-of-two-ideas/content.mdx

@@ -22,7 +22,7 @@ for them in the upcoming election. However, the decision rests with the voters
 who must decide which candidate's ideas most closely align with their own
 beliefs.
 
-## Forks in the Road
+## Forks in the road
 
 _The remainder of this article discusses an example of opposing ideas from my
 career in the software development industry. As such, many readers will not find
@@ -44,7 +44,7 @@ technique is best. While I do not intend on giving my own thoughts on the
 subject, I would like to share my thoughts about the two ideas as a way of
 demonstrating how to discern between differing viewpoints.
 
-## Zooming Out
+## Zooming out
 
 Once you have identified a set of opposing viewpoints, it is helpful to "zoom
 out" from the specifics and look at what high-level differences exist between
@@ -66,7 +66,7 @@ differences I identified were:
 - Overall testing methodology (testing pyramid vs testing trophy)
 - Definition of "implementation details"
 
-### Testing Methodology
+### Testing methodology
 
 One of the biggest differences between the two opinions on shallow rendering, as
 discussed in the aforementioned articles, is the overall testing methodology.
@@ -76,7 +76,7 @@ pyramid" where unit tests are favored over integration tests. This difference in
 how testing should be approached is a big reason why they differ on the idea of
 shallow rendering.
 
-### Implementation Details
+### Implementation details
 
 Another difference I noticed was the definition of "implementation details".
 While both Tim and Kent discuss implementation details, they use it to mean very
@@ -88,7 +88,7 @@ not be an implementation detail but instead a necessary part of the code. These
 difference perspectives on implementation details further explain why the two
 authors have very different thoughts on shallow rendering.
 
-## Making the Judgement Call
+## Making the judgement call
 
 So, the question you are probably asking yourself is "which approach is right?"
 However, this is not always the best question to ask. While it is often the case

app/(main)/blog/posts/auto-formatting-code-using-prettier-and-github-actions/content.mdx

@@ -26,7 +26,7 @@ there are a number of challenges with this approach.
    additional time when committing files due to Prettier having to format each
    file that is staged.
 
-## Finding a Better Way
+## Finding a better way
 
 Recently, a few of my coworkers implemented a tool called
 [Spotless](https://github.com/diffplug/spotless) into a number of projects to

app/(main)/blog/posts/automated-npm-publishing-using-github-actions/content.mdx

@@ -17,7 +17,7 @@ from my local development machine. In this article, I'll go through some basic
 jobs that you can run using GitHub Actions to simplify the process of publishing
 npm packages.
 
-## Basic Publish Action
+## Basic publish action
 
 To get our feet wet with publishing npm packages using GitHub Actions, let's
 start by creating a simple action that will publish to npm when we push a new
@@ -55,7 +55,7 @@ which is required for authenticating with npm to publish the package. The
 example above uses GitHub secrets for storing the token which can be generated
 in your npm profile.
 
-## Publishing A Release
+## Publishing a release
 
 To publish a release with our new action, we can run `yarn publish` or
 `npm publish` to increment the package version in package.json and create a new
@@ -68,7 +68,7 @@ run the git push command every time we run our publish command. That script
 would look like this `"postversion": "git push && git push --tags"` and should
 be places in the `scripts` section of your package.json_
 
-## Creating GitHub Releases
+## Creating GitHub releases
 
 Now that we have the basic publish action created, we can improve it so it will
 automatically create a GitHub release with change notes pulled automatically
@@ -92,7 +92,7 @@ so the custom action can authenticate with GitHub to create the release and
 upload the change notes. The value of this is the `GITHUB_TOKEN` secret that is
 [automatically available inside all GitHub actions](https://docs.github.com/en/actions/security-guides/automatic-token-authentication).
 
-## Running Tests
+## Running tests
 
 While the above examples work great for simple packages where you just need to
 publish and create a release, most packages will probably have a suite of tests
@@ -139,7 +139,7 @@ needs: test
 if: startsWith(github.ref, 'refs/tags/')
 ```
 
-## Putting It All together
+## Putting it all together
 
 Putting all three of these pieces together, our final action would look like
 this. In some cases, you may not need all three of the jobs so you can easily
@@ -186,7 +186,7 @@ jobs:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 ```
 
-## Bonus: GitHub Actions Badge
+## Bonus: GitHub Actions badge
 
 Once you get your actions working, you may wish to add a status badge to your
 readme to show if the build is passing or failing. GitHub Actions have builtin

app/(main)/blog/posts/conquering-derived-state/content.mdx

@@ -24,7 +24,7 @@ which does a great job of explaining why derived state is an anti-pattern. The
 focus of this article will be about how to recognize derived state in your
 components and several alternatives to derived state.
 
-## Recognizing Derived State
+## Recognizing derived state
 
 Before I go any further, let me provide a few examples of derived state to help
 you start recognizing derived state patterns. I'll begin with class based
@@ -119,7 +119,7 @@ showed above and suffers from the exact same problems. Just because it is
 written with hooks doesn't mean it is magically better than its class based
 equivalent!
 
-## Alternatives to Derived State
+## Alternatives to derived state
 
 Now that we've seen a few examples of derived state, let's look at some
 alternative solutions.

app/(main)/blog/posts/introducing-bytes/content.mdx

@@ -31,7 +31,7 @@ day. This might include such topics as:
 - How to use Git more effectively
 - And much more!
 
-## Small Learning Moments
+## Small learning moments
 
 The idea of small learning moments is part of my overall philosophy on how to
 improve as a software engineer. Many software engineers will face the same
@@ -56,7 +56,7 @@ would love to say about this, but it's best left to a dedicated post I plan on
 writing in the future. For now, let's move on and talk a bit more about Bytes,
 and how I built it!
 
-## The Tech Stack
+## The tech stack
 
 My website is built using [Next.js](https://nextjs.org) using the
 [App Router](https://nextjs.org/docs/app/building-your-application/routing) that
@@ -109,7 +109,7 @@ worry about database backups or anything, if for some reason I nuke the database
 I can just run my `pnpm db:reindex` script which will pull all the content fresh
 from the bytes repo and add it to the database.
 
-## More to Come
+## More to come
 
 I'm super excited to launch bytes today and start this journey with you all!
 While there are only a few bytes published so far, expect many more to come in

app/(main)/blog/posts/my-experience-changing-my-github-username/content.mdx

@@ -19,7 +19,7 @@ me. However, some initial research into changing my GitHub username got me
 pretty frightened and I seriously questioned if it was worth it. Nevertheless,
 the desire to change my username remained and I eventually decided to do it.
 
-## Determining the Impact
+## Determining the impact
 
 The first important step in changing my username was determining what the impact
 of changing it would be. While
@@ -41,7 +41,7 @@ articles did not apply to me. In the end, the changes I was
 - Travis CI
 - Git config files
 
-## Taking the Plunge
+## Taking the plunge
 
 Once I was reasonably confident of the impact, I decided to take the plunge and
 rename my account. I had already secured my new username and had created a
@@ -84,7 +84,7 @@ but if you use another Unix-based OS, your mileage may vary._
 sed -i '' -e 's/markypython/mskelton/' dotfiles/.git/config
 ```
 
-## Squatting Your Old Username
+## Squatting your old username
 
 When you rename your account, GitHub will setup redirects from your old username
 to your new username, but if someone takes over your new username and creates a
@@ -101,7 +101,7 @@ Because of this policy, I would recommend squatting your old username for a
 month or two and then deleting your old account so it is available for other
 users in the future.
 
-## Wrapping It Up
+## Wrapping it up
 
 Aside from the decision to start the processing of renaming my account at 9:30
 PM on a Friday night, I am very happy that I decided to rename my account as it

app/(main)/blog/posts/my-journey-to-become-a-staff-software-engineer/content.mdx

@@ -28,7 +28,7 @@ spent as a software engineer.
 1. [Embrace your team's norms](#embrace-your-teams-norms)
 1. [Challenge the Status Quo](#challenge-the-status-quo)
 
-## Try Things Out
+## Try things out
 
 One of the best ways to learn something is just trying it out to see what you
 learn. So much of what I have learned is a result of experimenting with new
@@ -40,7 +40,7 @@ projects and never completed them because completing them wasn't the point,
 rather I was having fun trying new approaches to problems that I've solved many
 times to see if I can find a better way.
 
-## Read Documentation
+## Read documentation
 
 It often shocks me how often I see engineers asking questions or failing to
 understand concepts when there are so many amazing sources of documentation that
@@ -56,7 +56,7 @@ to read one page of documentation (or 5 minutes worth) every workday. Five
 minutes is such a small commitment, but you'd be surprised how much
 documentation you can read in a year when you do it every day!
 
-## Get Good at Google
+## Get good at Google
 
 This might sound silly, especially when many companies (including mine) don't
 allow using Google during coding interviews, but learning how to research
@@ -82,7 +82,7 @@ more experienced engineer. Eventually, when you become the senior engineer,
 people will be asking you questions and you may no longer have a more senior
 engineer to lean on, so practice these skills now!
 
-## Teach What You Learn
+## Teach what you learn
 
 As you learn and grow as a software engineer, one of the best ways to reinforce
 and deepen your knowledge is by teaching others what you have learned. This is
@@ -101,7 +101,7 @@ efficient process on a Zoom call. These methods of teaching require far less
 preparation while still resulting in deepening your knowledge and helping your
 coworkers to also improve their skills.
 
-## Relentlessly Improve Efficiency
+## Relentlessly improve efficiency
 
 As you advance to higher levels of software engineering, you will solve more
 complex problems that require more time and mental energy. As you do, you will
@@ -138,7 +138,7 @@ section huge, here are some of my top tips.
   offer means of customizing with extensions or workflows to automate common
   tasks.
 
-## Chase Your Passion
+## Chase your passion
 
 The world of software engineering is vast and varied. You can dive into
 low-level programming with Rust and C, data science with Python and R, web
@@ -155,7 +155,7 @@ that pays the most, find what you love doing, and do that. If possible, use time
 outside of work to build side projects either to explore new technologies or
 deepen your knowledge of existing technologies you use.
 
-## Stay Humble
+## Stay humble
 
 The more experience you get as a software engineer, the easier it will become to
 be prideful of your knowledge, position, experience, salary, you name it. Fight
@@ -168,7 +168,7 @@ remember that not only do you have much to learn but also that every one of your
 coworkers, regardless of seniority, can teach you something, you will unlock the
 door to continued growth and learning.
 
-## Embrace Your Team's Norms
+## Embrace your team's norms
 
 Since starting at Widen 3 years ago, I have moved around to different teams
 quite a bit. During some of the earlier transitions, I had a tendency to come to
@@ -188,7 +188,7 @@ your team. Not only that, but often you will find that some of the things that
 were so important when you first joined might not be as important as you think
 after spending a little time on your new team.
 
-## Challenge the Status Quo
+## Challenge the status quo
 
 The final lesson I'll share in this article is to challenge the status quo.
 Being a highly effective software engineer involves challenging processes and

app/(main)/blog/posts/the-dangers-of-shallow-rendering/content.mdx

@@ -25,7 +25,7 @@ see, you won't be forced to read any more. 🙂
 1. Shallow rendering decreases confidence.
 1. Shallow rendering complicates refactoring.
 
-## Shallow Rendering Creates Additional Failure Points
+## Shallow rendering creates additional failure points
 
 What is the purpose of shallow rendering in the first place? According to the
 [Enzyme docs](https://enzymejs.github.io/enzyme/docs/api/shallow.html),
@@ -51,7 +51,7 @@ using the highest level component. In addition to testing the components, this
 will verify that your components are properly integrated removing that
 additional point of failure.
 
-## Shallow Rendering Decreases Confidence
+## Shallow rendering decreases confidence
 
 When developing web applications, the end result is some form of user value.
 Whether that is a visual or functional improvement, every change that is made
@@ -74,7 +74,7 @@ won't spend as much time fixing false positives/negatives, you will have more
 time to test known edge cases and perform exploratory testing to find other edge
 cases.
 
-## Shallow Rendering Complicates Refactoring
+## Shallow rendering complicates refactoring
 
 Refactoring is a necessary part of software development and often occurs many
 times during the lifetime of an application. When refactoring code, you should
@@ -94,7 +94,7 @@ Since I used shallow rendering, my test breaks since it was expecting to find a
 don't give me confidence that the changes to the components maintained the
 expected user behavior.
 
-## A Better Way
+## A better way
 
 If you are convinced that shallow rendering is not a good testing practice, the
 next big question is what to do instead? While there are many ways to answer

app/(main)/blog/posts/using-yarn-constraints/content.mdx

@@ -14,7 +14,7 @@ or all workspaces in a project. While constraints are still experimental and
 community examples of using them are a bit sparse, they are a very powerful tool
 to help you more easily manage your project.
 
-## What Are Yarn Constraints?
+## What are Yarn constraints?
 
 As previously mentioned,
 [Yarn constraints](https://yarnpkg.com/features/constraints) allow you to
@@ -24,7 +24,7 @@ when used on projects with multiple workspaces such as a component library.
 Constraints are written in Prolog which, although it has a learning curve,
 allows writing powerful rules in just a few short lines.
 
-## Let's See An Example
+## Let's see an example
 
 Alright, let's get down to business and look at an example of a constraint. For
 the rest of this article, let's assume that we are working on an open-source
@@ -73,7 +73,7 @@ Now that we've seen what Yarn constraints look like and how to check/fix them,
 let's look at a number of real world use cases where you might want to use
 constraints to enforce rules for your workspaces.
 
-## Use Case: Enforce Homepage URL
+## Use case: Enforce homepage URL
 
 Continuing with our hypothetical component library, we probably want to include
 a `homepage` field in the manifest of each workspace so that users can use the
@@ -182,7 +182,7 @@ $ yarn constraints
 
 _This constraint is also auto-fixable when you run `yarn constraints --fix`._
 
-## Use Case: Ensuring a Dependency Is a Peer Dependency
+## Use case: Ensuring a dependency is a peer dependency
 
 So, we've been using the example of a component library to demonstrate
 constraints, so let's extend the example to say that we are building a React
@@ -212,7 +212,7 @@ $ yarn constraints
 As we can see in the message, our newly created constraint prevents us from
 using `react` as a regular dependency.
 
-## Wrapping It Up
+## Wrapping it up
 
 That was a lot for a single article! I hope this article has helped you to
 understand what constraints are, when you might want to use them, and how to

app/(main)/blog/posts/why-i-dont-use-environment-variables/content.mdx

@@ -15,7 +15,7 @@ have some challenges which can cause some issues in certain scenarios. In this
 article, I'll explore some of those challenges and explain why I don't use
 environment variables in my applications.
 
-## Globally Available
+## Globally available
 
 The first challenge with environment variables is the fact that they are
 globally available to all applications. The main problem this can cause is
@@ -26,22 +26,22 @@ conflict between the two applications. This might seem like a contrived example
 but it is actually one that I have faced at my job and it has caused some
 serious annoyances.
 
-## Shell Specific
+## Shell specific
 
 Another challenge with environment variables is that they are only available in
 the shell which you have configured them for. Again, this might not seem like a
 big deal, but if you have to switch between shells on occasion this can be a
 real pain as the variables are not shared by both shells and must be maintained
 in each shell.
 
-## Difficult To Find
+## Difficult to find
 
 Because environment variables are configured in a file such as `~/.bashrc` it is
 harder to determine the value of each environment variable quickly. Although an
 minor inconvenience, it still adds to the list of challenges with environment
 variables.
 
-## My Solution
+## My solution
 
 My solution to this is to use `.env` files to store environment variables on a
 per-application basis. These files are not shell specific and they work across
@@ -58,7 +58,7 @@ so as to not override existing system environment variables unless explicitly
 requested. This behavior allows you to still specific environment variables on a
 per-command basis when running commands in your shell.
 
-## Should I Switch To `.env`?
+## Should I switch to `.env`?
 
 If you aren't having any issues with environment variables, I wouldn't recommend
 switching to `.env` just because it sounds neat. If however you have encountered