finally{}: I Just Can’t

ding – Subject line: Reminder to complete your student’s school registration.

A new email arrives.

Right, I need to get that done as soon as I finish work for the day.

ding – Subject line: Your domain names expire in 3 days.

Ack, I forgot to renew those last week. I need to get that done before they expire.

ding – Subject line: Did you get my email from last week?

What email? (scroll, scroll, scroll) Oh, there it is. Not sure how I missed that…

It starts to creep in, slowly at first—just a passing thought.

Oh yeah, Ticket #323 has been on the list for a while. I need to get that off of the list, but it’s not a high priority, so I have to do this one first.

A few days pass.

ding – Subject line: Have you had a chance to look at Ticket #323?

You can’t help but internally roll your eyes.

I thought you said Ticket #323 wasn’t an emergency, so why are you nagging me about it.

But externally, at least, you manage to say, “Yes, Ticket #323 is on my list, and I will get to it as soon as I finish projects x and y.”

ding – Subject line: Help! Our site was just hacked!

Ugh, hackers who break things on Fridays are the worst.

Evening plans are delayed and then canceled. You finally finish mid-Saturday. Your eyes are blurry, and your head hurts, but you have to get to the post office before it closes. You are just going to wait a minute to make sure everything really is…working…correctly…

ding – Subject line: Email doesn’t seem to be working

Oh no, I fell asleep, and now the post office is closed. I’ll have to go Monday morning before standup. Email isn’t working? I wonder if we are getting blocked because of spam sent out during the hack last night.

ding – Subject line: Second Reminder to complete your student’s school registration

Right, I still need to do that, but I have to check on the email issue before I do.

At standup on Monday, you apologize for being late because the line at the post office was really long. You try to get out of being assigned anything new because you have a bunch of old tickets you really need to clean out, but since none of those are priority tickets, you are assigned a “quick” task to do first to set up a coupon for the marketing department.

ding – Subject line: Any updates on Ticket #323?

Oh no, another email about Ticket #323, which I haven’t had a chance to do. I’ll get it done as soon as I finish what I’m in the middle of, and then I can tell them it’s done when I write back.

ding – Subject line: Need an update on project x from you ASAP

You look back through the tickets for project x and put together a recap of where things are which you present at the meeting. Ok, I’m back from the meeting, and I can finally get some work done.


WHAT?! Why would they send it out before I marked the ticket as done? I haven’t even started it yet!

You scramble to get the details of what this coupon code is supposed to do and frantically try to get it done as quickly as possible. At the same time, fielding questions and bug reports from each person in the marketing department and help desk individually telling you that the coupon code is not working. Meanwhile, Ticket #323 is long forgotten for yet another day.

And so it goes. There are tons of internet memes and commentaries making fun of people who can’t get simple little things done. A lot of it is targeted at Millennials who can’t “adult,” but the truth of the matter is that this is not laziness, a lack of intelligence, or an inability to prioritize the important tasks. This is burnout.

We are constantly inundated with communications. Finding quiet, uninterrupted time to complete tasks is akin to a quest for the Holy Grail at this point. When things are constantly interrupted, it becomes so difficult to complete even small tasks on time, and once we hit burnout, completing simple tasks becomes overwhelming.

There is no simple cure for burnout. It takes time to heal, sometimes a very long time. You can avoid it, though. Take a moment and evaluate how things are currently affecting you:

  • Are you avoiding things you used to take care of easily?
  • Is it becoming more common for you to get interrupted and never get back to finish your original task?
  • Are you forgetting things that you normally have no trouble remembering to do?
  • Are you having trouble sleeping at night? Do you fall asleep during times you don’t normally sleep?
  • Do you feel physically exhausted the majority of the time?
  • Have your eating habits changed, eating way more or way less than normal?

These can all be signs of burnout. So what can you do? First and foremost, contact your doctor and mental health care provider. If you do not have a mental health care provider, talk to your doctor about the best options for you.

Next, take a look at what is going on in your life? Is there a way to eliminate anything causing you anxiety or stress? Are there places where you can step back or decrease your involvement (even temporarily) to give yourself some time to do something relaxing and enjoyable (and no, that does not mean time to get caught up at work – it means a hobby or something done just for fun)?

