Hey There,

Thanks for stopping by; Andreas invited me to contribute this post, and as usual, for me, the imposter syndrome phenomenon kicked in; what do I know, I don’t have anything valuable to say. I wrestled with this for a little while and then a randomly timed twitter poll was started by Kara Ferguson, I didn’t spot the initial tweet, however, but I was tagged into the reply by Thomas Dutrion, thanks! The poll question was ‘When you think of the big influencers in the PHP world, what names come to mind?’ – wow, what an amazing list followed in the tweets of that thread! And there’s me included in it, amongst some of the all-time greats – no pressure, right?!

Once I stepped back from my self-doubts and started writing, I reflected on the things I’ve done ‘in PHP’. I realised I had made a number of contributions to our community, some that are fairly visible, like running the PHPNW conference / user group; coaching at WeCamp as the regally titled ‘Coach of Coaches’; and many others that are not visible in the slightest, except to those people who’ve been directly involved in the conversations or activity. I’m not telling you this to boast, instead to give some qualification for what comes later on.

I believe that our PHP community is fantastic. It is made up of so many people who are prepared to go the extra mile, to go out of their way to help others along their journey to being a better software practitioner. Go and read the names in the twitter thread mentioned earlier and tell me that you’ve not had great value from someone on that list. However, all in all, in my view, it’s just not enough! So let me explain why.

I think of all the people I’ve met through the conferences, unconferences, user groups and other events that orbit the PHP language ecosystem – it’s certainly well over 2000 people (if that’s one of you by the way, then Hi!). Overall, however, It’s probably only a fraction of one per cent of the people who work with PHP in our industry, the rest are somewhere on the outside, not members of this tribe of tribes. Perhaps some of them believe they don’t need the rest of us, that’s fine, their choice (& loss); some, however, are wandering lonely out there, without knowing there’s a better way, the PHP community you and I respect and love.

At an empirical level, I see this with great regularity during the hiring process in work or conversations at conferences and the like. Alongside being a software engineer, I’ve been a hiring manager for well over 20 years, in both of my careers to date, initially in the UK health service (NHS) and in the last 20 years in the software world at Magma.

In the tech world, I see so many people who have never heard of, or only just discovered, the PHP Community. They then maybe don’t do so well during the interview process (or are telling me about their experiences), and their stories have a common thread running through them. They’ve done the same role for 2, 3, 5, 10 years (time matters not); they’ve perhaps outgrown their current position, or life has started to indicate that they should be progressing (maybe they’ve met someone who’s better at X, Y or Z than they are); whatever the route, they start to understand there are missing pieces in their learning.

Then I ask them what they do to improve themselves. Usually, it falters at this point, because if the candidate had already actively worked on this area, then the interview would have likely already gone better of course. So, I introduce them to the PHP community, specifically PHPNW, its YouTube channel or specific blog posts or websites that can act as relevant career accelerators and generally tell them a bit about our world. Most start to realise what they’ve missed out on in their career so far and what they could do next to improve, some rise to the challenge, some have gone on to become names on the roster of big influencers mentioned earlier, some go the other way and settle for an easier job and continue coasting along.

Well, folks, it’s time to suck it up, over to you, it’s your turn! Your mission, should you choose to accept it… If you’ve gained from the PHP community, then why not balance the scales and get out there, do some (more) amazing things, release your passion on the PHP / software engineering world. Get noticed, who knows, maybe become an influencer within this community (& beyond) and encourage those who don’t yet know the value of being involved, that there’s a less isolated and lonely path, one that can give them that leg up that we’ve benefited from in our respective journeys.

If you’re reading this and thinking something like, well this is all well and good, it’s easy for you, you’re already ’there’. Then let me tell you, that the majority of the things in our community, including anything I’ve directly started or influenced, comes from ordinary people, with a certain desire to add to our collective whole. They generally get off their backsides one day, stand up and say I’m thinking about doing a thing. They’re driven by their passions, from being inspired by seeing others doing the work, or perhaps more often, from sheer terror once they realise that stuff got real all of a sudden! However, they press on through, and suddenly you’ve got the next user group, podcast, blog, conference or even camping or cruise experience from which we can benefit directly.

So, my call to you, as you look over the previous year, and into the next during this festive season, is to ask yourself, your colleagues or contacts, what can I do to give back? Here are a few examples of simple contributions that can make our PHP world that bit more inviting, some are glamorous, many are not. Perhaps, your talent might be reaching out to those on the outside, inviting them along to the next event. Maybe, you can ‘sweat the small things’, be the one who gets the speaker or user group organiser a drink, when they’re busy getting the equipment to work or preparing this week’s announcements. Perhaps, you’re the next great conference speaker but don’t know it yet; you could start by giving a tutorial at work or the local user group; get some feedback and then submit a talk to a conference or two (trust me I’ve seen whole careers grow from this approach!). Maybe you’re the one who can invite others in by writing great documentation, or answering bug reports for an open source project. Contribute by being the welcoming character in the local user group slack channel or on the meetup event night. Here’s a simple side-mission for the meet and greet role, introduce the new person to 2 others within the first few minutes; now they don’t feel like they don’t know anyone, they’ve met three people in 5 minutes and then do the same for the next new person arriving.

