Author: Tom (Page 7 of 426)

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

December 11, 2023 / Tom

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.

Someone Has Likely Already Written Your Blog Post

November 28, 2023 / Tom

This morning, I was going through my RSS reader. In one of the programming feeds that I read, I read two different articles both of which were talking about Git.

Each were talking about something that has been discussed I don’t know how many times over in the past by someone else:

Should dependencies be kept in Git or now?
And an outline of Git branching strategies.

It’s easy to look at posts like this – just like I can look at stuff I’ve written and realize it’s been discussed by someone else or you can look at stuff that you’ve written and find something similar has been written by someone else – and want to dismiss them.

That’s not the best way to think about publishing practical technical content, though. Even though someone else has likely already written your blog post, that doesn’t mean it isn’t worth writing.

You have a different audience than whoever you’ve come across. And although you may be reading something similar to what you’ve read or written, that doesn’t mean that whoever reads your site is reading those sites.
Writing for others is important, but it may be just as important if not more important than writing for yourself. Distilling your ideas into something that you can explain is incredibly helpful in making sure you solidify the information you’ve learned.
Writing something this year can be different than writing something a few years ago (and will be different in writing it in the future). The economy and environment changes fast.
The context in which you’re sharing knowledge and explaining your ideas may be similar, but not exactly the same, as someone else.

The next time you attempt to write about something and are skeptical if you should hit publish or not, go ahead and hit publish. At best, you’re helping yourself and maybe someone else will come across what you’ve shared; at worst, you’re sharing something someone else has shared but it’s unique to what they do.

And since similar isn’t the same as unique, the value of publishing what you have to say is greater than not.

Thanksgiving 2023

November 23, 2023 / Tom

For nearly every year I’ve written, I’ve made sure to publish a post on the end-of-the-year holidays here in the United States.

Happy Thanksgiving! — This is the earliest Thanksgiving photo I have in my library.

It’s neat to see what I wrote on this day 10 years ago in comparison to now:

For those of you who are in the United States and are celebrating Thanksgiving, I hope you guys have an awesome day hanging out with your family, friends, eating, sleeping, and generally enjoying the day off.

A lot has changed both personally and professionally since then (though I’m still working in the same industry and enjoying it as much as I always have), but the message is consistent: If you’re in the US, I hope you enjoy the time off; if you’re elsewhere, I hope you enjoy whatever you’re doing today, too.

How To Mitigate Side Effects in WordPress Development

November 22, 2023 / Tom

In software development, the concept of a side effect is generally understood to be something like this:

In computer science, an operation, function or expression is said to have a side effect if it modifies some state variable value(s) outside its local environment, which is to say if it has any observable effect other than its primary effect of returning a value to the invoker of the operation.
Side effect, Wikipedia

The Software Engineering Stack Exchange has a great answer. You can read it in its entirety, but I really like how succinct the person puts it:

It’s really very simple. Side effect = changing something somewhere.

There are a handful of ways developers try to mitigate side effects such as automated testing or quality assurance, but when a piece of software is large enough such that each part that composes the system is like a small system unto itself, it’s not difficult to imagine how introducing new code could inadvertently change the state of the program.

This is why any given project at scale is impressive to see work as smoothly as it does. (Sure, projects like large scale web applications, operating systems, are one thing but thinking about medical software, automotive software, the software that runs on airplanes, applications built at places such as NASA, and so on are all the more amazing.)

Bringing this down to the level of stuff I write about and that I work on during my day-to-day – specifically WordPress – side effects are something we’re likely all too familiar with experiencing.

If nothing else, think about the last time you activated a plugin and it immediately conflicted with another plugin or a feature of theme.

It could have thrown up a notice,
It might have displayed an error message,
Perhaps it completely broke the way some part of the way the core application functions,
Or it just threw up a PHP error message that wasn’t even clear on what was going on.

To make matters even more fun, the only way to resolve the issue is the disable the plugin via WP CLI or, even more drastic, deleting the plugin.

This is an obvious example of a side effect in WordPress. They can happen for any number reasons, too. Sometimes it’s a matter of running a different version of PHP, it could be a matter of a team not keeping their code contained in its own namespace, or perhaps it’s a matter of not doing enough testing.