This month can be rough for many people. While sources disagree widely on what month is the toughest on mental health, February is when most people give up on their New Year’s Resolutions and is considered a major low point for those who suffer from Seasonal Affective Disorder. With the recent surge in COVID-19 cases, supply chain issues, and employees buried under extra work due to staffing shortages, watching for burnout is critical.

Want to help? Now would be a great time to pass around a burnout quiz at work or host a learning lunch on identifying burnout. Remind everyone to keep an eye out for signs of burnout at the end of your next meeting. Even just a simple reminder in Slack that burnout is a real thing can help. Keep an eye on yourself as well as your friends and co-workers. Mental health is important, and so are you.

Originally published in “World Backup Day”, the March 2022 issue of php[architect] magazine.

finally{}: Every Which Way But Loose

I recently saw yet another discussion online about PHP’s infamous naming convention exceptions and needle/haystack rotations. All the typical vitriol was there from the PHP haters, but I was very happy to see several new programmers add to the conversation or ask for clarifications and receive very supportive and educational responses from the thread. PHP is nothing if not consistent in its status as a recipient of the internet’s hatred. However, I am forever proud of our community’s ability to ignore the hate and still welcome and encourage newcomers.

But do the haters have a point about our inconsistencies?

I mean, they are not wrong that sometimes it is “needle/haystack” and other times it is “haystack/needle.” Sometimes it’s “in_,” and other times it’s “contains_.” I freely admit to needing to check the docs or use tooltips in an IDE when using functions I don’t use very often because I can’t remember which way it will go.

**Is it phpinfo() or php_info()? vardump() or var_dump()? Has anyone thought of just fixing this? ****

Most definitely. In fact, PHP RFC Consistent Function Names (consistent_function_names) will turn seven years old next month. This RFC proposes renaming any inconsistent functions and keeping their old names as aliases. No backward compatibility issues. Everyone can keep using whichever version they want to. It seems like a proposal that would satisfy the people who want everything renamed and those who do not want the names changed. So what’s its status? You guessed it. After all these years, it is still listed as “Under Discussion.”

Why is it so difficult to make a decision on something that garners PHP so much hate? Especially when there is seemingly a perfect solution to make everyone happy? **

Well, that’s the thing. Despite how it looks on the surface, renaming and aliasing is not a perfect solution. PHP has had these function names for so long they are expected to be a part of the code.

Does this mean we can’t change them because we don’t like change?

Absolutely not. It means is that other libraries and codebases have been working around those function names for well over a decade or two. For many codebases, it means they have wrapper functions using the proposed standardized versions of the function names because they prefer standardization. Or they have built custom functions and used the proposed standardized function names because those weren’t reserved. Standardizing the function names and order of variables means adding a lot of new reserved function names that could break a lot of code.

Don’t we add new functions to PHP all the time, which does the same thing?

True, but in those cases, the BC breaks come with the benefit of new functionality. In this case, we would be introducing a lot of BC breaks with no new functionality.

Isn’t a better dev experience worth it?

Maybe. Consider, though, the huge list of amazing new features, security patches, bug fixes, and everything else on the horizon for PHP. Do we really want to spend our limited core developer time on something that only improves the dev experience for some devs. It is really hard to justify this when it means losing time to work on a new feature or fix that could improve things for all devs. When dealing with limited volunteer resources, there are lots of tough decisions to make.

But what about all the haters who say PHP is ugly because of this?

As the saying goes, haters gonna hate. In PHP’s decades of life, there have always been haters. No matter what we do, there will still be haters. Look at the amazing modernization strides that PHP has made in the last five years! The perception that PHP is old, clunky, and ugly is not based on legitimate facts but rather long-held biases. Those biases aren’t going to go away even if we made naming conventions perfect, which I’d venture to say that no language could truly achieve given the ever-changing nature of programming.

So is this a dead issue?

Definitely not! There is merit to the concern and potential in the suggested solution. It just isn’t the right time for this kind of a change, and that’s why as we draw near to this RFC’s 7th birthday, this continues to be “Under Discussion.”

