No one ever wants to go back and look at their old code. If you’re worth anything as an engineer, it means you’re always learning, always improving, and writing progressively better code as you learn and improve.
Often it’s easier to just start over than go back and refactor, so if a chunk of code isn’t actually broken, we leave it alone.
Most of my early patches were rejected from core based on abysmal standards adherence. I’d write a patch following documented WordPress standards, only to have it rejected because it didn’t fit within the legacy class or set of functions I was patching. I’d write another patch following the standards and style implied by the code in the file I was patching, only to have it rejected because it didn’t follow documented standards.
The discrepancy made it very difficult for me to understand what was going on. My first year or so of contributions to WordPress came in the form of forum threads and plugins because “doing it the WordPress way” was just too damn hard.
I pride myself now on working with some of the best WordPress engineers in the world. At 10up, our clients know they’re getting solid editorial projects backed by even more solid engineering. There’s some magic in that, but most of it is learned.
Over the past months, I’ve worked hard with a couple of other engineers at 10up to heavily document our engineering best practices – the tips and tools and workflows we use to pull together cutting-edge projects for our clients. We covered everything from version control to dependency management to language-specific coding patterns – and were able to shore up a lot of our own internal communication at the same time. 2
This document serves as a glimpse into how we do WordPress at 10up. It’s a fairly detailed set of documents that, like the code it influences, is constantly getting better as we continue to learn and improve. As a public document, it’s also open to collaboration – feel free to provide whatever feedback you think is necessary.
My hope is this document becomes a solid resource for the community. Hopefully the next developer can get started right away rather than spending a year learning the ropes on her own like I had to …
- Some of the things we pulled together in documentation was just assumed to be the standard by most, but was still a complete mystery to others. Making sure it’s all documented in one place is a great way to educate new engineers, as well as help established developers keep an eye on their craft. ↩