In the spring of 2015, I became a WordPress contributor, more or less without realizing it and without anticipating what the impact on my personal and professional life would bring.

I have been using WordPress to make a living since 2010 but never knew the open-source project needed contributors from people that were not PHP developers — in my mind, that was the only skill required — I was clearly wrong.

I first started translating WordPress into Italian and then moved to volunteer in the Community Team, the team that oversees and supports all official WordPress events around the world, and now online.

In 2019 Josepha Haden reached out to me to know if I was interested in being part of an upcoming release as the coordinator, and thus my new path in WordPress contributing started. I had the immense pleasure to co-lead two major releases, 5.3 and 5.4, with the role of Release Coordinator. Now I am mostly doing what I love best: mentoring new contributors in their own path, thanks to my new role at Yoast, as the WordPress Core Team Lead, where I get to contribute to open source full time.

Open Source Fundamentals

The book “The Cathedral and the Bazaar” by Eric Raymond, is still, after almost 30 years, a must-read for anyone dealing with open source.

If you haven’t read it yet, I suggest you do. It might be outdated in some sections, and it infuriates me that the author only mentions men, some of whom turned out to be very toxic for open source, but it’s still a must-read. I go back to it quite often in search of motivation.

It mentions several lessons. Amongst them, the most widely known is lesson 1:

Every good work of software starts by scratching a developer’s itch.

This is the starting point for lots of contributors.

I would replace the word “a developer” with “someone”. The key concept here is that you need to start somewhere, and starting from something that you need a solution for is a great idea. It might be something that puzzles you or something you need to solve to move forward with your project. Or you want to learn about something, and you can learn by doing.

Lesson 18 is also a good reminder of why we contribute to open source.

To solve an interesting problem, start by finding a problem that is interesting to you.

Ask yourself: what interests you?

Be Selfish

These two lessons make it clear that we are the masters of our contributor destiny, and we should pick projects that are interesting for us and that we are excited about fixing.

So yes, be selfish.

If you pick something you use daily, it will be easier to get started and continue.

And don’t worry about making small changes. I started by translating as many instances of the days of the week from English to Italian. It might sound trivial and meaningless, but those words needed to be translated, and someone did it. Then I moved on to more complex translations, but it was great to be able to start from something small and fun.

Also, don’t worry about the next step, getting more involved. It’s absolutely ok to keep doing things when they feel right for you. So it can be a casual relationship.

The next step: get more involved

If you do enjoy it, the next step might be getting involved more actively and continuously. That’s usually the point where you realize
* What an impact doing small changes can have.
* There is usually some form of communication to coordinate all these individual efforts.

In WordPress, for example, there are blogs for the different teams, we use Slack for communications and Trac and GitHub for development and bug tracking.

You can start attending chats or calls, even as a listener at first, and then when you feel ready, you can definitely connect with other people and participate more actively.

Learn

On the way, You will learn lots of things.

For example, you’ll use tools that you have never heard of before or processes that you are not familiar with.

You can also improve your existing skills and acquire new ones. Thanks to WordPress, I improved my English a lot. I started learning about conflict resolution and project management. I became more assertive and patient and learned how to delegate and mentor.

Very tangible results.

You will make new connections: they can become business partnerships or friendships. Both are important in our lives. And you could spot new opportunities for your professional advancement.

Be ~~selfless~~ generous

I talked about being selfish, but when I started contributing, everyone told me to be selfless.

For me, the words selfless and selflessness are problematic. Mainly because I am not a native English speaker, so that “less” sounds like you are erasing yourself, but you are actually the most important resource in the process. So I prefer generosity or altruism. This is where contributing to open source becomes about the others.

I see this a lot in contributors. At first, we learn, we do, attend, propose, fix, give feedback, be vocal, etc. Then a lot of people move into the background and start helping others go through the first step. This is how you make sure you get new energies into a project.

So we go back to Eric Raymond and Lesson 5 that is both about being selfish – if something doesn’t interest you anymore, give it away – and be helpful by thinking of who is coming after you.

When you lose interest in a program, your last duty is to hand it off to a competent successor

Here are some examples of how I was both selfish and generous in different contributions I made in my life, not only in WordPress.