In essence, don’t tell me there’s nothing you could contribute, put plainly, I don’t buy it! From my perspective, one of the worst things would be to do nothing, to consume others efforts and not contribute, or worse perhaps, to publicly bitch or moan about someone who’s endeavouring to do good (trust me as a conference organiser you learn to develop a thick skin rather quickly!).

Whatever it may be, promise me that you will do it and that it will be done more than once (remember three times makes a habit!). Ask for feedback from others so that you know how you can improve as you go and then, finally, tell others what it felt like to get started so that they to are encouraged, by your story, to step up as well.

If that happens, for at least a few of us in the PHP world, then perhaps we can build out the (less than) one per cent in our industry to 2, 3 or maybe even, dare to dream, 5% contributor level – what would our collective strength be then?

I hope you enjoy the festive season and enjoy a well-earned break. However, in between the food and drink, please think about what you could do to help us all win together, what your contribution can be, then next year, write up your experiences so we all can learn from them.

It is the Christmas season, and Christmas is a time for giving gifts: to family, to friends, and to colleagues. Some even give gifts to strangers they may never meet, as an expression of charity or of generosity, or in thankfulness for their own abundance.

Does the recipient of a gift owe the giver anything in return? Some might think the answer is “no” — it was a gift, after all. Others might think that the recipient now owes the giver a gift of their own, perhaps one of comparable value — but if the giver expects a gift in return, doesn’t that take away from the generous nature of the gift, making it more like a business transaction?

I would say that both responses are close to the truth. When someone receives a gift, they do well to return something to the giver … but the return is not primarily a material one. The recipient does the right thing to compensate the giver, not first with money or merchandise, but most importantly with gratitude and good will.

Granted a sense of appreciation, then, sometimes a further expression of that thankfulness is a gift in return. But note that it does not come from a sense of obligation or indebtedness “for services rendered.” We may exchange gifts, but we do not pay for having received them. To pay for something in that way is not to have received a gift; it is to have made a purchase.

II.

I think open source software is a little like the giving and receiving of gifts.

To be clear, I don’t mean the production of open source software. The actual work of developing a progam, with others, is not a series of gifts being exchanged. It is a cooperative/competitive activity with its own implicit order of criticism and acceptance.

But the open source software product itself, when presented, is a little like offering a gift to strangers. When you publish your work, you don’t know in advance who will find it useful, or even if anyone will find it useful at all. And yet, when someone does accept your offering, you get that good feeling of having been helpful.

In accepting an offer of free software, as with any gift, the recipient does best to regard the giver with gratitude and good will. That is to say, the user of open source software should have an internal feeling of appreciation for the gift they have been given.

If that appreciation is expressed in some outward and visible manner, so much the better. But that expression cannot be required by the giver of the open source gift. Really, it cannot even be an expectation on their part.

III.

What would we think of someone who, on offering what appeared to be a gift, immediately demanded a gift (typically money) in return? And then harbored resentment and ill-will for not receiving one? I think it would be fair to call such a person disingenuous at best; a swindler or a con-man at worst. It’s like the squeegee-man scam: someone runs up to your car at a stoplight, sprays and wipes down your windshield to clean it, starts yelling at you to pay them back for having served you, and finally (if you drive away) curses at you.

A person who offers a gift, then demands a gift in return, is attempting a sort of emotional jiujitsu to turn your own good will against you. Having received a gift, you may feel the giver’s demand is somehow justified; is it not the normal expectation to exchange gifts? And yet the initial act was not that of giving a gift: it was more like priming a pump, so that you would feel guilty, and then pay in cash to soothe your own self-imposed guilt.

Of course, the proper emotional reaction to the squeegee man should be indignation, not guilt, followed by refusal to concede anything to a “gift-giver” who expects money as payment in return.

As such, if you present your open source offering as a gift, you can have no expectation of anything in return. You cannot expect that anyone will use it; that anyone else will write the documentation for it; that anyone will write up issues or pull requests; that anyone will give you money for it. You can hope for these things, but to expect them (especially money!) is to be like the squeegee scammer. You gave a gift of your own volition; you have no cause to be resentful if people don’t offer you money for it.

IV.

Then comes the question, “Don’t I deserve to get paid for my work?” Certainly you do. But you don’t “deserve” to get “paid” for your gifts. It may be true that one good turn deserves another, but if anything, it is to be in kind, not in cash. If someone opens a door for you, you don’t tip them; you open a door for them in return.

The open-source “in kind” equivalent is Github stars, fair reviews, issues and PRs, and other work — given as a gift! — on your offering. Or recognition, or being cited as an ispiration. Or it might be new software offered as a gift to new strangers, that you never know about. (That is part of what prompts my own open source work; having received these gifts, I find it fulfilling to offer gifts of my own.)

Is it appropriate to mention the kinds of gifts you might like in return? Of course! Everyone who has ever made a Christmas list knows how that works. Set up a Patreon account, point out your Amazon buy-through link, suggest a donation. But I caution against “advertising” it anywhere other than on the project page itself; going out and announcing in public that you accept gifts is a little too much like panhandling.

V.

It’s normal to want to get paid for doing something you love doing anyway. It’s just not an appropriate expectation when you are giving strangers a gift. Now, it is true that getting money for open source software does happen from time to time, but it is unusual — more often, payment is tied to services around the software, not to the software itself. So if you prefer to get paid for your programming efforts, that’s fine: state the terms of exchange, then (and this is key) do not deliver the software unless those terms are met. Generally speaking, we call this “employment” or “sales” or “business,” not “gift-giving.”

