New release PHP for WordPress Developers From the Root Up is available now. Explore books
Post

From Developer to Author: Turning Years of Experience Into a Book Series

For most of my career, I thought of myself first as a developer. I built websites. I wrote code. I worked with WordPress themes and plugins. I solved client problems, managed projects, debugged issues, and spent years learning how technology actually behaves outside of tutorials and documentation. Writing books was not originally the center of […]

For most of my career, I thought of myself first as a developer.

I built websites. I wrote code. I worked with WordPress themes and plugins. I solved client problems, managed projects, debugged issues, and spent years learning how technology actually behaves outside of tutorials and documentation.

Writing books was not originally the center of that path.

But after more than 14 years in web development, I started realizing that I had collected something just as valuable as code: experience.

That experience came from years of building, fixing, maintaining, securing, and improving websites for real businesses. It came from working as a Director of Web Development, leading projects, communicating with clients, and seeing what happens when technology is built well—and what happens when it is not.

Eventually, I began asking myself a different question.

What happens to all of that knowledge if I never write it down?

That question became one of the reasons the Rooted Dev Guides were created.

Development Teaches More Than Syntax

When people first start coding, the focus is usually on syntax.

How do I write this function?

How do I create this loop?

How does this API work?

How do I build a plugin?

Those questions matter.

But as the years pass, development starts teaching you something deeper.

You learn how to make decisions.

You learn when not to add another feature.

You learn how to recognize fragile code.

You learn how to troubleshoot problems without panicking.

You learn that performance, security, usability, and maintainability are often connected.

You learn that the best solution for a client is not always the most technically impressive one.

And you learn that the quality of a project often depends on decisions nobody outside the development process will ever see.

Those are the lessons I wanted to preserve.

A Book Can Hold More Than Instructions

Technical documentation is important.

Tutorials are useful.

Code examples are useful.

But a book can do something slightly different.

A book can connect individual concepts into a larger way of thinking.

Instead of explaining one WordPress function, it can explain how that function fits into a complete plugin architecture.

Instead of recommending a security tool, it can explain why layered security matters.

Instead of listing website features, it can explain what a small business actually needs from its website.

That is the direction I wanted for the Rooted Dev Guides.

I did not want the series to become a collection of disconnected instructions.

I wanted each book to help readers understand the system underneath the subject.

Turning Experience Into Structure

One of the most interesting parts of writing technical books has been taking knowledge that feels automatic after years of doing the work and breaking it back down into something teachable.

Experienced developers often do certain things without consciously thinking through every step anymore.

We recognize patterns.

We notice warning signs.

We know where to look when something breaks.

We can often tell when a solution feels more complicated than it needs to be.

Writing forces you to slow those instincts down.

Why do I approach security this way?

Why do I separate this functionality into a plugin?

Why would I choose one architecture over another?

Why is this easier to maintain?

Why does this matter to a business owner?

Those questions have actually made writing the books valuable to me too.

Teaching something forces you to examine your own process.

The Series Started With Foundations

The first Rooted Dev Guide, WordPress Security From the Root Up, established the philosophy I wanted the series to follow.

Security is often treated like a product decision.

Install a plugin.

Turn on a few settings.

Assume the problem is solved.

But years of development taught me that strong security comes from the foundation underneath the site: hosting, updates, access control, trusted software, backups, monitoring, secure development, and recovery planning.

That became the first major theme of the series:

Build the foundation correctly before depending on what sits on top of it.

The second book, The Small Business Website Playbook, moved that same thinking into business websites.

A website should not exist simply because every company is expected to have one.

It should serve a purpose.

It should help customers understand the business, build trust, make contact, and take action.

That book grew directly from years of working with businesses and seeing what they actually needed from their websites.

Then the Series Moved Deeper Into Code

Once the foundation was established, I wanted the books to move deeper into development.

That led to:

Building WordPress Plugins From the Root Up

Building WordPress Themes From the Root Up

and

PHP for WordPress Developers From the Root Up

Those books represent another part of my career: the development side.

The goal is not just to show code that works.

The goal is to help readers understand why the code is structured a certain way, how security fits into development, how WordPress architecture influences decisions, and how to build software that can actually be maintained.

That is the difference I want the series to provide.

Real-World Experience Changes the Way You Teach

There is a major difference between learning a concept and depending on that concept in a production environment.

A tutorial might show you how to build a feature.

Experience teaches you to ask what happens when:

  • The input is unexpected.
  • Another plugin conflicts with it.
  • The PHP version changes.
  • The client wants something different six months later.
  • A vulnerability is discovered.
  • The site has significantly more traffic than expected.
  • Another developer needs to maintain your code.
  • An update fails.
  • A user does something you never expected.

Those questions influence the way I write these guides.

I want readers to think beyond:

“How do I make this work?”

and begin asking:

“How do I make this reliable?”

That is a much more important question in professional development.

Writing for More Than Developers

Another thing I realized while building the series is that not every lesson belongs only to programmers.

Business owners need to understand technology too.

They may never write a line of PHP, but they still make decisions about:

  • Hosting
  • Security
  • Websites
  • Marketing
  • Forms
  • Ecommerce
  • Maintenance
  • Plugins
  • Vendors
  • Backups
  • Online growth

A business owner should not need to become a developer to make better technology decisions.

That is why some Rooted Dev Guides are deeply technical while others are designed for a broader audience.

They all share the same goal:

Make useful knowledge easier to understand and apply.

Becoming an Author Did Not Replace Being a Developer

I do not see writing as leaving development behind.

I see it as an extension of it.

Development is still about building.

Writing is also about building.

Instead of building software, you are building understanding.

Instead of organizing classes and functions, you are organizing ideas.

Instead of debugging code, sometimes you are debugging an explanation until it finally makes sense.

There are more similarities than I expected.

Both require patience.

Both require structure.

Both require knowing who will use what you create.

And both improve when you think about the person on the other side.

The Books Also Preserve a Career

Technology moves quickly.

Frameworks change.

Platforms evolve.

Tools come and go.

But many of the lessons underneath development remain useful.

Think before building.

Understand the problem.

Protect the foundation.

Avoid unnecessary complexity.

Test your work.

Plan for maintenance.

Respect the user.

Keep learning.

Writing those ideas into books gives them a life beyond one project or one client.

That matters to me.

I Want Readers to Grow With the Series

One of the goals I have for the Rooted Dev Guides is to create a progression.

Someone may begin with a small-business website guide.

Then they become more interested in WordPress.

Then they start learning plugin development.

Then themes.

Then PHP.

Then security, APIs, performance, or commercial software development.

I want the books to give readers somewhere to go next.

Learning technology is a long process.

There is always another layer.

Another system.

Another skill.

Another problem to solve.

The series is designed to grow alongside that journey.

There Are Still Many Books I Want to Write

The first few books are only the beginning.

There are still subjects I want to explore in depth:

  • WordPress performance
  • Debugging
  • JavaScript
  • Gutenberg block development
  • Secure development
  • REST APIs
  • WooCommerce
  • Database development
  • Commercial WordPress products
  • Running a theme or plugin business

And technology will continue creating new topics.

That is part of what makes development interesting.

There is always something new to learn.

From Code to Pages

Looking back, becoming an author feels less like changing careers and more like finding another way to use the same experience.

For years, I used that experience to build websites and software.

Now I can also use it to help someone else build theirs.

That is what makes the Rooted Dev Guides meaningful to me.

They are not separate from my development career.

They are a record of it.

A way to organize what I have learned.

A way to share the mistakes, lessons, patterns, and principles that took years to understand.

And hopefully, a way to help another developer, business owner, or learner move forward a little faster.

I started as a developer because I enjoyed building things.

I became an author because I realized knowledge can be built too.

And now I get to do both.

Built from experience. Rooted in better code.

Guides that help you grow.