# How I Became a Self-Taught WordPress Developer (17 Years, No Bootcamp) - Link: https://matthummel.com/self-taught-wordpress-developer/ - Published: 2026-09-25T05:27:21+00:00 - Author: Matthew Hummel I’ve spent about seventeen years learning this work the long way: reading docs, shipping real sites, and fixing what broke. I’m a **self-taught WordPress developer**— plus plenty of on-the-job learning in marketing web and related tools. No bootcamp fairy tale. Just practice. All of that time has been in-house web work, and it started in higher-ed marketing. Nobody handed me a curriculum. I learned by doing the job in front of me, one site and one problem at a time. This post covers how that happened, what it taught me, and how it shapes the custom WordPress work I do for shops and agencies today. ![Self-taught WordPress developer workspace illustration with a block editor window, code panel, and learning checklist](https://matthummel.com/wp-content/uploads/2026/ 09/Self-taught-WordPress-developer-workspace-illustration.jpg) ## Early tools: Dreamweaver and hand-coded ASP Before 2010, most of my web work lived in Dreamweaver and hand-coded ASP. That was the practical stack where I learned how pages, forms, and server-side logic fit together. It wasn’t glamorous, but it taught fundamentals I still use: clear structure, careful edits, and respect for what has to keep working after you leave. Working that close to the code meant I had to understand what each page was doing. If a form stopped sending, I had to find out why. If a layout broke in one browser, I had to fix it by hand. There was no page builder to fall back on. That habit of reading the code before changing it has stayed with me. It is one of the most useful habits you can pick up early, because it makes every later tool easier to learn. ## First webmaster job at Germanna Community College My first webmaster role was at Germanna Community College, in the marketing and public information office. That’s where on-the-job learning got serious. I learned marketing alongside advanced web work—messaging, audiences, deadlines—and how a public college site has to hold up for prospective students, faculty, staff, and alumni. Being in a marketing office, not an IT office, shaped how I think about websites. The site was there to help people find what they needed and take the next step. Every technical choice had to support that. I still bring that view to every marketing team I work with. ### ASP to PHP and WordPress on WP Engine Over time the stack moved from ASP toward PHP and WordPress, hosted on WP Engine. Day-to-day edits shifted from Adobe Contribute to WordPress itself. The college site redesign is when my interest in WordPress really took hold: a CMS marketers could use, themes and plugins we could maintain, and a workflow that matched how the office actually published. Moving to WordPress meant learning a new set of rules. I spent a lot of time in the [WordPress Theme Handbook](https://developer.wordpress.org/themes/), learning how templates, the loop, and hooks work. I tested what I read on real pages and kept notes on what worked. That redesign was the point where I stopped thinking of myself as someone who edits web pages and started thinking of myself as a WordPress developer. ## What higher-ed marketing web taught me Higher-ed marketing web is a demanding classroom. Accessibility matters. Handoff matters. The people who update the site after launch need a system they can trust— not a clever setup only one developer understands. * Clear navigation and plain language for mixed audiences * Accessibility as part of the build, not a late add-on * Editability and documentation as part of the deliverable * Judgment: keep it simple unless structure earns its keep Those habits still shape how I build WordPress sites today. ### Accessibility as a daily habit A college site serves a wide range of people, including people who use screen readers, keyboards, or zoom. I learned to check headings, link text, color contrast, and form labels as I built, not after. The [W3C’s WCAG overview](https://www.w3.org/WAI/standards-guidelines/wcag/) became a regular reference. Building this way from the start is faster than fixing it later. It is also the right thing to do for the people using the site. I learned accessibility on real pages with real deadlines, and that made it stick. I wrote more about this in [why an accessibility plugin won’t make your site accessible](https://matthummel.com/wordpress-accessibility-plugin/). ### Writing for the next person In-house work taught me that I would not always be the one making the next change. Someone else might need to update a page on a busy day. So I learned to name things clearly, leave short notes, and keep content editing simple for non-developers. That habit has mattered more than any single technical skill. ## Power Apps, SharePoint, and missing WordPress Later I worked with Power Apps and SharePoint for several enterprise consulting firms. I enjoyed that stretch for a while—process-heavy systems, ownership, and workflow thinking. Over time I missed WordPress: public-facing sites, content that marketers can edit, and the open web side of the craft. That chapter didn’t replace WordPress as the focus. It sharpened how I think about handoff, permissions, and maintainable systems—skills that transfer when a WordPress site has to survive real teams and real turnover. I wrote more about that change in [why I’m moving away from Power Platform and back to modern WordPress](https://matthummel.com/why-im-moving-away-from-power-platform-and-back-to-modern-wordpress/), and in [coming back to WordPress and why I’m all-in again](https://matthummel.com/coming-back-to-wordpress-why-im-all-in-again/). ## How I learn new things I didn’t wait for a perfect curriculum. I read official docs, verified them on live sites, broke things carefully, fixed them, and asked better questions the next time. Some weeks that meant CSS that finally behaved. Other weeks it meant understanding how a CMS stores content, or why a form failed for the one user who mattered most. * Read the docs, then confirm against a real site * Prefer maintainable choices over clever ones * Treat handoff and editability as part of the work * Learn through finished projects, not unfinished theory ### Official documentation first When I need to learn something new in WordPress, I start with the source. The [WordPress Developer Resources](https://developer.wordpress.org/) site covers themes, plugins, the REST API, and the [Block Editor Handbook](https://developer.wordpress.org/block-editor/). Blog posts and videos help, but I check them against the official docs before I rely on them. ### Small projects that ship Finishing a real project teaches more than reading about one. A recent example is my first plugin in the WordPress.org directory. I wrote about [how I published my first WordPress.org plugin, TOCguide](https://matthummel.com/first-wordpress-org-plugin-tocguide-ai/), including the review steps and what I had to fix along the way. Projects like that are how I fill gaps. You find out what you don’t know when something has to work for other people. ### Reading other people’s code WordPress core, well-built plugins, and good themes are open for anyone to read. When I don’t understand how something works, I open the code and follow it. That has taught me more about hooks, filters, and data handling than any single course. If you’re teaching yourself, reading code is one of the most reliable ways to learn. ## How I debug WordPress problems When something breaks on a site, my first goal is to understand the problem before I change anything. That habit goes back to my early days with Dreamweaver and ASP, when I had to read each page to see what it was doing. The tools are better now, but the approach is the same. I start by trying to repeat the problem. If I can make it happen again on purpose, I can usually find the cause. I write down the exact steps, the page, the browser, and what I expected to see. That short note often points me in the right direction before I open any code. Next, I move the work to my local development site. I don’t want to test guesses on a live site that editors and visitors depend on. Locally, I can turn plugins off one at a time, switch to a default theme, or add logging without anyone noticing. Browser developer tools answer a lot of questions quickly. I check the console for script errors, look at the network panel to see which requests failed, and inspect the markup to see which styles apply. For PHP problems, I turn on WordPress debug logging and read what it records. I change one thing at a time. When I change several things at once, I lose track of what actually fixed the problem. Git helps here, because I can see every change I made and roll back anything that did not help. Once the fix works, I write a short note about what went wrong and why. I don’t have old class notes to look back on, so these notes are my reference. They save me time when a similar problem comes up again. ## The tools I use today My tools have changed a lot since Dreamweaver. The list is simple on purpose. I would rather know a few tools well than chase every new one. * **A code editor.** These days I use Cursor, with AI help for routine tasks that I still review line by line. Here is [my full AI workflow for WordPress development](https://matthummel.com/ai-workflow-for-wordpress-development/). * **Git and GitHub.** Every project has version history, so changes can be reviewed and rolled back. * **A local development site.** I test changes locally before they go anywhere near a live site. * **Browser developer tools.** Most layout and script problems can be found here. * **Accessibility checks.** Automated tools catch some issues. I also test with a keyboard and a screen reader. If you want to see some of that work, I keep a short list in [what’s on my GitHub and on this site](https://matthummel.com/whats-on-my-github-and-on-this-site/). ## The limits of learning on your own Teaching yourself has gaps, and I would rather be honest about them. Without a formal program, nobody checks that you covered every topic. You can miss something for a long time because it never came up at work. I handle that in a few ways. I read the official handbooks end to end when I start a new area, not just the page I need that day. I read code from WordPress core and from plugins I trust. And I take feedback seriously when another developer points out a better way. That approach is slower than a shortcut, but it has kept my work steady for a long time. ## What hiring a self-taught WordPress developer means for your project Being self-taught is not a label I use to stand out. It describes how I work. I learned by solving real problems for real teams, so that is still how I approach a project. * **Accessible by default.** Headings, labels, contrast, and keyboard use are part of the build. * **Maintainable code.** I follow WordPress conventions so another developer can pick up the work. * **Editable content.** Editors should be able to update pages without calling me. * **Clear handoff.** I document what I built and how to change it. None of this is unusual for someone who came up through in-house work. It is what I learned the site needs after launch, when the original developer may not be around. ## How I work with agencies and shops now Today I build custom WordPress work for shops and agencies. A lot of that is agency overflow, where a team needs another developer for a project or a busy stretch. I explain how that works in [WordPress agency overflow: how white-label help works with me](https://matthummel.com/wordpress-agency-overflow/). I take agency overflow and custom quotes only. I don’t post public pricing, because every project is different and I would rather quote the actual work. Agencies sometimes ask how I fit into their process. I’m glad to work inside it: their repository, their coding standards, their review steps, and the tools they already use to communicate. I’m open to agency collaboration, and I’m also open to a full-time role with the right team. ## How I keep learning with a busy schedule I have a full-time job, a freelance WordPress side business, and twins at home. That doesn’t leave long, open blocks of time for study. I had to find a way to keep learning that fits into the time I actually have. The biggest change was to stop waiting for free time. Instead, I tie learning to the work already in front of me. If a project needs a feature I haven’t built before, I read the documentation for it that week and build it carefully. The project gives the learning a clear purpose and a deadline. Finally, I try to be realistic. Some weeks, family and my full-time job come first, and I don’t learn anything new. That’s fine. After 17 years of in-house web work, I know that steady progress over time matters more than any single week. Consistency is what keeps skills current. That same approach is what I would suggest to anyone balancing a job and a family while they learn. Pick one small goal, tie it to real work, and keep going. Short, regular effort adds up. ## Advice if you are learning WordPress on your own People sometimes ask how to become a self-taught WordPress developer. I can only speak to what worked for me, but these steps held up over the years: * Build something real, even if it is small, and put it online. * Read the official handbooks before you search for shortcuts. * Learn basic HTML, CSS, and PHP well before you add more tools. * Make accessibility part of every build from the first day. * Keep notes on what you fix so you can find the answer next time. * Ask for feedback from people who will use the site. Progress is slow at first. It speeds up once you have a few finished projects behind you. Every developer I know who taught themselves started with small sites that nobody else noticed. ## Where I work from I’m based in Gettysburg, Pennsylvania. If you need a self-taught WordPress developer who learned this work on the job—and who still builds with accessibility and handoff in mind—[say hello on my hire page](https://matthummel.com/about/#hire). Tell me what you’re working on; I reply within one business day (ET). ## FAQ ### Are you formally trained or self-taught? Mostly self-taught, with a lot of on-the-job learning. Docs and courses helped. Shipping real sites under real deadlines taught me the rest, starting with my webmaster role at Germanna. ### When did WordPress become the focus? During the Germanna college site redesign, as we moved from ASP and Contribute toward PHP/WordPress on WP Engine. That’s when WordPress stopped being “another tool” and became the craft I wanted to keep refining. ### Why mention Power Apps and SharePoint if WordPress is the focus? That consulting work taught me a lot about workflows and ownership. WordPress is still my specialty. That experience just helps me hand off systems that teams can maintain. ### Can a self-taught WordPress developer handle agency work? Yes. Agency work depends on clean code, clear communication, and meeting deadlines. I’ve built those habits over years of in-house work, and I follow WordPress coding conventions so an agency team can maintain what I deliver. ### Want to work together? If this background fits your project or team, [reach out on my hire page](https://matthummel.com/about/#hire). I’m in Gettysburg, PA, and I reply within one business day (ET). --- ## Want more posts like this? I keep the address on this site. I do not send it to a newsletter service. Email I write about modern WordPress development, AI tools, and building plugins. Follow along on [DEV.to](https://dev.to/matthummeldev) or [GitHub](https://github.com/matthummel-pa), or subscribe with the [RSS feed](https://matthummel.com/feed/).