Giving a gift in return may sometimes be good manners, but expecting a gift in return is bad manners. Likewise, it is bad manners to be a scold or a busybody, demanding that others pay money for gifts freely given. And if you feel that others are being “exploited” somehow for giving out gifts, the remedy is not to encourage them to begin demanding payment like the squeegee-man. Instead, consider suggesting that perhaps they should not be giving out gifts when they cannot afford to do so.

So don’t be the squeegee-man. If you want to get paid for your work, great! Ask for your money up front. If what you want is to give a gift, that’s great too — and if money unexpectedly flows your way, be grateful.

Postscript: these are some of the links that informed this essay.

• http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/ar01s06.html
• http://paul-m-jones.com/archives/20
• https://infogalactic.com/info/Squeegee_man
• https://twitter.com/fabpot/status/967337512535576576
• https://twitter.com/Crell/status/964524639857926145
• https://blog.jgrossi.com/2018/open-source-is-about-sharing-and-giving-back-think-about-that/

My friends, colleagues and business contacts are often asking why I’m involving myself in OSS and community activities around PHP. The honest answer is that time dedicated to the community changed my personality and my career path in better ways. It was a great experience and I’d like to highlight the benefits and how to give something back.

My personal motivation is built up upon three things:

• I’m using PHP for more than 10 years and feel important to give something back
• PHP infrastructure is great and competing (frameworks, tools, conferences and more)
• A diverse community, the most important thing for PHP to keep evolving

Due to specific of my OSS activities, I’m interacting with multiple projects communities (mainly frameworks) and each of them has it’s unique maintenance and communication culture. Since those cultures are different, we can see those holy-wars articles as “X vs Y”, but because of this, we are getting a great set up for creating great PSR standards.

The frameworks diversity value is a power for moving standardization topics forward.

And the life not ends when you are looking outside of frameworks communities, as PHP itself and tooling for it is created by other individuals groups. The diversity of knowledge and value those groups are sharing is outstanding, here some examples:

• Testing: PHPUnit, Codeception, Behat, PHPSpec, Infection
• Debugging and profiling: XDebug, XHprof, Blackfire
• ORMs: Doctrine, Eloquent, Propel
• Code style: PHP Coding Standards Fixer, PHP Code Sniffer

The infrastructure and frameworks diversity values are in an opportunity to create solutions fitting business needs.

As you see diversity brings a lot of opportunities, which still needs to be discovered and evaluated. While it might not be on the surface when making a decision to be involved into OSS or not, the following criteria need to be considered:

• the tool (or framework) has a community you do enjoy working with
• you find the documentation great
• you find tickets handling great (how fast maintainers are responding, how good they are in communication and more)

The infrastructure and frameworks diversity brings also an opportunity to find an OSS community you enjoy working with. This is a great source of support and inspiration, take the best of it.

Now, dear reader, let’s take a step back to the diverse community: it created a lot of value and opportunities. A lot of individuals, like us, made it possible, as our experiences and ways of thinking are unique. That’s a treasure, which we could share with the community, inspire other people, find people with the same values out there.

Isn’t it great? If so, why not to give something back: reporting or fixing bugs and reviewing pull requests in your favorite OSS projects, attending and helping out local user groups, coaching your colleagues, writing articles and sharing your know-how? All that matters.

And if you have any feedback, don’t hesitate to reach me at Twitter (@kalessil), I’ll be happy to support you in the first steps discovering the community.

A lot of people don’t understand why I like to speak to the PHP Community so much; since I am a database person. The truth is that I am not a database person, I am a Software Engineer that happens to know a lot about databases and likes them.

Sometimes we need to get out of our comfort zone to discover what we really enjoy doing, and that was no different for me. A lot of developers have to learn a specialized skill set at work because either they are the only technical resource available, or the only ones willing to put in the work to learn the needed skills. And that includes DevOps, Data Engineers, Test Engineers, SREs, etc.

But being the single resource is not an excuse to attempt being the Jack-of-all-trades at your company.

Maybe you’ve heard the commonplace myth: “You are only a REAL programmer if you code ALL the time”. I understand the drive, which sometimes is almost like a mania, to learn a new thing because it is cool and makes your head spin, but there is only so much that a brain can take without a break.

Life is out there too, outside of this screen. You may have responsibilities that don’t allow you to dedicate as much time as you might want to spend coding, or may make you not want to do so. And you know what? That is NORMAL. Most human beings in the world don’t bring their work home and continue working until they get exhausted.

Maybe you’re not bringing your work home, but are exhausting yourself trying to “keep up”, for example, with all the new JavaScript frameworks and what’s changed from one to another. You may succeed for awhile (again, they have a LOT of frameworks), but what is the price you are paying for it? Is it your body all tensed up? Having trouble to sleep? Anxiety? Compulsion? We all pay a price when we overwork on something.

If you are at a gym and overwork yourself you will feel physical pain, but on this knowledge high the consequences may take a while to appear. I am no doctor, but I have experience, and in my case, my brain AND my body charged a high price for my constant striving. You can read a bit more about that in this post.

I have a few tips that may help depending on how disciplined and open-minded you can be:

• Book a time on your calendar for recurring studies that you wish to learn. I am not saying for you to book a 3h slot five times a week, but start small, maybe a 30 min session twice a week or a book chapter per session?
• I am also not talking about stuff you need to learn to do the basics of your job. For example: Your company decides to move the entire stack to Node.js; it’s one thing to study a bit at home, and another to completely move your learning curve out of your working hours. THAT is not ok.
• Learn something different than your craft, have hobbies, they are a good escape valve. Book time to spend on your hobbies.
• Avoid as much as possible bringing work home. One thing you can do is to not check email after 6 pm. Close out of it completely, as well as Slack, and any other apps that might rope you back into thinking about work on your off hours. I guarantee that if stuff is on fire, someone *will* call you.
• Your GitHub is not your résumé. I know a lot of people that are excellent Software Engineers and aren’t on GitHub due to work in private sectors like banks, for instance.

And be yourself. Putting a facade is tiresome, energy draining, and honestly? Useless. It’s more frustrating to you to put up a show than to be honest with people about your strengths and shortcomings.

For this 2019 I wish you all the wisdom to be able to better take care of yourself.

You can reach me at http://gabriela.io or on Twitter @gabidavila (My DMs are open).

There are many ways you can contribute to Open Source: reporting issues, answering support questions, contributing docs, tests or code, and maintaining packages. I’ve been experiencing the last one for a few years, thanks to Thomas Rabaix, of Sonata Project fame.

I got involved in Sonata soon after picking it as the go-to tool for administration interface in my former company. I had been experiencing some bugs, and the code was simple enough for me to change it, and make a PR to contribute the changes back. At some point though, I remember getting a bit frustrated because my PRs were piling up. I looked at the list of PRs and I thought that mine were never going to be reviewed given the list of open PRs. So I proceeded to give reviews to as many PRs as I could, so that they were easier to understand, merge or decline. Then Sullivan Senechal joined the project and gave it, among other things, a much needed vision on versioning
Some time after that, when the project’s health was starting to get better, I got merge permissions too. Since then, I have been a maintainer and I have learnt some things about that job that I think are worth sharing.

The bus factor

This one is of tremendous importance: just like your production systems should avoid Single Points Of Failure, you should avoid them in an open-source organization. Many people should be able to merge pull requests, release new versions, or tweak repository settings. Of course, you should not trust just anyone, but if you notice you get regular contributions from the same person, you should definitely ask them if they would be interested in joining your team. Some might first say they are not worthy, and later on turn out to be great additions to your team. All will feel honored with your trust, and will often contribute even more than they already did. Always be looking for new team members even if you are already many, it puts less pressure on everyone, and allows better decisions to be taken. Some
members will sometimes need to step away from the project for some time, and that should not be an issue for anyone.

Managing releases

Composer is in my opinion the single best thing that happened to the PHP community the last few years, and, because of it, I think the approach people have towards version numbers shifted from marketing to something way more technical: backwards-compatibility. One of the most crucial responsabilities you can have as a maintainer is to make sure patch/minor releases do not contain any BC-breaks. Instead, you will often have to ask contributors to deprecate part of the API of your lib, while recommending newways of using your package.
The issue with the BC layers that are introduced is that they are often ugly, and can make your code harder to understand, and to contribute to. To avoid this, you should release new major versions of your packages as often as necessary, and remove deprecated APIs when doing so.
The corollary of this is that major versions should be boring, ideally just about removing old, ugly things, while minor versions should be the ones to continuously introduce new features.

This “release often” mantra goes for minor and patch versions too:
– The longer you wait for releasing major versions, the more crust you accumulate;
– the longer you wait for releasing minor versions, the bigger wave of bug
reports following them;
– and finally, the longer you wait for releasing patch versions, the longer your users suffer from bugs.

Our policy for Sonata releases is to do the patch and minor releases on demand: people can ask anyone of us for a release and it will be notified in a dedicated Slack channel that release managers monitor.
For major releases, we do not release as much as I would like, and I hope we can improve on that.

Making contributions easy

As a maintainer, you should make sure that the build is as stable as possible. Contributing a typo fix and getting a red build is terrible experience for contributors. To avoid that, you should never ever merge unless the build is green, and most tools will allow you to prevent that with some settings. You should also try to reduce uncertainties by using appropriate version constraints, and pinning versions for software you do not install through Composer. Do not commit your composer.lock though, that would mean your users would discover bugs before you get a chance to. Do add build jobs to test your software with future versions of your dependencies, and a job to test them with the lowest possible versions. Also when everything else fails, remove the tests that fail, even if they only fail sometimes for no apparent reason.
There is nothing worse than flaky tests.
If the tests fail in the CI, your contributors should be able to run them locally easily. Ideally, they should be able to just run make test and look
at the result.
If that fails, your contributors should be able to figure things out by reading the CONTRIBUTING.md and/or README.md files.

Reviewing code

Getting fast feedback on pull requests is always nice, and one of the most important feedback you can provide is that you do not understand the pull request. Require good commit messages, documentation for new features, and unit tests demonstrating how to use new APIs, or confirming that an issue is indeed fixed.
To avoid pestering contributors with style issues, automate away the style review, there are lots of SaaSes for this. Sullivan even wrote one and let us use it on Sonata.
If you can, integrate static analyzers like phpstan or psalm in your CI pipeline, it should detect some non-obvious bugs, or inaccurate phpdoc. With this out of the way, you should be able to focus on the big picture, and tell your contributor as soon as possible if their patch can be merged or not. Doing so as early as possible can avoid a lot of frustration.

