spelling and cv and misc updates

Author: hazelweakly

src/_resume/cv.md

@@ -11,7 +11,7 @@ contact:
 
 Influential engineering leader and sought-after international keynote speaker;
 experienced in developer experience, observability, resilience, and distributed systems;
-with a focus on organizational change, holistic efficiency, and driving cross-functional business results in a sustainable manner.
+with a focus on organisational change, holistic efficiency, and driving cross-functional business results in a sustainable manner.
 
 :::
 
@@ -34,14 +34,14 @@ Due to the nature of this role, publicly provided details are scarce. Details ma
 
 Worked to build a next-generation compute and networking platform utilizing cutting edge technology.
 Acted as a subject matter expert to help validate and inform the implementation strategy for the project.
-Facilitated communications across teams and organizations, guiding prioritization of roadmaps.
+Facilitated communications across teams and organisations, guiding prioritization of roadmaps.
 
 :::
 
 ::: {.cv Title="Principal Architect - Platform" Company="[Datavant](https://datavant.com)" Date="Jan. 2024--Aug. 2024" Location="Seattle, WA, USA"}
 
 Developed, oversaw, and drove the technical vision for Platform Engineering and Infrastructure at Datavant.
-Executed on broad impact projects with high visibility, leveled up the technical excellence of the organization, accelerated timelines exponentially, and derisked key initiatives.
+Executed on broad impact projects with high visibility, leveled up the technical excellence of the organisation, accelerated timelines exponentially, and derisked key initiatives.
 
 - Architected the "Golden Path" of the company, building alignment around a strategy for reducing technical fatigue and accelerating development efforts.
 - Designed and executed the observability strategy, including incremental adoption, improvement, platform capabilities and end-user integrations.
@@ -69,7 +69,7 @@ Led the Platform Org in an explicitly interim capacity, focusing on preparing th
 
 - Built awareness around resource allocation needs for the Platform Org, leading to substantially re-allocating resources in order to right-size our infrastructure investment.
 - Built a data-driven and strategic process around identifying and allocating developer experience interventions, leading to substantial improvements to developer satisfaction and velocity.
-- Worked with Product Engineering, Security, and the CTO Leadership Team to build a narrative of cross-functional collaboration and trust, bringing about a significant improvement in the organization's alignment and messaging around Security and Platform.
+- Worked with Product Engineering, Security, and the CTO Leadership Team to build a narrative of cross-functional collaboration and trust, bringing about a significant improvement in the organisation's alignment and messaging around Security and Platform.
 
 :::
 

src/_talks/platform-engineering-day-kubecon-eu-2025--so-you-want-to-hire-for-platform-engineering/slides.md

@@ -37,7 +37,7 @@ We're covering:
 
 - The part of the hiring process engineering leaders have control over
 - One way to view the differences between Platform Engineers, Infrastructure, SREs, etc.
-- How to think about skills your organization needs
+- How to think about skills your organisation needs
 - Hazel's Opinions and Experiences (which have been very successful!)
 
 ::right::

src/_talks/qcon-san-francisco-2023--understanding-platforms-what-they-are-why-they-work-when-to-use-them-how-to-build-them/index.md

@@ -3,7 +3,7 @@ title: "Understanding Platforms: What They Are, Why They Work, When to Use Them,
 description: |
   Technical concepts are something that are thought of, approached, and understood differently across engineers, managers, and executives. Bridging the gaps and providing understanding to a complex and nuanced topic across all three groups can sometimes feel impossible. In this talk, we'll do just that.
 
-  Together, we're going to go over not just platforms and platform engineering, but the very fabric of doing, what it means to learn, and how collective thought scales across a team, an organization and an industry. Utilizing that, we'll go over platform engineering from the perspectives of an engineer, a manager, and an executive. All at the same time.
+  Together, we're going to go over not just platforms and platform engineering, but the very fabric of doing, what it means to learn, and how collective thought scales across a team, an organisation and an industry. Utilizing that, we'll go over platform engineering from the perspectives of an engineer, a manager, and an executive. All at the same time.
 
   Not only will we go over a consistent framework for how each group can think about and understand platform engineering, we'll spend time going over how each group can communicate with other and understand each other in a way that's effective, actionable, and transformative.
 author: Hazel Weakly
@@ -126,7 +126,7 @@ $$ \text{Motivation} + \text{Relationship} + \text{\bf{Context}} = \text{Action}
   ### Vertical
 
   - Specialized Knowledge
-  - Effective action in the organization
+  - Effective action in the organisation
   - Cognitive overhead required for doing
   - Utilizes consensus
 
@@ -136,7 +136,7 @@ $$ \text{Motivation} + \text{Relationship} + \text{\bf{Context}} = \text{Action}
   ### Horizontal
 
   - Collective Knowledge
-  - Effective learning in the organization
+  - Effective learning in the organisation
   - Cognitive overhead required for collaboration
   - Utilizes alignment
 