• I get to mentor new contributors in Core, especially people who identify as women and underrepresented groups who want to start public speaking. Others helped me when I started out, so I hope I can assist people in their path to contribution or in their public speaking adventures. I love doing this more than anything else, so it’s great that I can be generous with my time and knowledge. And mind you, it’s also selfish: the more underrepresented groups in tech take the stage or become visible contributors, the more I can move on to do other things that interest me.
• I learned to delegate. I was one of those people that complained about others not doing enough. It turned out I was doing too much, and I was holding everyone, including me, to unsustainable standards. I am now a lot more selfish! I don’t want to work sixteen hours a day, so I work eight and delegate the other eight. This is also generous: I am sharing my knowledge so people can learn.
• The most selfish thing I do is document as much as I can so in case I lose interest, someone can take care of all these projects. And for me, documentation is also the highest form of generosity in contribution. Without it, it’s impossible to recruit and empower. Lots of projects, not only open-source, are at risk of dying a slow and painful death if we don’t ensure continuity.

What’s in it for me?

After five years of solid contribution, I still think being clear on what you are getting is a major drive to succeed in long-term contributions. And it’s not necessarily profit-driven or about raising your profile.

• The sense of accomplishment and pride you feel when you make a change is a big mood enhancer. The worst my day is going, the more I turn to contributing to feel that I am making a difference for millions of people. For me, these are my main “What’s in it for me”.
• Validation. Positive feedback about our ideas and work is always great.
• I think recognition is also important and it comes in different forms. If you have kids, you might have used a rewards system when they grew up if they finished their tasks. It’s an excellent system. All gamification processes are based on that. In WordPress, we have badges
• And finally, it will help build your skills and put together a better CV in case you are looking for a job. I put it last because if this is your only motivation and your contribution is clearly and only selfish, I am sorry. I am also pretty sure it won’t work after observing hundreds of contributors. Companies that hire through open-source see through this quite clearly.

Your one takeaway

To sum it all up, I would like to finish with a quote from a WordPress Core Committer, a former release lead, and my life partner, who I happened to meet at a Contributor Day. So yeah, Contributing is always a good idea. It could even help with your love life!

Make it better, give it back
John Blackbourn

Not too long ago, a mistake I made caused a few thousand wrong emails to go out to customers. I edited the untested code and didn’t bother to add tests. Fortunately, the bug was discovered and fixed. After this happened, I wanted to add some tests to this code, but I soon realized the tests wouldn’t have found the original bug.

The problem? Mocks not reflecting the truth.

The script

We started with a piece of code that looked something like this:

It fetches all users with a specific state, sends them a mail, and gives them another state. This is by no means a perfect piece of code, but it has been working for many years and made the business money.

Now, some of our business logic had changed, which introduced a new state. The script had to be updated.

Mind you this didn’t introduce a bug yet, the code got worse, but it was still correct. State 3 was readyForMail, state 5 was also ready for mail, but with another precondition. A colleague was quick to point out that we now have an enum like object for user state, and that it would be more logical to use that. So I updated the code, the merge request got approved, merged, and deployed.

Can you spot the bug?

Now all accounts with the normal state would also receive the mail. The correct state that should have been used was AccountState::preConditionReadyForMail(). It was discovered quickly, but not before a lot of customers had received an email.

The tests

A mistake that could’ve been avoided, had I added tests. So then the job came of adding those tests. So what did I want to test? The user had to be fetched, the mail had to be sent, and the correct state had to be set back. The mock of the repo was configured like so:

I ran the tests, and then they passed. Then, just to be sure, I changed the code back to the ‘bad’ way, where all the normal accounts would also receive an email. But the tests stayed green. I could pass anything into the findAllByState method, and the mock would always return these two objects.

The method could be used wrong, and the mock would hide it.

Now you might say, that I could add a check on the mock, to make sure it was called with a specific object. I’ve found that those kinds of checks are very prone to just being copy-pasted from the original code. Especially if the values there are hardcoded.

We needed a better solution.

The solution

Stop using mocks. That’s it, that’s the fix. Or at least it’s half of the fix, we don’t want to use the database in our tests, so we still need something to use in the test. The solution is a new implementation of the UserRepository. The one in the code can be backed by a database, while the version for the test is based on an array.

And now we can use this repository in our tests, and when we use the wrong account state, the test fails.

By using a new version of the repository, we could make sure that the code using the repository does so correctly. You could argue that the test has now become an integration test, rather than a unit test. As it also tests the integration with the repository. And perhaps you are right. But I would still prefer this way of testing over mocks, as there is less chance of erroneous tests.

The other tests

We’re not done yet. The new MemoryUserRepository should work the same way as the other versions of the UserRepository. So, we need to add a test, to make sure all work the same. What I like to do is create a base TestCase class, where we define the tests. It has one abstract method, which will return an instance of the UserRepository to test against. This way we know the different repositories all work the exact same way. In the database version of this test, you could have a setUp and tearDown method to make sure the database gets reset to an empty state again.

So what do you think? Are you already using your own implementations during tests?

Or do you think mocks offer advantages over custom implementations?

