I should use a spell checker

Author: Fidget-Spinner

_posts/2026-03-17-jit-on-track.md

@@ -23,7 +23,7 @@ The Faster CPython team lost its main sponsor in 2025. I immediately [raised the
 At the CPython core sprint in Cambridge, the JIT core team met, and we [wrote a plan]({{ site.baseurl }}/posts/faster-jit-plan.html) for a 5% faster JIT by 3.15 and a 10% faster JIT by 3.16, with free-threading support.
 A side note, which was less headline grabbing, but vital to the health of the project: was to **decrease the bus factor**. We wanted 2 active maintainers in all 3 stages of the JIT; frontend (region selector), middle-end (optimizer), backend (code generator).
 
-Previously, the JIT only had 2 active recurrent contributors middlde-end. Today, the JIT has 4 active recurrent contributors to the middle-end, and I would consider the 2 non-core developers (Hai Zhu and Reiden) capable and valued members.
+Previously, the JIT only had 2 active recurrent contributors middle-end. Today, the JIT has 4 active recurrent contributors to the middle-end, and I would consider the 2 non-core developers (Hai Zhu and Reiden) capable and valued members.
 
 What worked in attracting people were the usual software engineering practices: breaking complex problems down into manageable parts. Brandt started this earlier in 3.14, where he opened multiple [mega-issues](https://github.com/python/cpython/issues/131798) that split optimizing the JIT into simple tasks. E.g. we would say "try optimizing a single instruction in the JIT". I took Brandt's idea and did this for 3.15. Luckily, I had an easier job as my issue involved converting the interpreter instructions to an easily optimizeable form. To encourage new contributors, I also laid out [very detailed instructions](https://github.com/python/cpython/issues/134584) that were immediately actionable. I also clearly demarcated units of work. I suspect that did help, as we have 11 contributors (including me) working on that issue, converting nearly the whole of the interpreter to something more JIT-optimizer friendly. The core was that the JIT could be broken down from an opaque blob to something that a C programmer with no JIT experience could contribute to.