@@ -295,7 +295,7 @@ SRE
 : A specialist role in resilience engineering that naturally arises when horizontal context becomes too large for any one team
 
 Platform Engineering
-: An empathy-driven approach towards sociotechnical organizational design
+: An empathy-driven approach towards sociotechnical organisational design
 
 ## What is a Platform?
 
@@ -353,7 +353,7 @@ $$ \text{Motivation} + \text{Relationship} + \text{Context} = \text{Action} $$
 ### Vertical
 
 - Specialized Knowledge
-- Effective action in the organization
+- Effective action in the organisation
 - Cognitive overhead required for doing
 - Utilizes consensus
 
@@ -363,7 +363,7 @@ $$ \text{Motivation} + \text{Relationship} + \text{Context} = \text{Action} $$
 ### Horizontal
 
 - Collective Knowledge
-- Effective learning in the organization
+- Effective learning in the organisation
 - Cognitive overhead required for collaboration
 - Utilizes alignment
 
@@ -382,7 +382,7 @@ $$ \text{Motivation} + \text{Relationship} + \text{Context} = \text{Action} $$
 
 <div class="fragmented">
 
-If you "aren't" a matrix organization, but...
+If you "aren't" a matrix organisation, but...
 
 - You have teams that rotate projects
 - "Dynamic" or "rotating" teams are a thing
@@ -536,7 +536,7 @@ Exec
 
 ## When to Platform?
 