Some years back I was sad that PHPAdvent was not happening. And as the saying goes: If you are missing something, then you are the one responsible for it to happen. So I decided to make it happen. And I started this blog.

I invited people that I knew, to write about whatever they wanted. If it was something about the Community they feel at home with, that’s great but in the end I decided that it was their blogpost. So whatever the person felt right was right.

But gosh! That was draining. To be honest, it was exhausting. Starting at the beginning of November I reached out to get folks to write something for December. And that usually got me covered for the first few days. Of course – as time goes by – I got some more ideas of whom to invite for that year and about 50% committed to writing something. And a good number of those got their contributions in well in advance. And then there were those where I was literally having sleepless nights as, when the post should have been published, nothing was there. So I moved contributions around or wrote something myself.

And in these for me challenging times I learned one of the most important lesson for myself: When I told people the problem: There is no post for today due to reasons – I got one or two people writing something almost immediately. People do not want to see the project fail! People do not want to see you fail! Thank you Cal Evans! Thank you Stefan Koopmanschap! You saved me more than once!

In addition to this I learned so much from organising this project. I learned about the challenges of working with people from different time zones. I learned about different ways of handling deadlines. I learned about different ways to say “no”. I learned about diversity and that it is not really easy to get a diverse mix of contributions. I learned about different mediums of communication throughout the world, I learned about how hard it is to get contacts in some local communities.

And last year I learned how much easier it becomes when you share the burden between different people. Thanks Jonathan and Claudio for joining in.

And this year I learn how difficult it is to let go.

Jonathan and Claudio do an awesome job! Everything just falls into place. They struggle with the same things that I struggled with (usually between the 6th and the 10th to 12th there is a gap that needs to be filled somehow) but they manage to get over that with such an ease (from what I see) that I’m really envious! But it is still difficult to “let go”. To not have the final say in who’s going to write. To accept that we’re publicly asking who wants to contribute (That was an awesome idea – even though it wasn’t mine). To see that they are doing an awesome job without needing me.

Letting go isn’t easy. Handing over a project that is dear to me isn’t easy. But handing it over to people that do such an awesome job with it and that are so enthusiastic about it is the best that could happen to me!

So what do I learn from that? Try not to do it on your own. While it was fun to do it on my own it was much more fun to do it with others. And by inviting others and showing them how to do it and mentoring them, they can take over at one point. And then the most important lesson is: Hand over the baton! They will manage to do it on their own! I am still around for questions. But so far they didn’t need me.

So finding the right time when to hand over the baton might be a tricky part. Too early and they are not ready yet, too late and they think you won’t let them do it on their own. There is no mathematical solution to it. Perhaps if you think they are not 100% ready yet is the best point in time to give it a try. The missing stuff is then “training on the job”.

So the next time, you think about how to hand over this project of yours or how to pass on responsibility, think about who might just not 100% ready for it and talk to them! And the moment they ask you about taking over responsibility: Rest assured that they are ready!

The Physical Herd

When March rolled around, we quickly shifted gears to working and going to school from home. I’d been working remotely for nearly a decade, and I thought the transition would not affect my routine. In many ways, it didn’t alter my daily routine. However, one of the markers for me that 2020 was not a typical year was not going to a PHP conference or user group meetings. While I’m firmly in the introvert camp, I missed the energy and camaraderie they provide. Although many events and groups pivoted to online-only affairs, it’s not the same thing—the talks you go to are only one part of it.

At a local level, user groups can be welcoming and an easy way to meet like-minded developers. If you’re looking for work, networking with local companies can bypass HR. You can get to know the lead developers, and more importantly, they can get to know you. If you want to present a talk, organizers are always looking for presenters. Telling the group about a service, framework, or library you use is a great way to get started. While many groups have a Slack or Discord channel you can join, it’s challenging to replicate the energy of having all the members together for one night. I have to admit, I haven’t been a regular attendee at my local PHP UG, but going to the Drupal meetup near me helped me make new connections, give PHP classes, and try out new talk ideas.

Most PHP developers may never attend a PHP conference, but they’re vital to the global PHP community. Where else might you see core contributors chatting in the hallway or making elePHPant movies? Did you know the PHP FIG got its start from discussions at php|tek in 2009? For every attendee, a conference is a chance to meet the maintainer of that library you use all the time and give them feedback. It’s a chance to get to know what kind of business someone runs while you play a board game one night. And, it’s a chance to get to know someone beyond their Twitter handle while you check out a local restaurant for dinner. Yes, you’ll be going to excellent talks throughout the day—but, believe me, there’s more to a conference than the scheduled talks. You never know what might happen at a conference. Before you know it, you’re publishing a magazine and books with the help of the folks you met at one.