I hope these tips will help you if you plan to become a maintainer, which you absolutely should if you want to grow as a developer: it will give you experience in areas that are crucial for deploying projects flawlessly but where you might not be able to train often.

When Andreas asked me to write something about the PHP community I immediately said ‘yes’. This community has become very dear to me over the past couple of years so I would love to share some of my thoughts.

This story begins many years before I even knew what PHP was.
When I was young I didn’t have a great relationship with the word “community”. To me, it meant conformism, in-crowd, bullying, gossip. I wasn’t a cool kid. I had great difficulty belonging. And by the time I was a teenager I kind of decided that I would be as independent as possible. Community was unsafe.

But as I grew older and gained more confidence, I did find communities where I felt at home. I was so fortunate to often have very nice co-workers. In my mid-thirties I joined a Zen meditation group. And by doing so, I became part of a larger spiritual community where I felt very much at home. It felt warm and safe being on the inside of a community and it became part of my identity. But everything changes, and the rebel in me started screaming and needing some space. Who would have thought that? My identity of being part of the Zen community in the tradition of Thich Nhat Hanh started to crumble. Some of the rituals started to annoy me, as well as the devotion that some people displayed towards Thich Nhat Hanh. And my spirituality expanded to include more than just Zen Buddhism. It felt like a pendulum. All the way to one side, then all the way to the other side. And right now it kind of stopped in the middle. The community of Thich Nhat Hanh is still my ‘family’ even though I don’t identify with it fully anymore. I still feel at home in it.

And then, at the age of 47, I became part of the PHP community. I was kind of nervous. In the spiritual community, I found myself among many people of the ‘feeling’ type. Many therapists and artists. More women than men. I was a bit scared to enter a community where the men were in the majority and where I expected to find people with a much more rational, thinking approach to life. Would this be a good match?

Up until then, my career had been lacking direction. Working was for paying the bills. Not very inspiring. Until the data scientist at the company I worked for, asked me to help him with some programming stuff. Then I discovered that programming actually gives me a lot of energy. That I really enjoy doing that! But if I was going to make this my profession, I would have to overcome my shyness and go meet the right people. And I did. I started going to meetups. Everywhere I went, I met nice people. No one tried to discourage me because of my age or my gender. I received a lot of help and mentoring to make my dream of becoming a developer come true. I received diversity tickets to go to conferences. AmsterdamPHP once organized a TestFest. I asked Rafael Dohms if I could attend and perhaps just watch what other people were doing because I could barely program in PHP. Rafael was very welcoming and during the event, he spent all of his time teaching me how to write unit tests. Mike van Riel played a big role in my becoming a developer as well. He was also at that TestFest where we practiced writing unit tests for phpDocumentor. After the event, I asked Mike if I could keep on practicing on phpDocumentor. Mike welcomed me to the phpDocumentor team and started mentoring me. He helped me improve my unit testing skills and programming skills in general and he answered many, many questions. It was Mike who had enough faith in me to introduce me to LTP where I landed my first job as a developer.

And then came WeCamp. Oh imposter syndrome! What if my skills were way too limited to participate? But I quickly found out that I had nothing to worry about. Such a great atmosphere! Any skill level was absolutely welcome. I felt included and at home. From then on I knew that the PHP community was also ‘family’.

I feel really rich and fortunate to be part of these communities. At the same time, I also see a danger. Remember that I shared that as a teenager I wanted to become as independent as possible? At the same time, I actually longed for a community. And when I found those communities I basked in the feeling of belonging. And I noticed in myself a feeling of “us”. I started identifying with that community. People outside of the community felt more distant. More like “them”. It’s so easy to find “us” a little bit better than “them”. I noticed that it was very tempting for instance to blame other people for harming the environment. While “we spiritual people” were so conscious. It was also easy to be oblivious to the challenges of our bosses when the going got tough for the development team.

These are mini examples of what we are seeing on a much larger scale in the world. There is so much polarization going on right now and it is getting more extreme by the day. It is so tempting to choose sides. To choose the safety of our communities and close our hearts to the outside world. It’s so easy to judge people in terms of good and bad even when we know so little about them and the situations they are in. It’s challenging and tiring to constantly put ourselves in other people’s shoes and yet I feel we should, as much as possible. At the same time we should be mindful of our boundaries. We should dare to speak up without breaking the connection.

When I was still an outsider, I experienced the PHP community as very friendly and inclusive. I have met so many open-minded and open-hearted people. Yet I know that we are all human and prone to closing our hearts and our minds when we find ourselves under pressure or under attack. May we support and remind each other to keep our hearts open to all those others out there. May we actively look for similarities instead of differences. For instance that loud and dominant woman from the other department, she has grandchildren that she adores. She can talk about them with so much love! That person who is always complaining is actually under a lot of pressure. Hmm, I tend to nag as well when I’m under that much pressure. When we look deeply, we can always find aspects in which we are the same. When we focus on the sameness of people, we can more easily access our compassion. May we extend our sense of community to include as many others as possible. May we all belong.

Happy Holidays!

Growth is the part of every human being. We only grow when we start doing things that we did not do before. But, with time we develop a tendency to stay in doing what we are used to. The tendency is called being in comfort zone and we all know nothing grows in comfort zone. This is a journey of me and how dev community helped me to do new things.