Regardless of the case, it’s something many of us have experienced and it’s likely a problem many of us have caused during our careers.

Initially, when I started thinking about side effects in WordPress development, I was working on a plugin that needed to fire when certain events happen during the user management lifecycle.

From there, I started thinking about edge cases and then I started thinking about the overall economy around WordPress and the interoperability and compatibility challenges that come with writing software that runs on top of a piece of open source software that powers so much of the web.

It’s impressive.

Then I was left at a fork of what I wanted to discuss:

Should I talk about the initial problem that kicked off this entire post (that is, making sure I handled all cases of user management)?
Or should I offer general commentary on edge cases and how it relates to work in building WordPress or WordPress adjacent projects?

If you’ve read this far, it’s obvious that I’ve spent more time on the latter than the former. So I’ll save the former for another day.

Since I’ve discussed this at length already, these are a few things – in no specific order – I recommend doing the following things to prevent side effects and conflicts when working on WordPress-specific code:

Even if you’re not using object-oriented programming, use namespaces to keep all of your functions contained within their own context.
Know the environment(s) in which you’re code is going to run and write for the lowest supported version.
When writing a custom function that will fire on a specific hook, take the time to understand the priority and number of arguments the function will expect and write your code defensively (that is, ask “how would I write this code so someone else’s won’t interfere with what I’m trying to do?”)
Don’t be afraid of writing unit tests not only to ensure your code is doing what it’s supposed to do but also that it’s not doing anything it shouldn’t be doing.
Before writing anything to any type of storage, make sure that the keys you’re using are not already in use and/or make sure to uniquely prefix the keys you’re going to use.
Don’t add frontend assets to any page that doesn’t need them.

I don’t know if it’s possible to put together and exhaustive list. But in my experience, these are the things that I’ve found to be helpful especially as it relates to working on backend development.

Asynchronous Methods and Headers: Just Working Isn’t Good Enough

November 17, 2023 / Tom

When sending asynchronous requests to a WordPress back-end, which may be a REST API or an Ajax callback, it’s helpful to know what headers to specify when sending said data.

Since I recently shared another post about idempotency in REST API design and since asynchronous calls are more common than they have been in the past, I thought it useful to share when to use what type of headers when making said requests.

If you’re working with WordPress in some capacity – be it a headless state or working on processing Ajax calls – then it’s useful indicate how your data is being sent and in what format the data is being sent. Ultimately, your asynchronous methods and headers need to do more than just work.

That is, it’s not enough for it to simply be sent and received. Instead, the data should be sent in a format congruent with what the backend service expects. If anything, future you will thank you. To make it even more relevant, this is an opportunity to keep our code as clean as possible.

Asynchronous Methods and Headers

When creating an Ajax request in WordPress using modern, vanilla JavaScript the request will likely look something like this:

fetch(tmAcmePlugin.ajaxurl, {
    method: 'POST',
    body: data,
    credentials: 'same-origin',
    headers: new Headers({
        'Content-Type': 'application/json',
    }),
})

Notice here I’m specifying the headers as part of the request which isn’t something we’ve historically done. In this example, I’m using application/json.

It’s also common to send form data across the wire, too. And if you do that, then your request will look something like this:

fetch(tmAcmePlugin.ajaxurl, {
    method: 'POST',
    body: data,
    credentials: 'same-origin',
    headers: new Headers({
        'Content-Type': 'application/x-www-form-urlencoded',
    }),
})

Obviously, know which type of header to send and when is important. As obvious as it seems, these are the guidelines I recommend when working in the context of WordPress-centric applications.

Use application/json whenever you’re sending a payload that’s structured as JSON. Whenever you’re receiving the data on the server, you’ll need to use json_decode or your language’s equivalent to parse the data.
Use application/x-www-form-urlencoded whenever you’re sending a payload that comes from data being sent from a form element or in a string of key/value pairs such as key_one=value_one&key_two=value_two. Typically, this will be received in a POST request.

Again, however you specify the method and the header, the data will still be sent but how you manage it on the server may not match up to what’s expected.

If someone else – either someone with whom you work or just future you – reads the client-side code and the server-side code and what’s sent doesn’t match, it’s going to create an entire set of circumstances of detangling what’s been done and something that’s completely unavoidable.