There was a time when I really wanted to work for 10up, not to be confused with the time they wanted me to work for them. Before I interviewed with their president and founder Jake Goldman, I did as much research on him as I could on him.
That’s a good pre-job interviewing strategy. It didn’t work for me then, but I learned some really useful stuff from reading up on Jake and looking through his WordCamp presentations.
My point here is not to present some theory on getting jobs that is likely full of shit. I hear 10up is hiring and if you want to work for them, awesome. I don’t have any advice besides contribute to open source projects as much as possible. Actually, that’s my advice on getting any job in the WordPress ecosystem.
One of the best pieces of advice I got from reading up on Jake was that when you don’t know how to do something, you should read the source code, before you go to the codex. This is one of the most useful bits of advice I’ve ever gotten and I repeat it all the time.
Why You Must Use The Source
Since you do all of your development locally — you do right? — you probably have like 14 copies of WordPress on your computer. WordPress is super well documented inline and the code is designed to be readable. There is a lot of abstraction that could be done in WordPress core that would come at the expense of readability that I am happy has not been done.
I’m not here to knock the Codex, or the code reference at https://developer.wordpress.org/reference/. They are both great resources, and I use them.
What you can only get from reading the source is an understanding of how something works. The documentation is a reflection of what it does, or should do. The source, along with a quality inline debugger tells you what is happening — you are using xdebug right? And along the way, you will learn a ton about development patterns by reading the source.
It also means that if your usage of the function/ method/ hook, etc. doesn’t work as intended, you are in the exact right spot to start asking why. You can see what should be happening and then start debugging to see what is happening.
Most importantly, documentation doesn’t always exist. I wrote an article recently for Torque on adding custom endpoints and routes to the WordPress REST API. At the time it was published, I’m pretty sure my article was the only documentation on how to do it.
The lack of documentation wasn’t a problem for me. I just read the source for the default post control. You can’t allow yourself to go through life being rendered powerless by a lack of documentation.
It’s A Free Software Ya’ll
If you want to be a creative non-fiction writer, you’re going to need to not just read, but critically study Truman Capote, June Didion, James Baldwin, Hunter S. Thompson and others top non-fiction writers. That’s a huge part of learning to write in that genre that you can’t skip.
Being a developer is not different. Go grab a well written plugin, and figure out how it works. Along the way you will learn more about how to work with that plugin than you will be reading documentation, no matter how well documented it is.
Pull up the file in WordPress with the API you use the most and trace how it executes the code your throwing at it. Next time something goes wrong with that API, you will know exactly where to start your search for the cause of your issue.
It’s a free software, don’t forget to use your freedom to learn how the program works and to document your code to help others learn from what you do: