Software Engineering in WordPress, PHP, and Backend Development

Category: Articles (Page 2 of 252)

Personal opinions and how-to’s that I’ve written both here and as contributions to other blogs.

Colleges Don’t Teach Useful Software Development (Do They?)

With regard to what I shared in the previous post – What Do You Expect From Being a Software Developer? – the author provided 10 things I enjoyed thought it’d be a good exercise to look at each point through my own experience.

At the very least, perhaps these things will be something to keep in mind if you’re looking to enter the industry or even for who have been working in the industry. At most, that article is something that provides a solid perspective from one person’s experience (which likely echo many others, too).

This lead me to think about my experience both in college and in my career in software development and how it relates to the ten points mentioned in the last post. It’s easy to say colleges don’t teach useful software development, but how true is that? Again, I’m not arguing the original post. But perhaps my perspective is a different.

I’m not going to give a deep dive into my entire history doing this (who would want to read that, anyway? :) but why not share my on the 10 points mentioned?

Distinguishing Between Computer Science and Software Development

I think of computer science and software development as two different things.

This is an important distinction because if you’re talking to someone who works in the field of computer science, they may or may not be in the field of software development; however, if you talk to someone in the field of software development then it’s likely they’ll be doing exactly what the title implies.

And as the field has grown in the last 10-15 years, entire degree programs or certification programs specifically for software development have emerged (as opposed to those just for computer science). That said, there are also degrees and certifications that have a foundation in computer science with a focus in software engineering, software development, web development, and so on.

All of this is worth mentioning because when we start talking about the case of if college will prepare you for a career in software development, I think it’s important to be nuanced enough to map what the college program was teaching versus what you’re expecting from the job market.

Further, it’s also worth stating that it’s not required or necessary to go to college to get a job in this job market. This was the path I chose; others have their own.

“College Will Not Prepare You for the Job”

This is where I think it’s important to distinguish between computer science and software development. When I was in school, I majored in computer science with a focus in software engineering.

If I had to summarize it, I took a lot of classes that were focused on computer science – that is, a lot of math – and then I had a lot of courses on software engineering – that is, how to analyze, design, build, and/or maintain software. For experience, I worked as a teaching assistant and participated in a few internships.

So there’s my context for the experience I’ve had thus far.

In the original article, Mensur writes:

The college will prepare you for some basics, but what most of the colleges teach is so far away from day-to-day jobs. Most of the professors who teach at universities are not good software engineers.

Only a small percentage of them even worked as software engineers. Also, the university curriculums are heavily outdated. They trot years behind the software development market needs.

college will not prepare you for the job

There are three main points in this passage I found most relevant to what I’ve done over the last 16 years (including what I’m doing now).

1. Most Professors Are Not Good Software Engineers

I can definitively say in my experience, you could tell who were the academics and who were the practitioners.

This isn’t to say either is better than the other. If, however, you’re going into the job market then those who have been there have something to offer than those who have been in academia. Conversely, if you’re looking to continue on the track of research and education, then those who have worked in the job market may not be the ones who are your best resource.

Even then, you have to know if the professor is working at the university for research or they are practicing software development by building out something that’s yet to be made publicly available. Some institutions do that and, as such, it’s not as easy to cleanly divide the two.

Generic class room all too similar. Photo Credit.

First, I can unequivocally say the professors who had the greatest impact on my career and my interest in software as a career were those who had spent time outside of an academic setting and worked in the industry (in fact, I still remember their names and many of the projects we did for those classes because they were designing from real world scenarios). A lot of practical skills were taught.

Secondly, I’m not saying those who had not worked in the industry weren’t good professors. Their methods of teaching and the projects they assigned felt far more academic in nature. A lot of theory was taught.

I know: Giving two examples relevant to my own experience doesn’t make or a solid case in one direction or the other. The goal is just to add another perspective to another published article.

The point is simply this:

  • The majority of the professors who prepared us for working in the industry were those who had already been there.
  • Those who had not worked in the industry were teaching foundational concepts – they were teaching us how to think.

And I’ll have more to say about that later.

2. University Curriculum Is Heavily Outdated

This point isn’t going to be very long because I can’t speak to the state of university curriculum. Generally, it’s a strong maybe from me. I’m sure it depends on the university or the program in which you’re enrolled.

At the time, I didn’t feel like much of the content I was learning was out of date. But it’s hard to know when you’re in school, right? What do you have to judge it against?

But looking back, there’s only one course that I took that felt out of date for me and it didn’t so much have to do with the content but it had to do with the language we were using: Smalltalk.

There’s a caveat here, though: Part of the reason we were tasked with using Smalltalk was because it was also to help inculcate the foundations of object-oriented programming where everything is an object that receives messages (versus classes and functions that are invoked on an instance of the class).

So even that served its purpose because it told us how to conceptually adapt to a weird requirement.

And for those who are wondering, there were a lot of languages used in school at the time (Java, C, Python, Smalltalk, JavaScript, SQL, and so on). But to say this is heavily outdated isn’t as true as it might be for others.

  • Was Smalltalk outdated? Yes. But I recognize the concepts taught in that class along with designing or improving object-oriented based systems were the most useful.
  • What about working with a team to scope, design, build, and test a photo sharing application? This was more applicable to what I was going to be doing day-to-day.

Now, I’ve probably forgotten certain things we were taught that are no longer needed – as is apt to happen – but one thing I distinctly remember learning that I only used in my first job out of school were UML diagrams.

I get the point of them, I understand what they are supposed to convey, but rarely do teams have the time to do this when tasked with a project. Further, it’s harder to diagram part of a project when a much larger system already exists (especially if even part of it is a legacy system).

3. Learn How to Learn

As I mentioned in the first point, the biggest advantage that I came away with when graduating with my degree was that I had learned how to learn.

No, I didn’t know all the languages but I didn’t need to know them. No, I didn’t know all the various tools, systems, languages, platforms, and so on, but I knew how to learn and adapt. And that one skill alone has likely been the one that’s paid the most dividends.

So if you’re in a program – be it something from freeCodeCamp, a course in high school, at a local college, a university program, or anything in between – it’s important to learn how to pick up something new and integrate it into your workflow.

For example, when you understand how something, say dependency injection, works in one language, it’s more or less matter of semantics when using it in another language. And that’s because the act of being able to do a thing transcends the tools used to do the thing.

Anyway, figuring out how to learn is key and we all have different ways of doing it so it’s important to find what works best for you. If that means going to office hours, doing independent reading, watching more content on YouTube, or meeting with the professor or a group of other students, or hanging out with like minded people at a conference, then do it. Whatever opportunities available that are tailored to sharpen your ability to learn, take advantage of them.

Ultimately, learning the why behind something helps you start formulating your own ways of how to learn something new. And when you get a good hold on that, picking up new technologies or applying something from a previous project or a previous job into a solving a new problem becomes easier.

Nothing I’ve shared here is a rebuttal to the previous article nor is it meant to even be argumentative. If anything, this is additional content. It’s an extension to an article someone else has already written.

And if anything else, this is a good exercise in writing something other than how to achieve something programmatically.

What Do You Expect From Being a Software Developer?

Not everyone who works in software development has a degree in computer science (or a degree at all), and I’m not suggesting that you should.

However, if you have ever taken a class, course, or degree program in computer science, software development, or programming in general, there were likely certain assignments or projects given to illustrate specific concepts.

For some, there were even capstone projects that required working on real-world applications. These types of projects, along with internships, are often the most valuable, as they allow you to experience what it’s like to work as a developer or engineer in a professional setting.

In other words, I don’t know what you expect from being a software developer, but engaging in these types of projects or internships can significantly help you understand the difference between theory and practice, as they say.

To that end, here’s a great article by @mensur-durakovic called 10 hard-to-swallow truths they won’t tell you about software engineer job.

Last weekend I had a chance to talk with some students who just got their degree. They are pursuing their first software engineer job. In conversation with them, I learned that they have a pretty wrong perception of this job. This is because the reality for these new kids is so skewed.

Here are the top 10 things as provided by Mensur:

  1. College will not prepare you for the job
  2. You will rarely get greenfield projects
  3. Nobody gives a f*** about your clean code
  4. You will sometimes work with incompetent people
  5. Get used to being in meetings for hours
  6. They will ask you for estimates a lot of times
  7. Bugs will be your arch-enemy for life
  8. Uncertainty will be your toxic friend
  9. It will be almost impossible to disconnect from your job
  10. You will profit more from good soft skills than from good technical skills

The entire article is worth a read especially because of the elaborations on each of the above points.

I, nor do I think the author, is claiming all software development jobs are like this but many are. I’d venture to say that many software development jobs include at least a handful of these things (and I do feel bad for those who have a job that exhibit all 10 of these).

If you’re ever wondering what it’s like to worth in software development, or you’re wondering about your own ability in your organization, or you’re wondering about your organization in general, maybe read this list.

And maybe I’ll work a few articles with my experience on each of these points. It’d be likely be 10 short reads, but it’d be something. And it’d be something that’d be relevant to many of you who found yourself as an engineer who made their way into WordPress.

One Way to Standardize Structure for Must-Use Plugins

The mu-plugins directory can often become full of various files that have basically been dropped in to solve a particular problem for the particular WordPress installation.

In my experience, these are often useful plugins but they aren’t structured like more standard plugins. That is, mu-plugins often look like a bunch of files dropped in the directory that don’t make a lot of sense unless you read the files. Further, an mu-plugin is often a single file that’s monolithic in nature.

Given the nature of mu-plugins, there’s a case to be made they shouldn’t need to be structured like that. Of course, if you’re building some advanced functionality that is considered must-use, then I think it’s worth building it in such a way that follows modern standards and still works within the mu-plugins structure.

What options are there, though?

I’m sure there are many solutions for how to do this but the way that I’ve found to be cleanest while also allowing me to build plugins in the way I typically do is to maintain a bootstrap file in the mu-plugins directory that references the actual plugin which resides in its own subdirectory.

For example, let’s say I’m building a plugin called acme-solution and the basic file structure looks like something like this:

To drop this into the mu-plugins directory, it’s far too many files as it makes it difficult to maintain along with the rest of the plugins that are present (not to mention the work that may be required when working with a CI/CD app).

So then, I’ll create a bootstrap that looks like this

This obviously is named the same as the acme-solution subdirectory to keep cohesion as high as possible. Then the plugin that resides in acme-solution is structure the same as if it were a standard alone plugin.

And, for what it’s worth, the GitHub repository is structure exactly as you see here. That is:

  • composer.json
  • composer.lock
  • src/
  • vendor/

Are included in the repository as well.


  • The vendor directory usually only includes the autoloader. I don’t recommend checking all of the dependencies into the repository unless there’s a good reason to do so.
  • Props to Benjamin Rojas for working with me on coming up with something that’s applicable across a variety of types of mu-plugins.

Why We Don’t Always Need Do Perform an Early Return

There are a lot of opinions on how return statements should work.

  • Some say that there should be a single point of return in a function,
  • Some day we should return as early as possible,
  • Some day multiple return statements are fine,
  • And some say that, when applicable, return as early as possible.

I’m sure I’m missing some, but all of these are ones I’m sure the majority of you have seen. And though I don’t hold either of these to be law, I think there’s a time and a place for each.

I’m a fan of the early return statement. In my mind, the sooner we can determine we don’t need to do the work of a function, the better we just leave.

For example, say we know if we’re not on a certain page, we can go ahead and leave the function:

In this case, it makes sense because:

  1. You only want to perform work on the plugins.php page,
  2. The amount of work to be done in the function is larger than what should ever fit within a conditional.

But there’s an alternative when the amount of work is less than what’s above.

Continue reading

The Term ‘WordPress Adjacent’ Should Be More Precise

Over the last year or so, the term “WordPress adjacent” has become more popular to use. And I get it. There are a lot of us who are still heavily involved with WordPress but who are building tools and/or solutions that may not only interact with WordPress or that start with WordPress and fan out from there.

So that phrase, as they say, has entered the chat. And it’s not a bad phrase, per se. But I think it’s imprecise and I think we can do better. This is important for those of us who write, podcast, speak, and any or all of the above.

This is you, entering the chat. Photo Credit.

First because I believe it’s important for us to be able to clearly define about what we’re talking and how it relates to WordPress. And secondly, so that our audience can follow it.

Imagine thinking you’re going to hear someone talk about building headless applications in WordPress and all that comes with that only to hear that a backend engineer is going to be talking about building a utility that incorporates Google Cloud Functions and custom endpoints to send data to a cloud-based database and to a WordPress database, too.

All of that falls under the umbrella of WordPress Adjacent. And that’s why it’s not good enough. It’s why we need to more more precise.

What Does It Mean to Be WordPress Adjacent?

Starting a more broadly, I would say, at it’s core, being WordPress adjacent refers to individuals or projects closely associated with WordPress, either through direct use or integration with technologies related to the core application.

It’s straightforward enough, but it’s a mouthful, isn’t it? Trying to throw this into a presentation or a podcast and you’re going to lose half your audience.

This person just checked out of your talk. Photo Credit.

Here’s why I say that: In their mind, people already have what it means to be WordPress adjacent. So when what you describe doesn’t map to what they think, it feels like someone is wrong or perhaps being misunderstood.

There’s no reason to feel that way but this is why I think we need a level of precision. Ultimately, there’s a myriad of ways one can be WordPress adjacent.

Lack of Precision is Frustrating (Why Wouldn’t It Be?)

The imprecision of the term WordPress adjacent is both a blessing and a curse. On one hand, it allows for flexibility, acknowledging the diverse roles and projects within the WordPress ecosystem.

On the other, this vagueness can lead to confusion. Imagine trying to explain your job to someone using this term – chances are, you’d end up providing a convoluted explanation that leaves the them more confused than not.

Okay, so How Do We Address It?

In my experience backend engineer, I’ve found myself involved in projects that are WordPress adjacent. And there’s certainly been an uptick in that in the last few years. Further, I’m grateful for it because it allows me to continue to grow as an engineer with learning other technologies, integrating them, and then having them still communicate with WordPress.

Case in point. Imagine, databases with a master and development branches all accessible via PHP or cloud functions.

From developing custom APIs that communicate seamlessly with WordPress installations to creating data systems all of which ultimately increase the functionality of WordPress websites.

Stuff like this orbits WordPress without directly living only within it.

And so that’s how what I do is WordPress adjacent. It may be how the work you do is too. But it’s not the same for all of us.

Clarifying Our Roles

So, how do we address this ambiguity? When we use the term “WordPress adjacent,” we provide a brief explanation of how exactly we are adjacent. Whether it’s through

  • developing plugins,
  • creating bespoke themes,
  • enhancing user experience,
  • building headless front-ends,
  • communicating with third-party APIs and integrating them back into the WordPress application (or vice versa),
  • and so on.

Specifying our roles helps in demystifying the term for others.

Ultimately, it fosters a deeper understanding of the diverse economy that revolves around WordPress.

Clearing Things Up

In technology, clarity is key. And given WordPress is technology, it isn’t exempt from that.

For those of us who work in this space, we have a responsibility to those who read our articles, listen to our podcasts, or attend our talks to clarify our roles. Don’t leave it to them to figure out in the moment.

If you’re going to be using the term in the future – which I personally hope to see more of – let’s at least explain how we’re adjacent.

« Older posts Newer posts »

© 2023 Tom McFarlin

Theme by Anders NorenUp ↑