At the beginning of my career, in the end of 2012, most of my time was spent with college and office tasks and did not have time to do anything except that. After some time in mid of 2013, I came to know about the developer communities and the meetups that are happening around. So I used to take out time and attend the events. With all the new faces and different kind of people, it was me just going to the event listening to the talk and coming back. But later I realize that Networking is also a great part of the meetup. Started from interacting in the group to later knowing some of them and sharing knowledge was helping me connect with people who worked in similar sectors.

In the year 2014, I gathered all the courage and decided to be a speaker in WordCamp Nepal. It was a huge step for me to go talk in an event that is one of the biggest by a community. Luckily, I was selected as a speaker and had a chance to speak. They helped me to improve my delivery skills and provided with different resources to help my presentation be better. After being a speaker, attending events was more fun because there were more people who I got connected with.

There came a time where the number of meetups in Developers Community dropped in Nepal. My college was over and I had some free time now. So, In June 2017, me and my friend Sujan, decided to organize PHP meetup. We both have never organized a meetup and it was totally new for us. This led us to interact with the previous meetup organizers. Some of them whom we have known before but not interacted much and some new people. Now, with the very supportive suggestions and rough planning, we were all set to organize the meetup. It was hard in the beginning to call for paper, finding a venue, getting the sponsor and managing the event. But it all went good and with the help of other community members the meetup successfully. after that, we organized 3 more meetups in a span of a year but we could not continue to do it due to many circumstances.

If you want to do something in your community than you should plan to do it because there is a whole lot of people in the community that are ready to help. The developer community is a place where it grooms and supports you to do things out of your comfort zone. So being part of it not only helps you to know new people or things but also to do new things and get out of your cocoon.

On the fifth day of blogmas a community member sent to you their FIIIIVE TOP TIPS for team agility!

Welcome reader,

Hopefully, unlike me, you are not already stuffed full of mince pies, eggnog lattes and on your 27th viewing of Elf. As we go into the new year, now is a great time to reflect and make small changes that should give you months of pure joy during 2019 in your work.

When I was asked to contribute, I realised I owed so much to this community for their help and support over the last year (especially at WeCamp) that the only way I could ever hope of repaying that back is by paying it forward.

So without further ado, allow me to share the most common problems I come across in organisations and teams as an Agile Coach and offer you some approaches you can experiment with (and I have used) to help improve your processes and team joy. Think of all of this as homework over the festive season. Yes, it is the post that keeps on giving.

Stop Starting Start Finishing

If I got paid everytime I saw individuals assigning work to themselves instead of working to keep the amount of work in process as a team low. I’m pretty sure I could have retired by now.

It may seem counterintuitive to do less to go faster, but you gain in terms of quality and no rework on defects, which leads to delighting your customer first time everytime.

Here are the books that cover this in more detail, I keep them in order of preference, however if you’re not in software development then switch A and B as it will may be easier to relate more, or you know, do what you want, i’m not the boss of you.

Focus on smaller deliverable chunks of work and keep asking what is the value and what is the goal and you’ll be on the right approach.

• The Phoenix Project
• The Goal
• The Toyota Way
• Mythical Man Month

Collaborate

You are not an island, you should be working on building those relationships with others, in your team and community. These are the people who can give you guidance when you need it the most.

Mob or Pair Program with your colleagues and invite others from across the business into the mix, tis the season of goodwill. Open your work to them and you will be amazed at the useful information you get back, nothing brings me more satisfaction than seeing a novice understand your world for the first time, don’t miss out on those moments.

By opening up and having a meaningful discussion on approaches or techniques, you start to build trust and can move on to meaningful experiments, teams who do less of this are often struggling with perception issues. I find being as open and visible as possible allowing constructive critique negates this and often people outside the team will move blockers and impediments for you.

The second tip here is to tell stories. “User story mapping – Jeff Patton” and “Example mapping” are great techniques to discover the unknown about work yet to be done. In here Cynefin and Clean Language can also help as techniques to help break down the complicated into simpler deliverable pieces. See how much you can discover about these tools and then go and share with the community what you’ve learned.

Seek feedback

No, don’t just seek, embrace feedback. I don’t see teams challenge themselves to improve often enough, that stale Definition of Done, team values or other parts of the process are not reviewed often and opportunities to improve or check in with each other are missed.

Start from where you are, create mini experiments that you all can agree to try, think scientific method, from here make it visible on the wall if possible, so you are all constantly working to prove or disprove the experiment and you can see the progress being made.

All of this starts to allow the team to view themselves from the outside in and become comfortable with the feedback. In turn, once comfortable, you can begin the process of being more honest about areas for improvement and this leads to effortless continuous improvement indefinitely and helps the team change and adapt when members leave or outside influences asserts pressure on the team.

Look after yourself

Don’t burn out, this is the toughest tip, you are on a journey and work will get tough for various reasons, agree as a team how you can support each other and tie this back to team or company values. Speak to your HR or People department who will only enthusiastically help create support networks within organisations. If any knows of the right way to do this outside the UK then please feedback.

If you are a line manager then maybe some of the following will allow you to help and enable others. Here are some tools I like that focus on the person and keeps you in a listening state of mind.

The Coaching Habit by Michael Bungay Stainer is a great place to start, follow this up with Clean language questions to help you focus on what the other person has said without reinterpretation.

That being said, the simplest thing, is to change the environment you are in by going for a walk or a coffee and just talk, that may be more than enough for the person in that moment. This is what I wish I could teach all leaders.

Have Fun

