Up to this day, PHP still has bad fame. When you are starting working professionally, that might give you a bit of impostor syndrome, because you think that you are not good enough to use a “good programming language” as other people you know. You think that you will become a good programmer once you are able to learn and work with a “professional programming language” such as Python, Java or Go, and stop playing around with toys for children like PHP.

However, as days, weeks, months and years pass by, step by step you are becoming more experienced —that is, if you have the right attitude, the appropriate gaze. One month, you start using a framework that ease your work. Another day you get a grasp on how good and helpful Composer is. Then you start worrying about testing, architecture, design patterns, code readability, SOLID practices…

I think it is sometime in that stage that you start to realize that good or bad code does not have much to do with the programming language or the tools you use regularly, but with other things that may not be technical —it can come to our minds what Heidegger wrote: “the essence of technology is by no means anything technological.”

Let me tell you a personal experience at this point. I used to work with someone with a few years of experience in web development whose main and only metric for code quality was the number of files you needed to write code to. Not security, not optimization, not code readability. Just the number of files you used to implement a feature. The less, the better. Moreover, he did not doubt to cut all the corners he could while implementing a feature so it was finished earlier. Because of that, management was happy with him: he was fast, so it was cheaper to deliver and it increased revenue for the company. Of course, no one took into account the number of bugs he had to fix, but he was fast doing it, so it only helped his reputation.

When he left the company after several years, we needed to take over his code. You can imagine it was easy to find controllers with more than 2,000 lines, containing duplicated paths and logic, without a single type or comment, exposed to SQL injection… We tried to prevent these kind of practices, but it is hard to battle non-sense using common sense. Had he used Go, C or Java, the magnitude of the disaster would have been the same — or worse. Quality is not about the programming language you use. It is about the person who writes the code: it is not that my colleague was not competent, he actually was pretty skilled. So I would say more: code quality depends on the gaze of the person who writes the code. It is about how you think about what you code, not the tools you use; the same way a good writer would write a masterpiece using a computer, a typewriter, or a pen.

We are now improving those projects a bit. In this arduous task, PHP with its environment is extremely helpful. We are implementing layered architectures using Symfony and The PHP League packages; testing where possible using PHPUnit or Behat. And we plan to integrate in our deployment quality tools such as Psalm and PHPStan. I think we have a promising future in front of us.

Before finishing, one might think that we did not answer a question that could arise from the text: “What is good programming?” But that is a hard question that we shall try to answer another day.

We all learn through our life, from our childhood to our retiring age. As children, we learn a lot from our parents or other family members, and later from friends, about socializing and other things we need to grow up. Later we learn through teachers in schools in many different subjects and after that, we choose to study what we need to know to be successful in our jobs. Life is impossible without learning. Live and learn.

As developers we actively learn through books, documentation, workshops, or just “by doing”, driven by our interests, curiosity, and the will to improve our skills. Sometimes there seems to be nobody to help or teach us during some stages in our lives and we have to take care to teach ourselves. Skills and knowledge are considered to be self-taught. After years of success and setbacks, we can look back at our accomplishments and a hard path that lies behind us in the past where we invested effort and time to enhance our abilities. Even during a strange year like 2020 there still was one or another achievement that made us better in what we do. Well done.

The other side of the coin

Of course, there were many people in our life who helped us to become better at our jobs, but too many seem to be convinced that it was mostly their effort that made them grow in what they are doing.

Unknown aides

What about you? I’m pretty sure you can name some people who influenced your growth and taught you some crucial knowledge about a framework, the language itself, or some good performance tweaks. But the truth is that there were many more people involved in your work-related progress than you can guess. People you didn’t meet in the past or even never heard of. If you ask yourself “How can this be?”, then I’ll tell you one name that helped me to come closer to PHP after I was looking for a new programming language to learn: Dieter Staas. I never met him. I don’t know what he looks like. While I’m writing these lines I even didn’t know that name a few minutes ago. He’s the author of a PHP book with the simple title “PHP 4”, a book about PHP 4.0 that I bought a very long time ago and that helped me in my beginnings of PHP when I wanted to write something different than C#, ASP or ASP.NET. I still have this book and after all these years I took it from the shelf just to see who had so much influence in my developer life that even affects me today because everything I know and do as a PHP developer was built upon that past.

