--- title: "How to become a WordPress developer, then an engineer" id: "544" type: "post" slug: "become-a-wordpress-engineer" published_at: "2026-10-06T20:00:48+00:00" modified_at: "2026-10-06T20:00:48+00:00" url: "https://danielpazwp.com/become-a-wordpress-engineer/" markdown_url: "https://danielpazwp.com/become-a-wordpress-engineer.md" excerpt: "How to become a WordPress developer from zero, then grow into a WordPress engineer: measure every change, own a system, read plugins, record decisions." taxonomy_category: - "Career" --- [Career](https://danielpazwp.com/category/career/) 6 min read # How to become a WordPress developer, then an engineer How to become a WordPress developer from zero, then grow into a WordPress engineer: measure every change, own a system, read plugins, record decisions. Published **06/10/2026**6 min read [Written byDaniel PazDaniel Paz has worked on the web for more than 14 years and has focused on WordPress since 2016. He is CEO and founder of WebOption, creator of WP Alta Performance (Brazil’s reference channel on WordPress optimization) and has shipped WordPress for Globo, Shell, Endeavor, Estratégia Concursos and Brazil’s Federal Government. He speaks at WordCamp Brazil, WordCamp Canada and WordCamp US, TDC and PHP Conference Brazil.](https://danielpazwp.com/author/daniel-paz/) How to become a WordPress developer: learn HTML, CSS, PHP and JavaScript well enough to read other people’s code, build a theme and a small plugin from scratch on a local environment, and ship a few real sites with version control. That gets you hired. To grow from developer into WordPress engineer, add the habits that come after the code: measure every change with field data, learn how the server, database and caches handle each request, take ownership of deploys and maintenance, and write down your decisions so others can review them. The first part takes months. The second is a change in how you work, and it never really ends. This is the path I would follow if I started again today. It is the practical companion to [WordPress engineer vs developer](https://danielpazwp.com/wordpress-engineer-vs-developer/) , where I explain why I think the market now pays for the second part more than the first. ## How to become a WordPress developer from zero If you are not a developer yet, start here. If you already ship WordPress sites, skim this section and go to the next one. ### Learn the web before WordPress WordPress is PHP that outputs HTML, CSS and JavaScript. If you skip the base, every WordPress concept will feel like magic, and magic is hard to debug. Learn semantic HTML, CSS layout with flexbox and grid, enough JavaScript to work with the DOM and fetch data, and PHP up to functions, arrays and classes. Accessibility belongs here too: headings, labels, focus and contrast are cheaper to learn first than to fix later. ### Set up a real local environment Use a local stack such as Local, wp-env or Docker, and keep every project in Git from the first day. Install Query Monitor ([wordpress.org/plugins/query-monitor/](https://wordpress.org/plugins/query-monitor/) ) on your local sites and leave it on. You will learn more about WordPress from watching which queries and hooks run on each page than from most tutorials. ### Build the three things every WordPress developer builds 1. A block theme with theme.json, templates and template parts, so you understand how modern WordPress handles layout and design tokens. 2. A small plugin that registers a custom post type, a custom block and a settings page, with proper escaping, sanitizing and capability checks. 3. A REST API endpoint with a permission callback, consumed by a small piece of JavaScript. Build them yourself, then use AI tools to compare their output with yours. Asking why a tool chose a different approach is a good way to learn, as long as you are able to tell when the tool is wrong. The [WordPress developer documentation](https://developer.wordpress.org/) is the reference to check against. ### Ship real sites Personal projects teach syntax. Real sites teach everything else: content editors who use the site in ways you did not expect, hosting limits, plugins that conflict, clients who change their mind. Take small projects, volunteer for a nonprofit, rebuild a site for someone you know. Three shipped sites teach more than ten tutorials. At this point you are a WordPress developer. Most people stop here, and many have good careers doing it. The rest of this article is for people who want to go further. ## From developer to WordPress engineer None of the steps below needs permission or a new title. They need a different habit at the start of every task. ### Measure before and after every change Before you touch a site, look at its field data in CrUX or Search Console. After you change it, look again, keeping in mind that CrUX uses a 28-day rolling window, so real-user results take weeks to settle. Learn the thresholds by heart: LCP good at 2.5 seconds or less, INP at 200 milliseconds or less, CLS at 0.1 or less, all at the 75th percentile. If you can’t show what changed, you can’t defend the work. Start with [field data vs lab data](https://danielpazwp.com/core-web-vitals-field-data-vs-lab-data/) . ### Own one system outside your editor Pick the server, the deploy process or the caching layer and become the person who understands it on your team. Learn how PHP-FPM workers, OPcache and the database behave under load. Configure a persistent object cache. Set up a deploy that can be rolled back. Owning a system is what turns code knowledge into engineering knowledge. ### Read the plugins you install Not every line. Read the parts that run on every request: what the plugin hooks into `init`, what it enqueues on the front end, what it saves as autoloaded options, what remote calls it makes. After a few months of this, you will choose plugins differently, and you will remove more than you add. ### Write down your decisions Keep a short decision log per project: what you chose, what you rejected, and why. Share audits as documents, not as chat messages. This is the habit that makes your work reviewable, and engineering work needs to be reviewable. ### Go deep in one area You can’t be an expert in everything. Pick one area where depth pays: performance, accessibility, security, technical SEO, WooCommerce or large-scale platforms. I picked performance years ago because it touches the whole stack and its results are measurable. The other areas of skill are listed in [the WordPress developer skills that matter in 2026](https://danielpazwp.com/wordpress-developer-skills/) . ## What does the path look like in stages? This table is how I think about the progression. The stages overlap, and nobody moves through them on a fixed schedule. | Stage | Main question you ask | What you can be trusted with | | --- | --- | --- | | — | — | — | | Learning | How does this work? | Small tasks with review | | Developer | How do I build this? | Features and fixes on existing sites | | Senior developer | How should this project be built? | Technical choices and code review on a project | | Engineer | What happens to the system when we build this, and how will we know? | Performance, reliability and security of running sites | ## Where does the community fit? I learned more about WordPress from the community than from any course: forum answers, meetup conversations, contributor days and WordCamps. Contributing is also how people get to know your work. Answer support forum questions in your area, test a release candidate, contribute to documentation, write about a problem you solved. Later, if you want, submit a talk. The community handbook at [make.wordpress.org/community](https://make.wordpress.org/community/) explains how meetups and WordCamps work. I talk about this path, and about what AI changes in it, in [Staying relevant as a WordPress developer](https://danielpazwp.com/talks/staying-relevant-wordpress-developer/) . The written version is [staying relevant as a WordPress developer in 2026](https://danielpazwp.com/staying-relevant-as-a-wordpress-developer-in-2026/) . ## What should you avoid? - Learning only one page builder and calling it WordPress development. Builders are fine tools, but they hide what WordPress is doing. - Judging your work by lab scores alone. A green PageSpeed score with failing field data is a failing site. - Adding a plugin for every feature. Each one is code you now maintain. - Collecting certificates instead of shipping work. A case study with before and after data says more than a badge. - Waiting until you feel ready to share what you know. Nobody feels ready. If you lead a team and want help building these habits on a real project, through a site review or team training, see how I work on the [WordPress expert page](https://danielpazwp.com/wordpress-expert/) . [Work with Daniel](https://danielpazwp.com/#book) [More in Career](https://danielpazwp.com/category/career/) [About the authorDaniel Paz has worked on the web for more than 14 years and has focused on WordPress since 2016. He is CEO and founder of WebOption, creator of WP Alta Performance (Brazil’s reference channel on WordPress optimization) and has shipped WordPress for Globo, Shell, Endeavor, Estratégia Concursos and Brazil’s Federal Government. He speaks at WordCamp Brazil, WordCamp Canada and WordCamp US, TDC and PHP Conference Brazil.Author page](https://danielpazwp.com/author/daniel-paz/) ## Related articles [All articles](https://danielpazwp.com/blog/) [Career Oct 2026How to become a WordCamp speaker (2026 guide)](https://danielpazwp.com/how-to-become-a-wordcamp-speaker/) [Career Oct 2026WordCamp talk proposal examples and ideas](https://danielpazwp.com/wordcamp-talk-proposal-examples/) [Career Oct 2026WordCamp speaker bio example and slides checklist](https://danielpazwp.com/wordcamp-speaker-checklist/)