-Platforms make sense when the benefits of reducing horizontal context more than offset the overhead of adding a vertical to the organization.
+Platforms make sense when the benefits of reducing horizontal context more than offset the overhead of adding a vertical to the organisation.
 
 $$
 \displaylines{\text{\# verticals in platform's scope} \\ \times \\
@@ -633,7 +633,7 @@ Agglomeration-based development
   2. Look for duplication of workflows, interfaces, process, planning
   3. Compare results
 * ### Exec
-  1. Ask organizational leaders what their pain points are
+  1. Ask organisational leaders what their pain points are
   2. Look for duplications of language, vision, alignment efforts, programs
   3. Compare results
 
@@ -674,7 +674,7 @@ Exec
 
 ## A Platform Is An Abstraction That Platforms Like A Platform
 
-## Platform teams are organizationally empowered to address cross-cutting changes
+## Platform teams are organisationally empowered to address cross-cutting changes
 
 With a combination of technical, procedural, and cultural improvements
 

src/_talks/scale-22x-2025--redefining-observability-observability-3-0/slides.md

@@ -261,7 +261,7 @@ layout: quote
 zoom: 0.7
 ---
 
-# You’re paying what? 10-20% of your _entire_ infrastructure budget for something that 5% of the organization is going to use, 10% of that 5% are going to be actually deeply competent in, and 10% of that 10% are going to be an expert in.<br/>That’s the worst possible way to spend 20% of your budget.
+# You’re paying what? 10-20% of your _entire_ infrastructure budget for something that 5% of the organisation is going to use, 10% of that 5% are going to be actually deeply competent in, and 10% of that 10% are going to be an expert in.<br/>That’s the worst possible way to spend 20% of your budget.
 
 -- Hazel _"yes-i-actually-quote-myself_" Weakly
 

src/_talks/staffplus-ny-2025--coherent-impact-the-art-of-strategy/slides.md

@@ -30,7 +30,7 @@ defaults:
 # _Impact?_ **Impact**
 
 - Rewrote the entire hiring budget in one quarter
-- Grew Platform organization from 8 people to 40+ in two quarters
+- Grew Platform organisation from 8 people to 40+ in two quarters
 - Developer sentiment and productivity measurably improved
 - Rebuilt the entire infrastructure stack
 - FedRAMP rev 4 to rev 5

src/blog/beginner-mistakes-and-oddities-i-encountered.md

@@ -15,7 +15,7 @@ I had a lot of these; mostly due to my inexperience, but also GHC is a pretty ol
 Unfortunately it’s not really something where comprehensive documentation can easily be written down other than a general "best practices" approach (which I think I’ll write up).
 
 - GHC has a lot of submodules. Before working you should not only pull the master but you should also run `git submodule update`; I had quite a few issues early on with extraneous files in git status before I learned to do that.
-- Git notes is really not that ergonomic at all. If you have any namespaces used in your git notes (which this project does) you’ll need –ref=perf for damn near every command you use. It’s a small thing, but it can sometimes take a while to realize what you missed.
+- Git notes is really not that ergonomic at all. If you have any namespaces used in your git notes (which this project does) you’ll need –ref=perf for damn near every command you use. It’s a small thing, but it can sometimes take a while to realise what you missed.
 - Running the ./validate script is the only way to guarantee a clean anything. Switch a branch and something weird breaks? ./validate; Not quite sure why tests started failing after a git pull and a small innocuous code changes? ./validate. The real bummer here is that ./validate wipes everything and rebuilds the entire damn compiler and all that stuff from scratch and then runs the most extensive version of the testsuite. The exhaustive version of the testsuite alone can take nearly 2 hours on my computer if it’s not run threaded, so it’s definitely a huge time sink if you don’t have this thing optimized.
   - Related pain-point; there’s a lot of things you can do to tweak and fix your setup so that you can build and validate quicker. Unfortunately, this is all something that you just have to kind of learn over time and there’s no real way to intelligently "auto-configure" this nicely. You’ll have to suffer super long build times for GHC and long runtimes for the testsuite or sink quite a few hours into configuring the "quicker options" for your specific usecase.
   - Update: Thanks to a few helpful Reddit comments, I’m now aware that `dist/maintainer clean` instead of ./validate will help you out quite a bit. Unfortunately, this still doesn’t clean out everything.
@@ -41,7 +41,7 @@ Things I really needed and had to learn:
 ## Sanity checks
 
 Programmers need sanity checks for everything, especially when working in a language like python.
-I can’t begin to mention how many times I was working on something only to have everything break for hours before I realized I was implicitly assuming something that wasn’t accurate.
+I can’t begin to mention how many times I was working on something only to have everything break for hours before I realised I was implicitly assuming something that wasn’t accurate.
 Not all tests are performance tests, some tests involve measuring the compiler, some don’t, etc.
 Sanity checks don’t just involve the code, they also involve your environment as well;
 I’ve accidentally ran tests on the wrong commit, used the wrong flags, accidentally wasted 2 hours building the wrong version of a program...
@@ -102,7 +102,7 @@ This applies to everything in my life and it’s why making breakfast takes me a
 So these are just some of the things I’ve learned and struggled with while working on this project. I’d probably summarize this into a few key points:
 
 - Abstraction is the process of communicating more precisely about something. Use it whenever possible and helpful to make code more robust.
-- Be explicit about your assumptions and use implicit behavior as little as possible; ideally document that implicit behavior in a comment whenever you can.
+- Be explicit about your assumptions and use implicit behaviour as little as possible; ideally document that implicit behaviour in a comment whenever you can.
 - Be deliberate and methodical about your sanity checks; write them down so you can verify things consistently and thoroughly.
 - Do _one_ thing at a time, learn your git hygiene, and use it.
 - Write down your thought processes somewhere whenever you’re doing something more intensive than fixing an immediate, small issue.

src/blog/halfway-there.md

@@ -25,12 +25,12 @@ After that, things have been going increasingly swimmingly and I’m sure my men
 - Similarly, data from git notes can now be loaded into the test driver.
 - Finally, I’ve started working on some tooling to start comparing performance metrics across commits.
 
-This progress corresponds to, in my proposal, basically completing phase one. What remains now is still quite a bit, but the first big hurdle is done. The comparisons done right now in the test driver have basically not been modified much in any way; it was right around the point where I finished adding stuff into git notes that I realized we’re going to need a separate tool for sane performance metric comparison; so, I’ve done some preliminary work on that. Unfortunately, git notes are a bit tricky and not very ergonomic to work with so I’ll be working on making that as seamless as possible as well; ideally, nobody will ever need to touch them or even know they exist. Technically, at this point, the ticket for this project could probably be closed as
+This progress corresponds to, in my proposal, basically completing phase one. What remains now is still quite a bit, but the first big hurdle is done. The comparisons done right now in the test driver have basically not been modified much in any way; it was right around the point where I finished adding stuff into git notes that I realised we’re going to need a separate tool for sane performance metric comparison; so, I’ve done some preliminary work on that. Unfortunately, git notes are a bit tricky and not very ergonomic to work with so I’ll be working on making that as seamless as possible as well; ideally, nobody will ever need to touch them or even know they exist. Technically, at this point, the ticket for this project could probably be closed as
 "successfully completed", but it’d be a shame to do so without developing the tooling to help make using the performance test-suite as painless as possible.
 
 ## What now?
 
-At first, I was thinking that the next logical step towards working on the tooling and the project was going to be working on things like: Developing tooling to make sure that the right information is added to git notes, that the correct information is maintained and propagated into the future, into different branches, etc.,; and the auto builders will need some additional configuration in order to handle the git notes (git notes do not work very seamlessly). But then, with Ben’s help, I fleshed out the workflows a bit and realized that none of that really needs to happen if I just rip all of the performance metric comparison out of the test-driver. After that, things fell into place a bit more and the new plan is:
+At first, I was thinking that the next logical step towards working on the tooling and the project was going to be working on things like: Developing tooling to make sure that the right information is added to git notes, that the correct information is maintained and propagated into the future, into different branches, etc.,; and the auto builders will need some additional configuration in order to handle the git notes (git notes do not work very seamlessly). But then, with Ben’s help, I fleshed out the workflows a bit and realised that none of that really needs to happen if I just rip all of the performance metric comparison out of the test-driver. After that, things fell into place a bit more and the new plan is:
 
 - Create a "library" to import into the test-driver. It’ll contain a few tools:
   - Boolean "pass/fail" function to compare whether a test varies beyond a certain variance % between two commits (generally HEAD and HEAD~1).