Episode Six of the Code Adventurer series ends with a letter. Our Adventurer, having spent a year learning WordPress, CSS, HTML, PHP, JavaScript, and the database layer, writes directly to the person at the beginning of their own journey. It is honest and warm and says the things that are actually true: that confusion is the process, that imperfect published work beats perfect unpublished work, that the voice telling you that you are not ready yet is lying.
I liked writing that letter.
This one is different. This one is not from a fictional character to another fictional character. This is from me, someone who has been working professionally in and around WordPress for years, to anyone who finished the saga and is now wondering what a career in this space actually looks like. What the job involves. What it requires. What it gives you that the self-directed learning path cannot.
It is not a recruitment post. It is not a how-to guide for getting hired. It is just what I would actually say, which I find is usually more useful than the polished version.
WordPress is Bigger Than You Think It Is
When you are learning WordPress from tutorials, it presents itself as a blogging tool that also does websites. When you are working with it professionally, it reveals itself as something considerably larger. WordPress powers roughly forty percent of the web. The platform runs everything from personal blogs to enterprise media organisations to government sites to global e-commerce operations. The problems that arise at that scale, and the solutions required to handle them, are genuinely interesting engineering problems.
I enjoy working at WordPress VIP, which is the enterprise tier of Automattic’s WordPress hosting. The sites on that platform are large, the traffic is real, and the stakes are high enough that the kind of mistakes you can make on a personal blog without anyone noticing become very visible very quickly. That context makes the work interesting in a specific way. You are not asked to understand WordPress in the abstract. You are asked to understand it well enough to help people whose businesses depend on it when something goes wrong.
The saga covers WordPress as a solo craft. The professional version is a collaborative, high-stakes, constantly evolving version of the same tool. Both versions require understanding the fundamentals the saga teaches. The professional version requires them at a depth you cannot get from tutorials alone.
Your Technical Knowledge Is the Foundation, Not the Job
The saga spends six episodes building technical knowledge. CSS, HTML, PHP, JavaScript, databases, security, performance. All of it is real and all of it matters. But I want to be honest about something: in a support role, the technical knowledge is the floor, not the ceiling. It is the thing you need to have before you can do the actual job, which is thinking clearly under pressure and communicating well.
Every support ticket I work on starts with a technical problem. But what the person on the other side of the ticket needs is not just a technical answer. They need to understand what happened, why it happened, what the fix is, and what they can do to prevent it from happening again. They need to feel like they are in capable hands. They need the information in the right order, at the right level of detail, without jargon they do not share, without condescension, and without the false confidence that glosses over the parts that are still uncertain.
That is a writing problem as much as a technical one. The saga, interestingly, prepares you for this better than most technical tutorials do, because it is fundamentally an exercise in explaining technical things clearly to people who are learning. If you can write the way the saga is written about technical topics, you can do support work. The instinct for clarity is the same instinct.
Local Development Is Not Optional
The saga’s hero makes changes directly to the live site for most of the journey. This is understandable for a solo learner on a personal blog. In professional work it is the one habit that will cause you the most pain if you carry it forward.
A local development environment, something like the Studio app that Automattic makes, or Local, or a Docker setup, is where you should be working almost all of the time. It is where you test changes before they go anywhere near a live site. It is where you reproduce bugs without risking making them worse on production. It is where you experiment without consequences.
Version control belongs alongside this. Git, with commits that describe what changed and why, a branch per feature or fix, and a pull request review before anything goes to production. These are not bureaucratic overhead. They are how you maintain the ability to understand what your codebase looked like yesterday, last week, six months ago. They are how you undo things when they go wrong. They are how you collaborate without overwriting each other’s work.
If you are moving from self-taught WordPress developer to working professionally, setting up proper local development and version control habits early will save you more grief than almost anything else I can recommend.
Read the Codex. Then Read the Source.
The WordPress developer documentation is good. The handbook pages, the function reference, the block editor handbook, the REST API documentation. If you are not already in the habit of reading documentation before reaching for a tutorial, developing that habit will serve you well. Tutorials go out of date. Documentation, when it is maintained, tracks the current state of the software.
Beyond documentation, there is the source code itself. WordPress core is open source and readable. When you do not understand why something behaves the way it does, reading the function in core that implements it is often the clearest possible answer. This sounds more intimidating than it is. The core codebase is well-commented. The functions are generally not long. The habit of reading source code to understand behaviour rather than guessing at it is one of the things that separates a good WordPress developer from a great one.
Trac, which is the WordPress bug tracker, is also worth spending time in. Reading through open and recently closed tickets gives you a picture of how the project thinks about problems, what the priorities are, what the tradeoffs being considered look like. It is the closest thing to sitting in the room where decisions are made, and it is public.
The Career Paths Are Wider Than They Look
The saga implicitly frames the endpoint of learning WordPress as running a blog and selling digital products. That is one path and a perfectly good one. The professional paths through WordPress knowledge are considerably wider.
There is agency work: building sites and products for clients, which puts you in the position of translating requirements into working software while managing the relationship with the person paying for it. There is product work: building themes, plugins, or SaaS products on top of WordPress that serve many users rather than one client. There is platform work: the kind of work I do, where you are operating and supporting the infrastructure that WordPress runs on, which blends system administration, customer-facing engineering, and deep product knowledge.
There is also core contribution, which is how WordPress itself gets built. Contributing to core, to Gutenberg, to the block editor, to documentation, to accessibility, to performance, is a path that puts you in direct contact with the people who shape the platform. It is also, practically speaking, one of the best ways to develop a deep understanding of how WordPress actually works, because contributing requires you to understand not just what the code does but why it does it that way and what the constraints were on the decision.
Automattic hires from all of these paths. So do agencies, hosting companies, plugin businesses, and the range of companies that run their digital presence on WordPress at scale. The knowledge the saga builds is applicable across all of them. What you layer on top of it, and where you point it, is up to you.
The Thing I Wish Someone Had Told Me Earlier
Working in WordPress professionally means working in public, to some extent, whether you choose it or not. The code you write, if it is in a plugin or theme on WordPress.org, is read by other developers. The answers you give in support forums or Slack or GitHub issues are visible. The reputation you build in this community is accumulated gradually, over years, through the quality of your work and the quality of how you communicate about it.
That sounds like a reason to be cautious. It is actually a reason to start doing things publicly sooner than feels comfortable. Writing about what you are learning, asking questions in public when you are stuck, contributing small fixes before you feel qualified to contribute large ones. The community is generally kind to people who are clearly making an effort. And every public contribution, however small, is an artefact of your thinking that other people can encounter and build on.
The saga’s hero ends up with forty-one thousand readers because they kept writing about what they were learning. That is the same principle applied to a career. Show your work. Show it early and often. Let the accumulation of what you have made and written and fixed and explained become the thing that represents you professionally.
The voice that says you are not ready to do that yet is the same voice Our Adventurer spent six episodes fighting. You already know what to do with it.
Leave a Reply