Elephpants need to congregate. Getting together with PHP devs isn’t just about the professional connections you can make. The people you meet at a conference or user group are bound to share some of your non-coding hobbies. Most Saturday nights, I play Dungeons and Dragons online. It’s one thing that’s undoubtedly helped me make it through this seemingly interminable year, and all the players in it are friends I’ve made through PHP conferences. If anyone is suited for delving into dark, dangerous places—it’s us.

Will user groups and events come back? I sure hope so. But I know that just wishing it won’t cut it. When it’s safe to get together again, we can all revitalize our user groups by taking the time to attend. Maybe reach out to the organizer and offer to give a talk. When it’s safe to travel to a conference, convince your boss that it’s time worth sending you or even look at sponsoring it.

I hope to see you at one in person soon.

If you had told me one year ago that I’d be working from home full-time within one year, I’d have laughed. A lot of companies did not seem to care much about remote working. And even if they’d allow it, it was mostly just for one day a week, or two days max. The reasons weren’t always clear, but based on what I heard I determined that it mostly had to do with either trust issues with the direct managers (scrum masters, team leads, etc) who wanted to be able to actually see you do your work, or it had to do with the inability or unwillingness of upper management to facilitate remote work.

Now I’m not going to say that the trust issues or the inability or unwillingness changed from one day to the next due to people seeing the light of remote working, but let’s just say a virus did change one thing: The necessity to allow remote working. In many countries, it is currently prohibited or at the very least strongly discouraged to work in the office if it is possible to do your work from home. And if there is any job that can be done from home, it is developing software.

Or is it?

The pitfalls

There are several pitfalls, things you should try to avoid. Some of them may be out of your control, but even when they are, being aware of them allows you to try and get the right people to solve them for you.

Connectivity

If your company has its security in order, there is a good chance that connecting to the servers of your company may not be possible unless you’re in the office network. This usually means you need some kind of corporate VPN. Depending on your company structure, obtaining that may take some effort. Chase the people down that have to arrange this, especially when you can’t do your work without the VPN.

Sometimes, however, the VPN will be available, but there may be a clash between the IP ranges of your office network and your local network at home. If you want remote working to succeed, you need to be prepared to update the IP-range of your local network.

Communication

When you’re in the office with your colleagues it is quite easy to communicate with each other. Every gesture, every word you say is seen and heard by the people around you. When you get up to get some coffee or water or head to the toilet, people see that happen. When someone comes to your desk and you’re not there, they see that you’re not there.

When working remotely, this is different. People can’t see where you are or what you are doing. So it’s important to be quite “noisy” in the Slack, Teams, XMPP, or other communication media your company uses. Managing expectations is important here: when you’re not at your keyboard for a bit, let people know you’re gone for a bit. When you’re going to focus for a while, let people know so people know not to expect an immediate response from you. This is extremely hard, even after all this time I don’t always do this either. Try to do this as much as possible. This will prevent a lot of frustration on the other side.

Another important thing to realize is that written text is different from spoken text. You’re missing body language, intonation, basically everything that communicates the intent of what is being said. So when reading things said by your colleagues, take a bit longer to understand how things are being said. If it is unclear, ask for clarification. Try to minimize assumptions when communicating in written text.

Distraction

One of the things I hear most from my fellow developers is that they easily get distracted at home. When you work in the office, you go there with a single purpose: To do your work. When you’re at home, you’re surrounded by things that are not related to work at all which you would give attention to when you would not be working.

If possible in your home situation, you should try and create a separate place where you can work which is away from your normal living situation. Preferably a separate room, but having a desk somewhere in a corner works as well. The most important purpose is to try and create a separation between work and the rest of your life. What can also help is not turn on the radio but listen to music on headphones, because that creates a certain isolation. Additionally, every once in a while, embrace distraction. When you’re in the office you get distracted by colleagues, by grabbing a coffee or some water, etc. Allow yourself some distraction at home every once in a while by cleaning a bit, doing the dishes, or put laundry in the machine. After you’ve allowed for the distraction, it will be easier to focus.

The joys

Working from home can also give you much joy. So let’s also focus on the positive side of working remotely.

No travel = more time

When you’re working from home, your commute is basically from the moment you get up to work until the moment you sit down at your computer. Because there is no travel involved, this saves you a lot of time. Time you can spend on other, more fun stuff.