It’s Christmaaaasssssssssss 🎉🎉🎉🎉🎉🎉

Celebrate your strengths as a team, Improve your retros by playing Retros against Humanity, board games, team lunches and chatting, Exploding Kittens, quizzes and any manner of entertainment that introverts and extroverts can enjoy, also for more formal retros look here other fun ideas (http://www.funretrospectives.com).

To be honest most of my job is looking for opportunities to play games with people which means I need to be open and honest about what I like so I can find out what others like, I am yet to find a team ready for the hungry hungry hippos tournament I want to run, although in my new role, I have been given a team who do team lunches and board games every week and I look forward to this day the most.

You are in this together so have fun and look after each other.

Then tell the community about that one great thing you did and really helped.

I wish you all a Merry Christmas and Happy New Year!

What We All Do

As developers the core of what we do is probably pretty similar. We probably work on tickets or stories or some other tracked and recorded issue. This may be in a tool like Jira or Rally or Pivotal or it could be tracked in an Excel spreadsheet or even via email. In some cases, it’s just a post-it or a couple of lines in a notebook that we keep in order to not lose track of what we’re asked to do. But someone is asking us to make changes to the software (it could be us).

After that we have the process of actually writing or modifying the code. For me and for many I know it’s roughly this – create a branch, make the changes, commit the code (one or more times), push up the branch as a pull request. After that, there’s the waiting for feedback, making changes based on that feedback and then finally the code is merged back into the main code branch.

There’s more details, I’m sure, but it’s probably not too dissimilar from what you might be used to. For us, the feedback or code review is a critical part of our process. If the code doesn’t get approvals from the right people or enough people it never moves on to the merging part of the process. We have a server that knows about all the different projects and repositories as well as the rules the team has for how many approvals it needs and from whom. This server also does a lot more for us that I’ll get into later, but it didn’t start with all of that.

How It Started

In the long long ago, but at my current company (I’ve been here eight years which is close to an eternity for many developers I know) we worked with code in SVN. Branching was easy but merging was a nightmare, so mostly people just worked in the main branch and then when a release happened, someone would copy the files into a release branch and away we’d go. Shortly after I started I converted us to Mercurial. Mercurial, if you’re not familiar with it, is quite git-like but at the time the tooling was much better for Windows developers compared with Git. Funny enough, Git and Mercurial both began life within a week or two of each other.

Our process then was that each developer would “fork” the repository and do their work and then when the code was ready, they’d let the QA team know and when they were ready, they’d let me know and I’d pull together and merge all the code they’d asked for. If it failed due to a merge conflict, I’d let the developer know and they would merge in “default” (the “master” branch of a Mercurial repo) and then we’d try again. I was the human integrator. I got to be pretty good at it and out of the hundreds or thousands of merges I did manually that way, I only made a small number of mistakes. But even those were too many. So I set about creating a set of PHP shell scripts that would speed up the manual entry of commands I was needing to enter multiple times every day. Think of it as fancy macros that would take the list of repositories and branches that QA wanted integrated and this tool would spit out the commands that I needed to copy/paste and run.

After doing this a bit and smoothing out any rough edges, I updated the code so that given the same input, it would run the commands. Of course error handling was still manually done. When a merge failed or when we needed multi-repo merges to happen in a transaction — think web code that relies on database changes that are in another repository — if the merge on the latter repos failed, I needed to undo the merges I’d done previously. After doing this a lot of times I found the various patterns and wrote some code to automate various cleanup and undo activities. Of course I was still a human conditional statement and had to figure out which sort of failure I had run into and what the appropriate fix was I needed to run.

As I’m sure you can guess, these scripts eventually got combined, I was able to make the determination of what sort of failure and how to clean it up I might run into, but still, all of this was manually executed based on input from the QA team. After running this way for a couple of weeks without needing to make changes, I built a UI for it. Instead of asking me to do the merges, the QA team could use the UI and make their own requests and the code would execute it and either let them know it was all done successfully, or tell them something had gone awry and what needed to be done to resolve it.

Going Further

At one of the many conferences I attended, I saw Jeff Carouth speak about some of the automation he and his team had. They used emojis in the review comments on github to indicate a pull request’s ability to be merged. I forget if it merged automatically or not, but I remember learning the developers on that team could request an environment be created for testing that pull request and it would be automatically created. I wanted that.

Sometime around this point, we moved from an internally hosted repository to Bitbucket for hosting. There are certain things you give up when moving from hosting your own code to using a service. One of those is that the repositories are no longer a part of your network. This means that events that happen on the repository cannot send requests or “webhooks” to servers that are part of your internal network.

What I wanted, what I needed, was a server that would straddle the edge — it needed to be publicly accessible but also be able to make API calls to servers that were part of our internal network. What this would allow is for an external service, like Jira or Bitbucket or Slack to make a request and something on our network could respond to it. This could be Jenkins causing a build to happen, or a message to go to a Slack channel or a text message to be sent or any number of things.

Webhooks

Eventually, I got the server, but it was a number of years later and my responsibilities had grown to the point that I didn’t have a lot of time to implement any of these things myself. What did happen ultimately has been great for the project and amazing for what it provides to the developers on the team. We hired my brother as a developer. I was able to tell him about my goals and ideas for the project and fortunately, he had the time to start implementing. As such, in further paragraphs, please understand that “we” is almost always referring to my brother implementing and coding the entire project but with both of us collaborating on the ideas.

Using Zend Expressive’s middleware based framework as a starting point we’ve found over the past few years that the possibilities are endless. We were able to not only integrate my integrator tool, we were able to enhance it greatly. Now instead of polling the repository for changes, the moment a pull request comes in it will trigger a build on the Jenkins servers that are on the internal network. When the builds complete, or comments are made on the pull request, the Webhooks server can post a status to Slack. Additionally it checks a configurable set of criteria, including the builds have passed, there’s the right number of approvals, the right number of people in particular groups have approved and that there’s not any comments that change this. The comments can be that another individual’s approval is required or that the author’s own approval is required and more. Assuming all the criteria have passed, the Webhooks server can either automatically rebase and squash the code (again all configurable) or let the author know that they need to rebase.

We follow a rebase workflow for most projects. This is mainly because QA is able to test a pull requests on a branch and know that the code they’ve tested will be identical to what it will be after the merge. This leads to another feature that was added more recently. By posting a command in Slack, developers or QA can bring up a sandbox set of servers for our applications on whatever branches or code versions they desire.

The webhooks project started simply and has grown to become an even more important part of our workflow than we initially thought it would. Much of this functionality is configuration or initiated through Slack commands. These commands are all controllable via an ACL (access control list) which is also configurable through Slack. We can also set up automatic merges, rebases and Jenkins runs. We can manage email configurations through Mailgun into one of our products. You can look up Twilio error logs and you can ask the server why any particular pull request hasn’t merged yet.

Because of the ease of development using middleward with Expressive, some of the commands we’ve built are just for fun. There’s a feature to send an inspirational message to someone and even one that would allow you to order a burrito.

Let Computers Do the Boring Things

The point of all of this is that you don’t have to start off with a server that can handle everything. That’s not feasible. But you can start out and automate a little bit that makes your life a little bit easier. Then iterate on it. For us, we started with automation of merging code, later we added creation of environments, rebasing code and much more. It means the human developers can focus on the parts of the process only they can do – writing and reviewing code, while computers handle the boring, repetitive and error-prone stuff: rebasing, merging, bringing environments up and down and deployment. This will let you focus on the more interesting things like coding, solving problems, and going home on time.

About giving…

Traditionally, at least in Western cultures, December is a month of holidays and celebration. Often these festivities involve gifts, whether they are put under the Christmas tree by a white bearded man and his reindeers, delivered in a burlap sack by another white bearded man from Spain or exchanged at a family dinner. But as we hopefully have learned, not all those gifts have to be large, expensive or material to make an impact. Sometimes the most joy can be found in sharing moments with family and loved ones, having dinner together, bringing up old memories and creating new ones. All it requires is accepting their presence and sharing yours.

Also in our PHP and open source communities we put a lot of emphasis on giving or giving back. In December there is 24 Pull Requests, there’s Hacktoberfest in October, and there are hackathons and code sprints throughout the year. This is not without a reason: a lot of open source projects deal with a lack of capacity or (financial) resources for maintenance. However, a focus on giving might also be a barrier for people to enter the ecosystem. For newcomers, the expectation to give back can be paralyzing: What projects do I need to help on? Should I open-source parts of my own code? Do I need to (be willing to) speak at meetups to attend one?

… and accepting what’s given

Maybe it’s better to focus on making full use of what the community has to offer first. Once you accept the things others gave to the community, giving back will often follow naturally.

For example, the next time you need a logger, event dispatcher, dependency injection container or router, please don’t create your own. There are numerous implementations of these available on Packagist. Unless you really have a revolutionary approach, the world probably doesn’t need another one, whether closed or open source. Overcoming NIH syndrome helps the open source community focus efforts on the few implementations that really matter. For a healthy ecosystem, maintenance effort and usage have to be in balance. A well-maintained package that nobody uses is just as bad as a popular package that suffers from a lack of contributions.

Once you start using more components that are already out there, opportunities for giving back will arise spontaneously. If you run into a problem, report an issue. Or sharpen the details on a bug report sent by someone else. Maybe you can try to fix the problem and contribute it as a pull request. If that does not succeed, you might be able to help the maintainer by writing a failing test to reproduce the problem. Perhaps, based on your own needs, you develop a new feature that you can contribute back. Also remember that not all contributions have to be code. If you find something unclear or unexpected when using a package, that might be an excellent opportunity for a documentation improvement. And if some open source project ends up saving you a lot of time, why not thank the author by sending them a postcard or ‘thank you’ tweet, or supporting their work on Patreon?

I experienced this effect myself last week. Just using a package for a few hours led to two opportunities for pull requests that, albeit small, will hopefully save others some time.

Beyond code

But the community has more to offer that you can take advantage of than just code. Go visit a meeting of a PHP User Group near you! Just by being there and talking to fellow developers you give back your knowledge, experience and ideas. Maybe you will get inspired to give a talk yourself sometime, or help out with organizing a next edition. Meet new people at conferences. Read blog posts, listen to podcasts, and realize that you too have experiences that are worth writing and speaking about. All it requires is accepting the presence of others (whether online or offline) and sharing yours.

Fin

Yes, the community needs more involvement and contributions. But first and foremost, don’t forget to accept all the great resources people in the community are already giving away to you. If you do so, the opportunities to give something back will come naturally. And remember: no contribution or gift is ever too small to make an impact.

May you give and receive lots of joy this December!