Software Engineering in WordPress, PHP, and Backend Development

Author: Tom (Page 6 of 426)

Meetings Are Inevitable (Quality and Frequency Vary)

TL;DR: If you’re looking at a career in software development, it’s imperative to know that meetings are inevitable. However, the frequency and quality of said meetings vary.

Don’t let the opportunity to ask potential employers – or current employees – what meetings are like pass you by whenever you’re interviewing.

Further, if you’re in a place that you feel has too many meetings or something about them could change, don’t be afraid to bring this up when the time is right.


In the original article, the author writes:

There are recurring meetings scheduled on a daily or weekly basis. Most of these are not productive. The majority of them are forced by a person who is organizing them because that’s the only “work” that that person is doing.

Meetings Are Inevitable

The short answer is yes, this is true. But it’s only true in some cases; it’s not the law of companies that hire software developers. Instead, it’s based on a number of factors (some of which do include people finding their measure of productivity based on how many meetings they can schedule – but I digress).

Speaking of those few factors, these are the ones I’d like. Some of them are related, some aren’t:

  • the size of the organization,
  • the size of the team,
  • the manager of the team,
  • how the project is managed,
  • and so on.

If you’ve worked in software for some amount of time, you’ve likely experienced this and/or you have your own item to add to this list.

A Word About Project Managers

One caveat I want to mention is in all of the years of working in software development, one of the things that I’ve seen – especially in a consulting or an agency-type of setting – is that a certain breed of software developers don’t enjoy having a project manager.

Assuming the project manager is worth the weight of their role and title, I’ve found having them to be liberating. It frees me, as the engineer, up from having to thing about certain things related to external factors and let’s me focus on exactly what I want to do: Write code to ship features, fix bugs, and build software.

A project manager that not only tracks tasks for software, but works on mathematical proofs in her free time.

Do not dismiss project managers. Instead, embrace them as the gatekeepers of sorts of the backlog of features and trust them to know what works best for the business. They are the liaisons between those who write code and those who will be using, or selling, the product. It lets us focus as much as possible on what you do well.

Current Status

If you don’t read anything else in this article, know that meetings do not have to take up the majority of your time when working in software development.

Currently, I work for a fully remote organization with several hundred employees. My team consists of, at the time of this writing, about seven people, and we have one standing meeting per week.

Standing meetings are not like this. Especially in a remote company. This looks like a scene from Silicon Valley.

We use almost never use email (and if you’re interested in moving in this direction, I highly recommend reading A World Without Email), primarily use Asana for project and task management, and have daily stand-ups through a morning report in Slack.

Though this works really well for me, it may not work for you; however, I do find that less email and fewer meetings helps to foster a greater sense of focus.

Other Factors

It’d belabor the point to break down all of the various different reasons as to how the size of an organization, the size of a team, or how management can influence the number of meetings.

Suffice it to say that I’ve worked for large organizations, medium organizations, and small organizations and each of them had their respective way of conducting meetings. I do think that, especially in the world of enterprise software development, there are a lot of meetings.

Ultimately, I’d say that if you’re currently looking at a career in this field and you’re thinking it’s primarily going to be sitting at a desk writing code, that’s misguided (and unfortunately so).

I guess everyone is in the conference room for a meeting that could’ve been avoided if only they’d had a proper project manager and expectations for their meeting.

Further, it’s a disservice many places that provide an education in software development often lack a component for what to expect when you’re actually pursuing a career in the field.

So what’s a person to do? If you have the opportunity to participate in an internship, a co-op, shadow someone in the field, pursue an apprenticeship in the field, or even just interview a number of people in the industry, I’d recommend doing any of the above.

Anything that will get you as close to the field as possible before jumping into it will be beneficial.

Ultimately What, Then?

I’m in no position to say how a business should be run nor do I have the hubris to prescribe how a team or an organization should conduct itself. I’ve shared my past and current experience and shared what I’d recommend some things to try if you’re interested in the field.

Meetings are inevitable; the number of how many you’re in isn’t necessarily so. Do what you can to find what works best for you, reasonably set your experiences, and then move forward.

Writing About WordPress in the Age of AI

Periodically, I review the content I’ve written over the last decade or so and am surprised to at some of the things I wrote about in the past (like My Day-to-Day). I also find it interesting that I stopped doing so. Then again, I likely exhausted that particular topic. At least for that time.