Take some extra time in your day to read, for instance. This can be a work-related book, but also whatever book you like to read. Perhaps you’re more into gaming. In that case, if you start a bit earlier (there’s no travel, so why not?) take an extended lunch break and play a computer game after you’ve had your lunch. This helps you unwind from your work for a bit and you’ll return to work ready to take on the world again. One thing I’ve started doing every morning before I sit down at the computer is to take a walk. My Apple Watch tells me I should be doing a minimum of 30 minutes of exercise every day, and I get it out of the way early in the morning. I take a brisk > 30-minute walk which gets me my exercise, but also ensures that once I sit down at the computer, I’m wide awake and ready to get cracking.

Get your chores done

Wherever you work, you should take regular breaks. This prevents work-related injuries such as RSI, makes sure you don’t wear yourself out and are able to concentrate, and keeps your body in a usable state. While at home, there is nothing stopping you from using break time to do some chores. As I mentioned before when talking about distractions, it’s fine to do the dishes, put some laundry in the machine, vacuum the room, etc. It will take your mind off work for a bit (which is good) and again save you some time that can be spent on the fun things in life.

More focus

One of the best advantages of working from home is the fact that there are fewer colleagues interrupting you from your work. It is easier to ignore a chat notification than it is ignoring a colleague standing beside your desk. So make use of that added concentration to get more work done. That feels more rewarding to you, and your boss will be happy as well. And not unimportantly: If the world ever goes back to the old normal, you’ve proven you can work from home and if you want might be allowed to work from home more often.

Ordinary world

We’re living in a very strange world since COVID-19 hit. We have no idea if we’ll ever go back to “the old normal”. I, for one, hope this crisis will teach us that maybe, we don’t even want to go back to that version of normal. The perfect ordinary world after COVID-19, at least for me, allows for much more choice for employees. And one of those choices is to allow for more remote working. The fear that many managers have had in the past has turned out to not be such a big problem after all. And remote working is not for everyone, so it would be great if employees simply get the choice: Work in the office, work remote, or mix it up a bit.

Above all, I hope that your 2021 may be better than your 2020.

Many years ago a very talented famous American professional basketball player kept skipping team practices and it culminated in a press conference where he complained that “it was just practice” and not the game. In his opinion, it was the game that mattered, not how hard he worked. In other words, results-oriented thinking. He felt his natural talent (which was extraordinary even by the standards of elite-level play) was enough for him to succeed.

This was in sharp contrast to most of his other peers, who used practice as an opportunity to hone and refine their skills while also helping their teammates get better at the same time. For them, practice was the only time they had to try and get better when the stakes were the lowest. In other words, process-oriented thinking.

So what does sportsball have to do with programming? I’m of the opinion that practicing and refining your tools and skills (meaning process-oriented thinking) will lead to better outcomes. Our industry is clearly one that focuses on results-oriented thinking due to the huge amounts of money that are out there to be made solving problems for people. At the end of the day, we do need to get what we’ve been working on out there for people to use but in my experience, the journey can be made a lot smoother through, well, practicing.

For me I think there is a tripod upon which all your programming outcomes rely on:

• operating systems
• editor
• language features

By refining and practicing your use of these three things, you build a very stable platform to keep building your own higher-level skills and help other people get better.

Operating Systems

There are two operating systems you need to worry about: the one you develop your code on and the one your code will be running on. They’re not always the same so it’s important to learn what matters when it comes to PHP:

• do you have to deal with a case-sensitive file system?
• how to you install libraries and other tools you might need?
• where are the error logs located?
• how do you stop and start services
• how do you upgrade the OS itself?
• is there an easy-to-use shell?
• can you use tools with a GUI?

Lots and lots of weird behaviour in an application can be traced back to subtle differences between the development environment and the production environment. Understanding those differences can really cut down on debugging time. Practice things like removing and re-installing packages, or turning on automated system updates. Learn about file permissions. You never know what might be causing a problem: system error messages are often cryptic and not actually pointing at the real problem.

I have been a long-time Mac user and appreciate the combination of a terminal shell when I need to work from the command line and the multiple options in terms of helper applications. Here are some things I use just about every day:

• graphical Integrated Development Environment (PhpStorm)
• graphical Git client (GitKraken)
• graphical MySQL client (Sequel Pro)
• graphical HTTP client (Paw)

All designed to help me get things done faster while also fitting with my own “way of doing things”, which consists of finding tools that allow me to automate a lot of things I used to do manually. Much like my editor, I practiced with other tools to find ones that (to use a sportsball metaphor) “fit my game”.

Editors

As someone who has switched between a lot of editors over the years before settling on one (PhpStorm + Vim for everything else), I can tell you that you can definitely produce code faster by learning your editor’s features. Pick one and learn it really really well. It literally doesn’t matter which one you use.

Here are some things that I learned to do with my editor via deliberate practice:

• refactoring
• keyboard shortcuts
• installing third-party plugins
• configurable layouts
• code generation
• syntax highlighting
• style checking

Spend deliberate time looking at these features and learn how they can help you. As a dedicated lazy programmer, I believe in letting the computer do as much of the work as I can under my watchful-yet-distracted-by-my-phone eyes. Your editor is the programming-related tool you will likely be using the most next to your brain. Pick one and learn it well — it doesn’t really matter which one.

As for all those features I mentioned above? I find them useful but they might not work for you. Try things out, deliberately force yourself to use them. When I was first using Vim, I forced myself to not use the arrow keys so I could master moving with the “traditional” HJKL keys instead. My interests are always aligned with automating things I am prone to make mistakes on so I can concentrate on things that require paying closer attention.

If people write books or create courses for better understanding your chosen editor, I encourage you to support their efforts by buying them and doing more deliberate learning and practicing.

PHP itself

I first started using PHP when it was making the transition from being purely procedural to having object-oriented features. To be sure, I did not keep up with a lot
of the changes because they just weren’t important…until I started having problems keeping my code organized as the projects got more complicated. Just like with my other things I suggest practicing on to learn if they “elevate your game”, here is a shortlist of features you should at least try before dismissing:

• return types
• parameter type hints
• interfaces
• abstract classes
• final classes
• traits
• functional programming paradigms

Explore the language, practice things, and refine your “solving problems using PHP” skills. A lot of concepts I was struggling to understand their usefulness became a lot clearer with deliberate practice via tutorials. You might not find any of these features useful in your own PHP work, but think of them as participating in drills where you work on different sets of skills to try and improve your overall level of ability with the language.

Following tutorials and then trying to adapt the lessons to your own codebase is some of the best practice you will find. It won’t always work but I can guarantee you will learn something you didn’t know.

Practice Raises The Floor

There is an idea that people do not rise to the occasion when under stress — they instead retreat to their lowest level of “unconscious ability”. This is why a lot of athletes practice things with such conviction — they are trying to train their mind and body to do extraordinary things without having to actively think about it. We can do the same thing by practicing with our tools and PHP itself to raise our own skill floor. Every time I apply something new I recently learned, or take a look at a tutorial, I look at it as a chance to get better. Failure is a natural part of programming, so embrace the failures that come during practice as the learning opportunity they are.

Happy Holidays to those who choose to celebrate this year!

It’s funny how every day I see some form of this question being asked online.

Yes, I do spend a lot of time around Twitter but still… it’s kind of weird, don’t you think?

For me, being so much into PHP and knowing pretty much everything that’s going on, it makes me wonder… why would anyone think otherwise?

Usually, this question comes from people looking to get into IT (or programming more specifically) for the first time so it’s a legitimate question to ask.

The idea is to be as effective at getting that first job as possible, and for good reason.

I also see many people responding to it with things like: “no, PHP is an old ugly language that is getting obsolete”.

Is it?

Most of the people who express themselves in this way are talking about a picture they saw of PHP in the early days (back at version 3 or even 4).

I’ve been there and yes, PHP was a mess back then.

But things got WAY better over time.

For me, the birth of PHP 5 (especially 5.4) was a tipping point.

Something broke there… in a good way 🙂

From there on, every new version brought us more and more cool features, new ways of expressing our algorithms, and also great performance improvements, making current PHP comparable to any other modern language out there.

Of course, keeping backward compatibility has always been a challenge and it would have been much easier to simply take it all apart and start fresh.

But that would also have meant leaving almost 80% of the web without support… I don’t think anyone wants that 🙂

So, back to the original question: yes, you should definitely learn PHP in 2021.

In fact, one of the great aspects of PHP is it’s huge and friendly community.

There are plenty of resources from where to learn.

I know for some people not being English-Fluent is a barrier, that’s why I create most of my content in Spanish because I know of the potential PHP has and I think it’s a shame great programmers get left out because of their not-so-great English skills.

So, in summary, being so close to New Year, go ahead and put “Learn PHP” into those resolutions.

You’ll thank me later.

It has been quite a year, has it not? We will remember 2020 for a long time to come, with shelter-at-home orders, restricted travel, not meeting friends, family, and the wider PHP community. It has been quite a lonely year, as we find that although Zoom is great for doing meetings in your pants, it is by no means equivalent to sharing a beer, laughs, and arguing about Attribute Syntax or which PHP versions should be supported by Open Source tools at a user group or conference. I am really missing it, and you.

Now most of us are stuck at home behind our screens, it is easy to forget that when we write down our arguments and gripes in issues, email, and not to forget on Twitter, that there is a person on the other side of the communication channel as well. And that person is going to have to read your rant on whether the bike shed MUST be purple with pink polka dots, and definitely not the more sane green colour.

In the last year, I’ve seen various posts by maintainers of Open Source software stating that their users are ungrateful when they complain and expect their problem to be solved straight away. Sometimes this stays as a single comment, or they call it “crappy software”, but sometimes words get way too strong, essentially about something that is being given to them for free—software written by a maintainer in their free time. I certainly have had a few rants directed at me for Xdebug for it wasting time, which I find amusing as the sole drive behind Xdebug is that it is going to save users a fuck ton of time. I digress.

I think that as a community we need to acknowledge that there is probably more twaddle thrown at maintainers of Open Source code than they deserve. In the end, they spend a lot of their spare time creating useful things for the world at large. There is definitely no requirement for maintainers to spend more time on problems that a user has, or thinks they have. How can you even require people to work on free stuff in their free time?

But does that mean that that absolves maintainers from not caring about the users of the code they have made public? It depends. Some Open Source code gets written to scratch an itch. I wrote VLD, a tool that shows the internal operations of the PHP engine, to assist me with developing and debugging Xdebug‘s code analytics routines. When I started this, no other such tool was available, so I made this Open Source for others to use if they want. I do not provide any support, and will immediately say “Pull Request welcome” if somebody runs into a problem. I can justify this for VLD, as it is a very low-level tool and only useful for people that know the PHP engine fairly well. VLD was primarily written for me.

Much Open Source software starts out that way, but at some point, things can get out of control. When I started with the development of Xdebug 18 odd years ago, it was also very much for my own benefit. Mostly to learn a little about how the PHP engine worked, and how I could prevent infinite-recursion from crashing the engine due to a stack overflow. But as you know, this got a little out of hand and I’m still here supporting, upgrading, and improving it, recently culminating in the Xdebug 3 release.

For a part of the 18 years that Xdebug exists, I did not actually write a lot of PHP code. I continued maintaining Xdebug for the benefit of PHP programmers at large. I would even go as far as to say that I felt that I neglected its users by not having as much time to work on it as the software deserved. Now that there are so many users, there is an implicit bond between my Open Source side project and its users, and I believe I owe the users at least something. If I did not want that, I should not have chosen to publish the tool that I wrote to scratch that itch as Open Source. But because I did, the question becomes rather what sort of expectations users can expect, and what I’m willing to provide.

Acknowledging Pull Requests and issue reports? Yes. Support questions in a public forum? When I have time. Private questions? Probably not. Free 24/7 phone support? Fuck no.

I am open to providing private support for Xdebug’s users, but only for users who have signed up for a paid support package. But still no 24/7 phone support, I’m not stupid.

By publishing your code as Open Source, you do create an implicit moral contract between yourself as maintainer and the users of your code. Users can rightfully expect you to be a good steward of the software that you publish. It also sometimes inconveniently means that they expect you as a maintainer to care for their problems. That is what you sign up for if you publish code as Open Source.

I think we would all be better off if these implicit contracts became less implicit by writing them down. A part of this is PHP’s supported versions page, and Xdebug’s compatibility page. For Xdebug there is an explicit commitment to which PHP versions I support:

In general, at any point when an Xdebug version is released, it will support the currently supported PHP versions.

I also believe that as an active maintainer I should listen to what users have to say, and take their concerns into account. Only mentioning PHP version support is not nearly exhaustive enough. That does not mean you can be expected to give in to their requests (demands?). You are not obliged to do anything, and free to ignore user’s requests or demand payment in exchange for getting things done.

I have to come back to the issue of which versions of PHP should be supported by (Open Source) tools and libraries that PHP community members publish. This is a subject that sees frequent discussions. I started writing this article a few weeks ago, but even as of this weekend, another discussion thread sprung up on Twitter.

I believe very few developers want to be required to support old versions of PHP. It is no fun constantly forgetting that PHP 5.3 does not support the [...] syntax for arrays (FML).

If you write Open Source code as a “job”, it is more justifiable to spend time on older PHP versions. Unfortunately, that means that I sometimes still have to try to get PHP 5.3 to compile on a new Linux distribution. But because there is an explicit contract in place, I knew what the deal was upfront.

End users want the most amount of compatibility with the widest range of versions of dependencies, because they cannot be arsed to upgrade their code all the time, for various reasons, right or wrong. It is annoying for them to have to upgrade all their dependencies if they just want to use a newer version of PHP, especially if that means that they need to rewrite parts of their code because one or more dependency has breaking changes.

On the other hand, maintainers want to have to support the smallest range of dependency versions they can get away with. Supporting older versions of dependencies, including PHP versions, adds more overhead when you just want to use the latest and greatest to write more efficient and more performant code, while reducing cognitive load. There should of course be a balance, and what that balance is, probably depends on what the context is.