Related Reading
– PHP RFC: Consistent Function Names

Originally published in “Parallelize Your Code”, the February 2022 issue of php[architect] magazine.

finally{}: Experts or Out-of-touch?

After talking to someone about ideas for new security education, I popped over to check out the latest OWASP Top Ten list. A quote on their homepage stood out to me:

This category represents the scenario where the security community members are telling us this is important, even though it’s not illustrated in the data at this time.

The experts in their community were telling them that a specific issue was critical and widespread enough to warrant a place in the top ten, but the data they collected from codebases and users didn’t reflect this at all. Is this because the issue is too up-and-coming to be reflected in the current boots-on-the-ground numbers, but we need to act now because it will soon be a huge issue? Or is this a situation where the experts work on a level so different from the standard developer that the security risk is only applicable to them and not in everyday circumstances?

This difference got me thinking about how PHP has evolved over the last ten years. I used to closely follow PHP Internals and even got involved in a few of the discussions. I felt like it was important for me to be involved as much as I could. After all, these decisions were affecting my livelihood and my community. After about a year, I started feeling like I didn’t have much to contribute to the discussion. The people making the decisions worked in such a drastically different environment than me, and neither of us could truly relate to the other’s point of view. Not to mention, my point of view was not the exciting, academic, cutting edge side of things, so that didn’t help either.

I stopped making comments and just watched the discussions – keeping informed while lurking. Slowly, though, I faded further and further from the discussions until I found I was months behind on reading the posts and just unsubscribed. I felt a bit bad about giving up on being involved in internals, but I didn’t have anything to say about closures or scalar type hints or inheritance by anonymous classes. Honestly, most of the projects that I was working on were companies just starting to upgrade to 5.4. PHP 5.6 was still out of reach for many of my customers when 7 was being prepped for release. Many of my projects were short-term or light enough usage that a full-blown, properly abstracted system was unnecessary and would create a painful complexity without providing any needed benefits.

The thing I most needed the core internals team to do was to avoid any breaking changes so I could get my clients to upgrade. Needless to say, that was not their top priority, and rightfully so. I needed consistency to decrease costs for my customers. The core internals team needed to modernize the language and add features and constructs to match what other popular languages offer. I was concerned about ease of debugging while they were concerned about ensuring that PHP enforced strict standards to remove ambiguity in coding and encourage best practices.

Who was wrong? Who was out of touch? Was I too entrenched in old code and projects on a tight budget to realize the importance of these features which I couldn’t imagine ever using? Were the core devs too focused on academic theory and too isolated within huge corporate infrastructures to understand what devs like me needed?

The changes made to PHP from version 7 and beyond have skyrocketed the language into maturity, sped things up considerably, and helped PHP gain some of the professional respect it truly deserves. These are all great things. While they were streamlining things and enforcing best practices, they made things more difficult for developers like me who work with small businesses, ancient codebases, and hosting companies unwilling to upgrade. In making things more advanced to appeal to senior programmers and large organizations, they upped the difficulty for anyone trying to learn PHP or debug unfamiliar code.

There is always give and take, a bit of pain with each step forward. Change is hard. However, the beauty of our community is that we are so diverse. We have a strong group with people who push us forward and other people that keep us grounded. Thanks to this, PHP supports a vast range of organization sizes and project complexities. From small shops that just need a contact form to companies supplying content and services to millions of users, PHP is out there solving problems of all shapes and sizes. When we encounter differences, remember: we are experts in our own experiences, and because those experiences are so different, there’s a lot we can learn from each other.

Originally published in “Domain-Driven Resolutions”, the January 2022 issue of php[architect] magazine.

Saying Goodbye

August will be my last issue as Editor-in-Chief of php[architect] magazine. I’ve been EIC for almost 6 years, and now it’s time for me to get back to doing PHP, not just reading about it. There is quite a bit of sadness mixed into the excitement of trying something new. The magazine has always been more of a passion than a job for me. There’s something so amazing about sharing knowledge, discovering new technologies, meeting the people behind the projects. It’s a beautiful thing, and I know that I will still be reading my subscription each and every month. It’s always sad, though, to leave something you love. Continue reading “Saying Goodbye”