But it’s not only about book authors (or blog authors). There were and are more people out there who have influenced your progress or your solutions. Yes, I’m looking straight at Stackoverflow. Has anyone ever opened the entry page of that site instead of accessing it over a search engine’s result page? There are so many people offering their help and solutions to problems and it became a regular problem solver for developers like you and me. It was so popular that it even became the target of jokes. Many of you might already have heard about the Exception class that creates a link with a search query to Stackoverflow. It’s a funny joke and I’m sure some created such an Exception class. Nevertheless, when I talk about what you or I learned from Stackoverflow, it was always another developer, another name that influenced your solution or decision. The same goes for any other source.

Who wrote that documentation you were reading in your attempt to teach yourself something new? Who wrote that blog post that made things much easier to understand? Who wrote that book that you used to study? There is no learning without teaching, explaining, or helping. Most cases where you thought that everything was self-taught are just another case of someone teaching you on your way. Even code itself or tests can (and should) be written in a way that makes it easier to understand and be a source of knowledge presented by a maintainer or contributor. But those names will be easily forgotten just as I forgot about the author of that PHP book.

Forgotten but never gone

I want to thank all the unknown developers who helped me to become the person I am today. It’s weird to share my appreciation in such a manner with you but, the sad truth is, we still will forget the names and internet aliases of those who were helpful on our path of improvement. This is going to happen even after realizing that we’re not as self-taught as we thought. But that’s why all that help can’t be taken for granted and before we give thanks to the unknown developer many years later, we should give our appreciation exactly when we learned something new or had other benefits by the help and work of others.

What we can do is:

• Simplest way: Say/Write “Thank you”
• Upvote a comment, blog post or video of the author
• Write how the content helped you with your problem
• Support their work

Or short: Make them aware that you liked what they did and that they made you a better developer, even when it just was in detail. And after that: Start to be helpful for others too.

Forgotten, but never really gone.

Something that many folks who know me, know about me, is that I tend to have a habit of rushing in where angels fear to tread. Call it blind optimism, call it stupidity, but whenever there is a need, I rarely think about the consequences and blast headfirst into getting involved, in order to help out.

The words “how hard could it be?” are something I regularly say to myself.

In 2016, after I discovered and officially became part of the WordPress community, I was asked if I’d be interested in helping to organize WordPress Cape Town meetups. I didn’t know what a meetup was, or how it worked but, how hard could it be?

Later that year, on a 1 and a half hour flight from Cape Town to Johannesburg, for the first WordCamp in that city, I was asked if I’d be interested in replacing the current WordCamp Cape Town lead organizer, who had to step down. I’d applied to lead in 2018, and therefore was planning on being part of the 2017 team, so I could learn the ropes. It meant I’d go from zero experience to leading the organizing team, and I’d never organized a large community conference in my life but, how hard could it be?

Last year, when the local PHP Cape Town meetup organizer had to step down due to moving to another country, he reached out to me and another member of our community to take over the meetup. I was already an experienced WordPress Cape Town meetup organizer, and I had someone who was helping me this time so, how hard could it be?

At the end of 2019, after offering to write a post for this very blog, I was asked if I’d be interested in helping to organize it. I had no idea what went into organizing/planning a yearly series of blog posts, every day, for the first 24 days of the month but, how hard could it be?

In case you’re wondering, the answer to all those questions was, pretty damn hard!

Because not everyone is like me. Not everyone rushes in where angels fear to tread and has time to speak at a meetup/help organize a conference/write a post for a blog in a short space of time.

And that’s ok. Those of us crazy/stupid/willing to do this will keep doing it. And those who aren’t, are very probably way better off for not doing it, and I respect them for it. And in every community, there are those who want to volunteer and those who don’t, and that’s ok too. Neither group should vilify the other for doing what’s right for them.

If 2020 has taught me anything, it’s that my involvement in the various communities I belong to is vital to keeping me sane, and I do it because I want to, not because I have to.

What I need to start remembering is that it’s always harder than it looks.

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.