Specifically, I’m surprised that I used to write about such things despite the topics not really being relevant to what I consider my core content.

Personally, a lot has happened in the last, say, roughly five years alone – between changing jobs, growing the family moving, pursuing additional hobbies, and more – one of the things that’s taken a back seat is writing. Then again, though, isn’t that how it goes?

We have a finite number hours on how to spend our time and as that time gets allocated to other things, something gets squeezed out. And that’s what has happened with writing.

This gentleman fears the amount of time that’s passed. The perpetual ticking that surrounds him isn’t helping.

For a while, I felt guilty about it. Partially because writing daily was something that I enjoyed doing and that I did habitually. Partially because it had become such an habit that when I didn’t do it, I felt as if I was dropping the ball on something.

And though there’s truth in some of that (such as I miss writing every day), that doesn’t mean I’d trade out some of the things I’m doing that occupy that time now. Some of it’s related to my day-to-day work, some of it’s related to my family, and some of it’s related to other hobbies.


Over the holidays (and as I’m trying this, I realize I didn’t write a short Christmas post for this year which is likely the first time since I can remember not doing that), I had time to think about a lot different things some of which included both how I want to spend my time and how I currently spend my time.

Though I’m not one for setting resolutions, I’m for settings goals. And I was planning different goals for myself over the coming year, I couldn’t help but reflect a bit on this site.

Apparently, this is how Meta imagines me doing exactly what I just described. I’m drinking something out of a pepper container.

Sure, the goals would be fun to share (and maybe I will in a future post – I always enjoy what other people are planning!), I found myself thinking a little bit about software development, WordPress, the WordPress economy, where things have been, and where things are headed.

But writing about WordPress in the age of AI especially as developer is proving its own set of challenges. Of all types of people, though, shouldn’t we be here to meet it?

And with the rise of popularity in AI, the more-or-less standardization of the Block Editor, and the upcoming changes to the administration area UI, there’s a lot that can be discussed and there will likely be a lot about which to write (either via commentary or tutorials on how to achieve something).

When thinking through that, though, I found myself remembering all of things about which I used to write that weren’t always dedicated to programming but were still dedicated to what I, as a remote developer working in software developer in WordPress, was doing.

Why did I stop doing that? And what’s to stop me from doing that again?

I used to write differently about things. How did I get here?

Just as I do think tools such as ChatGPT has wrecked some of the content I (and others) have historically written, it’s by no means a call to inaction – or a call to stop writing. It’s just a call to adjust and keep moving forward.


Though I don’t know if I’ll ever write daily again, I do think there’s plenty I can share that extends beyond:

  1. Here’s what you may want to do in WordPress using PHP or JavaScript
  2. Here’s how you can do it.

So at the end of 2024, we’ll see how I’ve done. Here’s to a greater variety of content all the while still keeping the focus on the type of content about which I’ve historically written.

The Most Useful (Or Popular) Articles from 2023

Last year, I wrote the first type of article that I’ve written in a very long time (if ever) given the amount of time that I’ve been writing. The Most Useful (or Popular) Articles from 2022.

There was generally derived from analytics data but also I used light engagement metrics via X/Twitter, LinkedIn, and even email to determine what were considered the most useful (or popular) posts.

This dude is completely scared of the fact that the calendar is nearing the end of another year.

And given that we’re nearing the end of 2023, I thought I’d do the same this year. So, in keeping with the previous trend, here are the most useful (or popular) articles from 2023.


2023: Most Useful Articles

For the last few years, I’ve claimed that I want to write more than the year before and get back to how much I was writing in a few years prior. Truth is, I don’t know if this is possible given how much has changed since this. Work is different, life is different, and the way my day-to-day is structured is different.

It’s all great, but it’s different.

Regardless, I still urge everyone with a blog to continue doing the same and then syndicating out to the web. It helps surfacing your content in search engines, on social media – be it X/Twitter, LinkedIn, Facebook, whatever, – and on RSS (which is still my personal favorite).

Father Time wrapping up another blog post for the end of another year.

Anyway, these are the posts for this year. On to 2024.

Thoughts on the Upcoming WordPress Admin Redesign

During this year’s State of the Word, the new design for the WordPress administration experience was discussed.

As described by Matias:

As WordPress turns twenty years old, the overall aim of this work is to improve upon this experience at a foundational design level, giving plugins and users more control over the navigation while ensuring each WordPress experience is recognizable, intuitive, accessible, and delightful.

The full posts lays out the high-level plans for how they plan to move forward and I find the Scope section one that’s most relevant for developers (and designers who write code, as well).

This dude is completely stoked about the redesign.

It’s too long – and redundant – to post here, so I recommend reading it via the aforementioned link.


The Upcoming WordPress Admin Redesign

As a developer who’s worked in this space since “The Kubrick Era” (is that even the way some people refer to it?) and has been involved through the years of Gutenberg development, I have some thoughts relevant to the announcement that I’m sharing for posterity to see how things pan out as this project begins.

  • I was a fan of the UI refresh we received a few years ago and I’m excited about what’s planned for this one, as well. It feels like it’s going to be much bigger but it’s easier to say that when we’ve been working with the current UI for so long (and I remember the design before that – it was no small undertaking to update it, either).
  • I’m looking forward to seeing how hooks are going to be updated (and if anything new will be introduced in terms of what we’re able to do within the admin). Will be using JavaScript to work with them more? How does PHP fit into this?
  • I’m curious as to how other things have not been updated in some time (such as certain Settings screens) will be updated beyond revamping the UI. That is, part of the WordPress philosophy used to be decisions, not options but I’d say the software isn’t as decisive as it could (or should?) be. My guess is most of the options are going to stay the same, but the general look and feel is what will change.
  • I hope to see clear documentation provided for each release for developers, designers, and users to help make it clear how to achieve certain tasks. That was a challenge within the Gutenberg-era – things that worked in one release didn’t worked in a new release and the cycle was happening to fast, it was difficult to keep up.
  • I’m very interested to see how plugins will inherently interact with the new UI given many are built to perform, look, and feel native within the existing UI.
  • Performance is something that’s always a concern and if you’ve done any profiling or network monitoring within the tools the Chromium-based browsers provide, it’s evident that there’s some things that could be refactored. Is now the time? (I’m genuinely asking – this isn’t a loaded question.)
  • I’m curious to see how well the existing Block Editor will fit within the context of the new experience. Will anything need to be modified, adjusted, or tweaked to make it feel more natural or is the Block Editor, as we know it today, more-or-less standardized?

But that’s not all there is to say about it. A lot is going into the overall project especially given this is just the third phase of a larger roadmap.


Change Is Hard

As the cliché goes, change is hard. But working through change when there are so many opinions on how the change is going makes it ever harder. Further, all the training material that agencies and organizations have as well as the material they will produce are eventually going to need to be updated as the new administration area is released.

Not that kind of change. Though I guess it’s technically hard, too.

I know the ultimate goal is to have more modern administration experience that’s easier for all types of users and I’m excited to see it come to fruition.

There’s likely going to be some friction – as is the case to come with any major updates – but I’m optimistic that we’ve learned a lot from how Gutenberg was initially developed and rolled out and I hope to see others work even more closely with the administration experience to make the transition easier both for developers and users.

I Didn’t Want to Resist Gutenberg

Though I wouldn’t say I resisted Gutenberg, I definitely found plenty of times where wasn’t ready for how I wanted to use it. The learning curve was forever influx because of the how the underlying technologies were changing or how the implementation of those technologies were changing.

Dude’s as scared of this printer as some were of Gutenberg.

To put it succinctly, trying to adopt it into my day-to-day work was a challenge.

Thus, it made me slower to adopt it both as a user and as a developer until it reached a certain level. Now it’s stabilized to a point where I both enjoy writing with it and have learned enough of the APIs to build out custom blocks for my day-to-day work in a consistent way (yes, even as one of those old people who primary works with server-side technologies).

I Don’t Want to Resist the Admin Redesign

To that end, though I recognize there are going to be inevitable hurdles to cross for this update, I also think this is a time in which lessons learned over the past few years can be applied.

Maybe we’ll receive the new admin like this. This computer is hugging back with a hand of its own.

Even though it’s not a one-to-one comparison, overhauling a major component of an older piece of software once yields plenty of learning. And I hope to be more present at least in terms of making sure the things developers enjoy – such as certain actions, filters, and other things with regard to menus, settings pages, options, and so on – are easy to learn and make sense when it comes time to migrate our code.

You Will Sometimes Work With Incompetent People (Or Will You)?

Some of the definitions for incompetent:

  • lacking the qualities needed for effective action
  • unable to function properly
  • not legally qualified
  • inadequate to or unsuitable for a particular purpose
Merriam-Webster

Given this, it’s more than likely we’ve all been the incompetent one on the team at some point in our career. Depending on the nature of the work we do, it’s reasonable to assume we could all be that person whenever we join a new team.

This isn’t to discount the skill experience teaches, but each time you start a new project (greenfield or not), there’s going to be a period in which you have to learn enough about the problem domain to actually start making meaningful contributions.

All of the above is a longer way of me delaying commentary on the claim that we’ll work with incompetent people. It’s uncomfortable to discuss because we’re making a claim about peers who are not incompetent because they’re just getting started in their career or because they are the new person on the team.

They’re considered incompetent because they aren’t able to fulfill the responsibilities, obligations, and/or demands of their job because of any one point of the above definition.

So given the claim we’ll sometimes work with incompetent people and given the definition above, how true is it that we’ll sometimes work with incompetent people?


Will We Work With Incompetent People?

In my experience, the only time I’ve truly worked with anyone incompetent was because of a willful desire to not learn what was necessary to do the job. And by that, I mean the person had the potential to actual do what was asked of them but achieving said potential required a level of effort they were unwilling to put forth.

Therein lies how a person can become incompetent not only in the field of development but generally in any field:

  • There’s a problem that needs to be solved,
  • The problem exists in a domain that requires a level of discovery and/or education (and not necessarily in the academic sense),
  • The person opts out of discovery and/or education,
  • The person can’t solve the problem,
  • And thus the person remain incompetent in their job.

Because some organizations still allow you to draw a paycheck without doing more than the bare minimum, there isn’t always a strong incentive to get better at whatever is asked.

And if this is what it means to work with incompetent people, then yes. It happens.

On Willful Incompetence

People don’t necessarily want to remain willfully incompetent, though. In my career [so far], there are plenty of times in which I would be labeled incompetent not because of my inability to ever solve the problem, but because of my inability to solve the problem at that time.

Given enough time, training, and/or information as well as enough motivation, it’s possible to move yourself out of that position and into one that enables you to get the work done.

Not only that, assuming you’re a person who is working with someone who may be currently incompetent but needs more information to become familiar with the problem domain, it’s also possible for you to be the person to help them move from one arena to the next.

In other words, if you see a need, meet it. If a colleague is unable to achieve something that you’re able to do, don’t attempt to subvert their attempt and solve it yourself.

Give them whatever help necessary to give them enough information to move forward and, assuming they’re motivated, they’ll move into the arena of being able to solve the problem.

On the Original Article

An incompetent developer who’s more interested in his fidget spinner. Generated by Imagine by Meta.

Finally, I wanted to make sure I link to the original article to see the context in which this claim was written as well as the author’s experience. In trying to summarize what’s listed here, I’d say it’s something like this:

  • Dealing with incompetent colleagues in the workplace can be frustrating and time-consuming, creating a toxic environment that affects productivity and deadlines.
  • Working with such individuals can lead to significant delays, ultimately costing companies both money and resources.
  • The frustration and challenges posed by incompetent colleagues can prompt individuals to spend considerable time strategizing ways to navigate around their lack of competence.
  • In certain situations, individuals may lack the complete context behind someone’s performance issues. There are instances where individuals struggle to perform well due to an overwhelming workload, juggling responsibilities meant for two people and hindering their ability to fulfill their job adequately.

So, yes, there are differences in what he’s experienced versus me. I’m not arguing his claim (any more than I’ve done so in the past articles). I’m just stating my observations, experiences, and ideas on how to mitigate the situation.

Final Outcomes

Ultimately, I find that one of two outcomes will happen:

  • The person will be motivated and needs more information to get started.
  • The personal lacks motivation and desire to do more than the minimum amount of work. This will be a hindrance, but there’s very little that can be done about it.

Whatever the case: Don’t dismiss incompetence on its face. Perhaps the person needs more help. And in any case, good luck.

« Older posts Newer posts »

© 2025 Tom McFarlin

Theme by Anders NorenUp ↑