A library or tool that is a dependency that other developers rely on, which has a small range of supported PHP versions makes it harder or impossible for these other developers to use that tool to support a wider range of dependency versions for their users. With Open Source there is no requirement to do anything, but does it really hurt to be generous with what you support instead of having a strict dogma on what you will support? I believe not. As a community, I think we need to look at having more empathy for each other. And yes, that will sometimes mean supporting things for longer than you really want.

This turned out a bit more gloomy than I intended, especially after such a cheerful first paragraph. My main point is two-fold: be more explicit about what you support, and why, but at the same time have empathy for your users, and the eventual problems that they run into with your published open source code, and how it is supported.

On a happier note, although 2020 has been an odd year, it also brought lots of new releases in the PHP world: Composer 2, Xdebug 3, and PHP 8. I suppose we all had a bit more time now we are all stuck at home. I am looking forwards to meeting you all in person again at a user group or conference in 2021, where I will be more than happy to argue that the Attribute Syntax that PHP 8 now ships with is absolutely the best one, or that it is now really time to say goodbye to PHP 5.

Take care,
Derick

As I write this, PHP 8 has just released. The PHP community was all aflutter over the weekend installing playing, benchmarking, generally having a wonderful time with this early Christmas present.

I’ve iterated over this loop before. I was part of the community for the release of PHP 7. I saw the same excitement, the same squeals of glee when something worked. It was awesome then, it is awesome now.

I hope and plan to be around for the release of PHP 9 as well. I love being a part of this community and love to see the awesome things that it creates. Most of the vocal members of this community are part mad-scientist and part artist. That’s a great combination for creating things that can change the world.

The fun part is that the community celebrating the release of PHP 8 is very different from the community celebrating PHP 7. There are a lot of new people who have stepped into leadership roles as some of the old guard have moved on to newer pursuits. I am thankful for all the people that have helped us get where we are, but I’m excited about the new faces that will help us get to the next level.

Nothing lasts forever. I know that there will come a day – hopefully long into the future – when PHP is no longer a thing. But that day is not today. Honestly, you can’t even see that day from here.

Until that day arrives, we as a community need to keep finding common ground on which to keep working together. As long as there are developers writing code in PHP, and as long as there are core developers who care enough to keep PHP moving forward, then yes, we can keep moving to infinity, and beyond.

That’s the dream the ElePHPant has when it sleeps.

Thanksgiving in the US marks the beginning of the festive season that a lot of the members of the PHP-Community are celebrating in December. It’s the time of darkness, but also of the warm lights. And – most important – it’s the time to gather the family and to celebrate.

These were the words Andreas Heigl used in his opening post on this site, published on the 25th of November 2015, almost 5 years ago.

His goal at the time was simple; reach out to his extended, distributed, PHP-Family (or PHPamily for short) and bring together as many diverse and interesting thoughts and ideas from our community, in one central place, for us to share with each other, learn from each other, and support each other.

A lot has changed over the past 5 years, life, as we know it now, is very different from then. Many of us are dealing with new and interesting challenges, both in our personal and professional lives. And that’s the beauty of sharing stories from our community, as Andreas so eloquently put it back in 2015.

And as in every family, there are differences and there is potential for conflicts. And there are times where we don’t talk to each other. But in the end, we somehow manage to at least get along with one another. And the knowledge that we will get along with one another in the end and the knowledge that we all want to achieve awesome things bind us together. And as in every family, we can achieve even greater things together.

This year marks the 5th edition of the 24 Days in December site, and we’d like to take this opportunity to invite you to share your stories with us. We really hope we can bring fresh voices to the forefront, so if you’ve never written for a PHP related publication, this is the perfect opportunity to do so.

But what to write? Well, many of our previous contributors have written about the community, or open-source in general, or the way the modern web is changing how we live. Some authors picked a technical PHP topic that they would like to share because 24 Days in December is primarily aimed at PHP developers. Others shared something specific to the year that had passed, and what made it interesting for them. You can find a lot of inspiration in the past posts from previous years. The point is, this site is for you, our extended PHPamily, so share whatever you feel is important for us to think about as this year comes to a close.

Whether you want to write about something technical that is related to plain PHP, a fully-fledged and integrated Framework like Symfony, Laminas or Laravel, something about your favorite CMS like WordPress, Drupal, Typo3 or Concrete5, or something that relates to higher-level concepts, like open source, the PHP community in general, or your specific experiences as a person working in STEM, we are open to it, and encourage you to contribute.

If you would like to contribute to this year’s edition, email us at info AT 24daysindecember DOT net, or contact us via Twitter at @24DaysInDec.