At the middle of November my wife and myself were speaking about the Advent calendar for the kids. And I came to realize that I missed the phpadvent/webadvent the last years. And wouldn’t it be great to have a read about something PHP-related for the first 24 Days in December? Even for those people that are not christian the time before christmas has to be a special time. And if it’s only due to the commercials and ads what to present.

So I would wait and see whether someone would arrange something.

But wait! When everyone thinks someone should do something, no-one will do anything.

Cal Evans words came into my mind: If there’s no usergroup around, you’re the leader of the new usergroup. So I decided to just try it. Ask a few people I knew of twitter whether they would like to write something about the PHP-Community at large and get that published for those first 24 Days in December.

That first step was one of the hardest parts of the whole project. Realising that “The Community” starts with myself and – even though I might not realize it – I am a vital part of it. It’s a constant give and take and this is my way to give. There is no central authority to be asked whether I am allowed to do such a thing. Just do it and the community will decide whether it’s OK or not. And You’d be surprised how often it’s more than OK!

It was still 12 Days before December 12th. So I registered the domain with one of my providers I had good relationships with and started to make a list of people I’d like to ask for contributions. I wanted to have a good mix of people showing the broad diversity of the community and the language. People from different continents, different frameworks, different usergroups, different gender, different religion, different popularity and so on.

With that set I started to look through people I knew – and if only remotely – to find at least 24 to ask. I realized I should ask a few more people in case some wouldn’t want or be able to contribute. So in the end I had a list of 33 names I wanted to contact. It was totally clear to me that this list in no way was a good resemblance of those targets I set myself, but it was the best I could do at that short notice.

The next interesting thing then was to contact those people. For most of them I found an Email-Address on the internet, others I could contact via twitter. Some I could only contact via meetups contact-form (which seems to be rather lousy as I never got a reply from them). And then I reached out to ask whether they wanted to contribute. Now there was no way back!

I actually didn’t have a complete list when I started contacting the first people. I had about 15 to 20 names and decided to start of from that and see how it goes along from there. And during the following days I found more names by checking usergroup-leaders, people that tweeted community-stuff and so on. And suddenly the list was complete.

After sending my mail I was overwhelmed by the responses!

Apart from less than a handfull of people I got replies from everyone. Sadly a few rejection but I could understand them and it made my planning much easier. Most of the replies though where along the lines of “Great Idea! How much text?/What exact topic?/You sure I’m the right person?”

Some of the people I contacted didn’t consider themselves as part of the PHP-Community and weren’t sure they “qualified” to write about the community. All of them influence their specific framework-centric community in one or another way and that in turn influences the whole PHP-Community at large. So YES, they qualify!

Fine, everything settled. I made schedule of who should contribute at what date with no real strategy behind besides – at the beginning – first in first out. The website was set as well so I created logins for the 24 remaining people, created 24 posts, assigned the authors and hoped that everything was set now. I could not have been more wrong.

Some people couldn’t make their dates due to various understandable reasons they explained well in advance to me. So I had to find someone to swap the date with. More than once I had to write an “apologies but would it be possible for you to contribute earlier”-email. And not a single time I got a negative response! It was awesome! It was like I started to learn thanks to Stefan Koopmanschap – If you ask for something, the worst thing that might happen is a “No”. But without asking you won’t get anything.

That was the easy parts. Then there have been those that made their contribution at the very last minute (or sometimes even after that). At the beginning it caused me a sleepless night when I didn’t see the contribution before I went to bed (some three hours before the post was autopublished). But after one or another encounter with that and the realisation that the earth was still turning I put that of. The worst that might happen is that the post would be published later than expected. I think that only happend twice and no one complained about it.

And then there was the 22nd of December. The contribution wasn’t in on-time. And I was still waiting. And I hadn’t heard an answer to my “short-reminder” emails I sent everyone to remind them of the date and time. And I didn’t have an ace up the sleeve. So I had to admit there would be no post today.

And again Stefan saved the day. He simply asked! And within no time I had two more contributions in my inbox and one asking what to write. Awesome! The community worked again! (And – of course: Asking!) Why hadn’t I asked instead of apologized? There is so much still to learn!

Unfortunately at the time those emails came in I was already in bed high with fever. Flu struck! Thanks to modern medicine I could find a way to manage email, convert one of those contributions into a blog-post publish and fall back to sleep. And the last two days went extremely easy from an organizing point of view.

In the end this project was an awesome experience for me. I learned a lot about the community I so much favour and about that so much fantastic words have been written during the last days. I learned that asking is easy and often rewarded. I learned that different people work differently but when they have a common goal do their best to achieve it – it might not be my way but it’s their way of doing it.

And I learned that the PHP-Community is much broader and diverse than I expected. And I learned that it will not have been the last time I asked people to write something during the end of the year.

Thank you to all those people that contributed. Thanks to all those that told me they wouldn’t have the time to contribute. And Thank You to all those spreading the word about this project and to all readers!

And as all this would have been pointless and impossible – last but not least –

Thank You Community!

December is a time spent reflecting back on the year that’s passed, and preparing for the New Year ahead.

It’s a time for making resolutions. Next year I will spend more time with my family / grow my business / lose weight / work more / work less / work out more / be more mindful / quit smoking / get a new job / find new love / write the next great novel.

The ball drop on the 31^st seems magical. January 1^st is not only the dawn of a new day, but of a whole new year of hope and possibility.

But what if

But maybe, just maybe, we’re not looking for change. Maybe our reflections have led us to want more of the same: to reinforce what we’ve already been doing and to stay on that path.

I’ve been thinking about this a lot lately.

In 2014, I made a three-year plan to create change in my professional life. I’ve written about this before, so if you know the story you can skip down a few paragraphs.

I knew I wanted to do something new, I just didn’t know what. So those three years would give me the time I thought necessary to explore my options, and start winding down the freelancing business I had built up over a decade and a half.

But then, about halfway in, I started having a really rough time. I was working a lot – too much. I was increasingly exhausted and losing focus and motivation. My health started to falter.

I was burning out.

So I made another decision, another decision for big change, right in the middle of my three-year plan. I was going to take a full year off work. Because if I didn’t, I was never going to achieve my ultimate goal: the professional pivot I’d been longing for.

But it wasn’t an easy decision to make.

It wasn’t part of the original plan. It felt like failure. Fear and doubt built up, pummeling me with negative thoughts and questions and excuses. I’m too young to stop working. I’m too old for a sabbatical year. I might miss out on some great opportunities. I can’t afford not to work. What if it’s a bad choice? Is this a sign of weakness? What if I’m doing it wrong?

Now here’s the part you don’t know

My year off is right around the corner. I’ll be finishing up my final client project in the next few days, and then I’ll be free. On January 1, 2016, the dawn of the New Year, I officially start my sabbatical year.

And I’m freaking out.

Fear and doubt have built up again, pummeling me with negative thoughts and questions and excuses. What should I do with this time? How will I make the best of it? I’m already filling my time up fast. I wanted to slow down, so why am I giving myself so many new things to do? What if I get to the end of the year and I still haven’t found what I was looking for? What if I do it wrong?

The truth about change

The truth about change is that it’s a constant test of commitment. Making change means choosing it again and again. Every. Single. Day.

Making a resolution means making a firm decision to do or not to do something. It means being resolved. We have to be resolved to make real change happen, and to be prepared to confront all of the obstacles—fear, doubt, external influences—that will inevitably stand in our way.

Change is the ability to hold steadfast, which might sound like the opposite of change, when in fact it’s the very essence.

Thirteen years ago, I quit smoking. Since, I’ve never once said that I’m a non-smoker. No. I’m a smoker who wakes up every day and decides not to smoke (confession: I sometimes dream about smoking).

There were days when my resolve waivered. There were days when I was stressed or someone was smoking next to me or I was sipping a cup of coffee and I thought: screw this I’m gonna smoke. It was so painful, too much to ask of myself at times. And what did I know anyway? Plenty of smokers live long, healthy lives, right? <laughter>

I’ve worked with hundreds of small business owners over the years. The most successful among them all had one thing in common: steadfastness. They had the will and focus to make plans for their businesses and stay the course.

The ones I saw suffer the most were those who were constantly making plans, but then second-guessing themselves. A competitor would launch a new product or service and they would upend their plans in reaction. Or a new technology would appear that they felt they had to chase. More often than not their course-corrections made them stray from their ultimate paths, and didn’t give them the opportunity to discover what rewards those plans might have reaped.

Change for the sake of change, change out of fear, doubt and outside influences, makes us end up running in circles, not moving forward.

So how do you know?

I think we know what we want. If we listen to ourselves, really listen—not to the fear and doubt and external forces—our path is clear. But it’s still a path, one that must be traveled: a journey full of surprises, things to be discovered and challenges to be met.

I can’t possibly know the result of my year off. I don’t know where it will take me or what I will do on January 1 of the following year. All I can do is be resolved to stay on this path. Every. Single. Day.

And when the right opportunity presents itself, I will be ready to make that change too.

The only way you can really do it wrong is to forget what you’re doing or why you’re doing it. Fear and doubt are normal. They keep us alert. They keep us in check. So how do you know? How do you know when change is moving you forward or making you chase your tail?

Maybe we don’t always know. Maybe we don’t always listen to the sound advice of those we trust who try and show us the error of our ways. But again, I think deep down we do know, if not the answers, then at least the goal. And that’s what’s important to not lose sight of.

Make a plan and stick to it

I imagine my father summing all of this up in just a few words, “Make a plan and stick to it, kid.”

In steadfastness, there is change. We adapt to the ever-evolving landscape around us, in order to hold our ground. We must constantly navigate obstacles that come from outside and from within, to reach our goals and live the lives we dream up for ourselves.

In change, there is steadfastness. Creating change requires resolve, discipline and a deep belief in our actions. It means constantly navigating obstacles that come from outside and within, that try and prevent us from making that change.

January 1 is just the day after December 31. It’s just another day in a series of days. It’s not a magical day. It doesn’t hold special powers to make us more resolved nor to facilitate change.

We have this power to decide, to change, to hold steadfast, every day of the year. Every. Single. Day.

But it is useful to have checkpoints. A year, six months, three years, a lifetime. Using time as a guideline helps us measure our progress. It can help us define how long we want or need to maintain our resolve in order to ask ourselves that pointed question: Hold steadfast or make change?

I remember my first real conference talk very clearly. Dozens of thoughts raced through my head. What if I forget what I need to say? What if someone in the front row falls asleep? What if someone knows more than I do and corrects me? As it turns out, it really wasn’t that bad.

You see, no-one is there to correct you. No-one is waiting for you to slip up and make a mistake. They’re all there to about hear what you’ve learned. About the experiences you’ve had working in a certain environment or with a tool they’re interested in. Don’t worry about someone knowing more about the subject than you do (in fact, some of the better talks I’ve seen were by someone talking about a tool when the tool’s author was in the audience!)

You don’t have to be an expert. You just have to have a solution to a problem. Going back to my conference talk, it was a presentation about all of the mistakes I’d made in the last 12 months. I admitted to making some stupid mistakes, some costly mistakes and having some issues that no-one seemed to know how to solve. After that talk, several people came and thanked me for explaining the issues and how to fix them, as it meant that they wouldn’t make the same mistake themselves in the future.

Don’t start with conference speaking though. Start with a blog. Your posts don’t need to be 10,000 word essays on the state of technology. They can be 200 word posts on how to configure a specific piece of technology. My most popular posts include ones about how I debugged an obscure cURL error (and how to fix it), how to encode/decode arbitrary JSON in Golang and strangely, how to get an XBox 360 wireless controller working with Windows 7.

Share something today. Whenever you encounter a problem and work out how to fix it, write it down. Not only will you help yourself in 18 months when you need to do it again (and trust me, you will), you’ll be helping the rest of the internet solve that problem too.

A few months ago during a QA session at PHP South Africa I ended up coining a phrase that has really stuck with me since I blurted it out in the heat of the moment:

“Community is where you will meet the people who will change your life.”

I really believe in this, even if it sounds like a marketing slogan, and if you ever met me you probably understand why. See, our world of technology and development is one in which a “network” is a huge asset to your career. This is not just about finding jobs, but also about growing as a developer.

Let’s say that you are the greatest coder that ever lived. Congratulations, you are surely much better than I am. But is that really enough? It’s like the old saying: “If a tree falls in the forest but no one is there to hear it, does it make a sound?”. Does being the best out there get you anywhere if no one knows you are trying to get somewhere?

This is where community comes in and definitively not just for great developers, even more so for those coming into this market and seeking a path to grow.

The community is an amazing network:

A Network of People

Knowing people is key to the game. These are the people who will let you know about good opportunities, who will remember your name when an opportunity comes around, or the ones who will tell you about new technology, new ways of doing things. Its as much about recruitment as it is about inspiration and advice.

Behind every developer is, surprise, a person. Turns out we are all humans and we all face good and bad times. The PHP community has proven once again that they are as ready to give you their opinion on PSR-X as they are to come together to support you in time of personal crisis or calamity.

As an expat, building AmsterdamPHP was as much about sharing knowledge as a way to make new like minded friends, to make adapting to Amsterdam easier and lot more fun.

A Network of Knowledge

Each person in your network is a powerful tool of knowledge acquisition. The game is not to know it all, but to know who to talk to, to get the information needed. We are not all lucky to work with all the amazing names of our community, but through community and communication tools like IRC, Slack, Twitter or other we can be connected to this neural network of smart minds. When I was a one man team I constantly took my internal discussions onto these channels to get an external opinion, a new mindset and find a fencing partner. I was never disappointed and I learnt so much more than I would have being lost in my echo chamber.

Similar exchanges can also happen in meetings and conferences, that is indeed the center of their purpose. Whether you are watching talks, or hanging out in the hallway track, those exchanges can really flip your career upside down.

A Network of Opportunities

We developers are living a truly amazing time in our careers, a time of bonanza, a time when we can actually choose where, how and on what we want to work. This is not as much of an exaggeration as it may sound, most companies I know of are hiring some level of developer, and most of them have more slots open then the number of developers they can find. I venture to say that if you don’t have this feeling, you are just blind to the current market, and guess what? Yep, community also helps here.

Every single sponsor of AmsterdamPHP is hiring, no exaggeration. By simply attending our monthly meetups every month I get to see the “insides” of a new company, learn about their product, their passions and even better, I get to interact with their team in their “home court”. All of this goes into my mental “rolodex of cool places”, whenever I feel the need to seek new adventures this is where I go and start interview processes. Why wait for recruiters to offer me up as the “dish of the day” and tell me where to go? I know all the places I want to work at!

Ironically enough this also makes me a real good recruiter, wait, no I have not gone over to the Dark Side, but I do now have a good list of places to point people who are looking for jobs to. We cover the full spectrum, from “looking” to “getting indications” and finally to “being indicated to”.

Does all this “change your life”? I’ll let you be the judge of it, but from where I stand, my life really did get flipped upside down by the people I met in the community.

• Elizabeth Naramore taught me that “life started outside my comfort zone”.
• Cal Evans taught me that “if you are not in a community, you are it”.
• Michelangelo van Dam taught me that “Community Works”.
• Stefan Koopmanschap recommended me to the job that changed me to another continent
• Frank van de Brink partnered up with me to build AmsterdamPHP and make Amsterdam “Home”.
• The AmsterdamPHP crew taught me that “shipping elePHPants is not as easy as it seems”.

Your Mileage May Vary, but I consider moving to another continent and speaking in all but two continent of the world (Asia and Australia, I’m looking at you) one wowzer of a life change. And this is not even including all the amazing people who taught me to code, to architect and to PHP.

Thank you all for changing my life, I hope I can change yours in exchange one day.

It’s close to the end of the year so people are beginning to make their new year’s resolutions.

I’d be willing to bet that more than half of the resolutions have something to do with improving physical heath (myself included). But whether or not your new year’s resolution has anything to do with counting calories or buying nicotine patches to kick a nasty habit, you might need a good distraction from the triggers that activate the bad habit loops that you’re trying to break free from.

There’s an amazing opportunity to distract yourself from bad habits this year and create new habits that help others; it’s a little thing called open source.

Become awesome at copy + paste

We PHP kids love to copy and paste. It’s what we’re good at. If you’re like me, you learned PHP by copying snippets of code from random blog posts and forums around the web and hacking together an app that mostly worked but if you were to ask us specifically how it worked, we’d be at a loss to explain the bits we copy & pasted.

Fast forward a few years and we might see a developer who has learned enough to explain the copy and pasty bits. In fact we may have supercharged our copy and pasting abilities with a little tool called composer.

If you’re not using composer yet, you should totally get on board. It will change the way you copy and paste code into your apps. It’s amazing. It will allow you to easily integrate fantastic open source projects into your app with a single command.

Paying it back

For the veteran composer user, sometimes we take for granted that we have a whole copy & paste repository at our fingertips; none of which would be possible without the dedicated volunteers behind all of the open source projects that power our apps.

If you’ve ever used a snippet of code in your app that’s not your own, then you’ve relied on the PHP community to write your app. Have you ever provided your own snippets of code to the community?

If you’ve never contributed to an open source project before or maybe you’ve only ever dabbled in it here and there, make 2016 your year of open source.

Turn a bad habit into a good one

When it’s 11:50PM and you’re craving that chocolate bar in your pantry, instead of giving in, distract yourself by browsing the source code of projects you like to use in your own projects.

Instead of walking down to the 7/11 to buy another pack of cigarettes, spend that time learning how to contribute to open source projects on GitHub.

Heck, why not contribute to lots of open source projects? See which project has the best chemistry with you. See how much you learn when your code is reviewed by others in the community. Once you start sending regularly scheduled pull requests, you’ll wonder how you ever learned anything before open source.

Open source isn’t only good you and your own learning and development, but your contributions no matter how small or how big affect the PHP ecosystem. Not to mention the huge pat on the back you can give yourself after every pull request you send.

But fair warning – contributing to open source is addictive. You might fall deep into the open source rabbit hole, never to return. But it’s totally worth it.

Make 2016 all about open source

So after you’ve had your fill of gifts, sweets, and myriad family members asking you to fix their computer for you (so far I’ve had to fix 3 computers), take some time to sit down and reflect on 2015. Try to focus on what was good. What did you accomplish? How many people’s lives did you touch?

Then shift your thoughts to the future, to this upcoming year. Where do you want to go? Would committing yourself to contributing to open source this year align with your goals? What are you waiting for? Jump right in! The water’s fine.

The other day a friend of mine told me a story. He shared that he was meeting new colleagues at his new job, and when asked about his background, my friend told him that he’d been programming PHP for 18 years. My friend’s new colleague said “I’m so sorry.”

We laughed, because it’s funny. When you’ve worked with PHP a long time (about the same for me as my friend), you sorta have to. We know the language is warty and lacks uniform design principles. We know the process of creating it is sometimes an anarchic mess. We also know that it’s really, really good at solving some problems, and that’s why we still keep using it.

A few years ago, I hit a crossroads. PHP and me, we weren’t seeing eye-to-eye. I had been dabbling in Node.js and Python, and I liked what I saw, particularly a couple things:

1. Easy to use package libraries like npm and pip that had lots of well-written, interoperable components
2. A fair bit of emphasis on simple solutions for specific problems: built-in simple web servers; straightforward module systems; basic, usable testing libs shipping in the standard library.

To compare, this is what I saw in PHP:

• Lots of monolithic frameworks that were not interoperable
• Complex solutions (like monolithic frameworks, complex ORMs, etc) that tried to fit as many use cases as possible
• Lots of difficulty finding high-quality libraries of code unless you bought into one of those monolithic libraries. PEAR existed as a package manager, but there was not an active central repository where people could publish their work
• Downloading code in ZIP files from Google Code or SourceForge. God help us.

This sucked, especially if you felt, like I did, that having to learn a big fat framework and inherit a ton of code was a crappy idea. I started yelling about this with a blog post I titled “The MicroPHP Manifesto”. Some people seemed to agree.

I was still thinking about jumping ship, probably to Python, because that was where my work was headed. I did for a while, actually. But then I came back.

I came back because the good stuff was still good, and the bad stuff was starting to get a lot better. Now, a couple years since, I am even more confident that I did the right thing, and there are three major reasons why.

Composer and Packagist

I’ll say it plainly: I think Composer and Packagist saved PHP. Yeah, it still would have been used for a long time for WordPress and Drupal and some other very popular systems, but outside of that I think PHP was going in a bad direction, and I think it was Composer that saved it. It saved it because it gave great motivation to developers to create high quality, interoperable libraries. It did this by making it so much easier to find these libraries via the Packagist system. Discoverability was a huge problem that led people to keep choosing frameworks that gave them everything in one place. Composer & Packagist meant you could find what you needed, and only what you needed, quite easily. This was the biggest technical reason I came back.

Community

I should say here that I mean the non-application-specific PHP community that I run into mostly at conferences, because if we talked about everyone who worked on PHP stuff, it would be a hundred times bigger.

I haven’t run into a cooler, less clique-ish, friendlier community than the PHP community. Maybe it’s because we know our favorite programming language is not all that pretty, but it works really well. There is very little pretension with PHP folk, and I love that to death. We’re just trying to make good stuff and share what we know. It’s a really great open source community, and I am extremely proud to be part of it.

Diversity of Ideas

You could also call this “PHP’s willingness to liberally steal ideas from other platforms.” If there’s something that works pretty well on another plaform for web app dev, there’ a good chance it will end up in PHP, either in the language itself, or in userland. Stuff like short array syntax, ReactPHP, traits, and the built-in web server all came from other places, and all are super cool in PHP. And, if PHP doesn’t provide it, we’re very willing to just use other tools, like Node.js or Python or whtever, as long as it does a good job. That’s awesome.

There’s still stuff I don’t like much with PHP. Other than the crap we all complain about like function names and parameter order, my biggest beef is that the object system is so much like a mini-Java: very rigid, not composable. Don’t like it. Wish it was more like JavaScript or Python.

But, I can work with it. I like it here. I’ll stay a while longer.

One of the key strengths of any community is its diversity.  I don’t mean in the usual race-and-gender kind of diversity (although that’s important too), but more broadly.  Any given person only has so much experience to draw from, and only one (or maybe a very few) perspectives to bring to any given problem or situation.  Two people with the same experience may add (almost) twice as much available labor, but add only a little bit of problem solving ability.  Two people with different backgrounds and experience can double, or more than double, the problem solving ability.

Working with PHP, there are people of all sorts of professional backgrounds.  There are people that have only been out of college for a few years; there are people who have been coding long enough to have the proverbial (or literal) gray beards; there are people who didn’t go to college.  I’ve worked with CS majors, English majors, Physics PhDs, business majors, art majors, college drop outs, and culinary school graduates.  I’ve met people who are freelancers, agency consultants, product developers, hobbyists, and in-house “computer person”.

It’s that breadth of experience that is our secret weapon.

I’ve been part of the Drupal community for over a decade now.  The Drupal community is vast.  When I first started coming to PHP events, what struck me most was how quaint they were compared to what I was used to.  Most of the PHP conferences in the US cap out around 200 people.  That’s a small DrupalCamp.  DrupalCons in Europe generally pull around 2000 people; in the US, 3000.  Many people I talk to at PHP events are in absolute shock to hear that, and when they come to DrupalCon get a deer-in-headlights look about them.  How can there be so many Drupal developers?

Well, there aren’t.  I mean there are tens of thousands of Drupal developers around the world, on every continent, and that’s just the ones we know about that are actively engaged in the community.  But only half, half of DrupalCon Europe attendees describe themselves as back-end PHP developers.  Maybe a third of DrupalCon US attendees do.  So who are the rest of them?

They’re designers.  They’re front-end developers.  They’re UX experts.  They’re business owners.  They’re content strategists.  They’re project managers.  All interested in some way in building Drupal or building something with Drupal.  Although Drupal has often been accused of being “by dev geeks for dev geeks”, nothing could be further from the truth.

It’s that breadth of experience that is our secret weapon.

Teams that are diverse along many axes (both the obvious ones and not so obvious) succeed because they can, collectively, look at a problem from many different angles at once.  And by being part of such a team, you can learn, both deliberately and by simple osmosis, how to look at a problem from more than one angle.

That’s the benefit of a diverse community.  It is a loose team from which you can learn and experience different perspectives.  By engaging with different people and learning from their experience and perspectives, you borrow some of their power, and they borrow some of yours.

Most importantly, though, they can help you get more diverse experience yourself.  Not all the world is Drupal, or Symfony, or Zend, or Laravel, or WordPress.  By getting your own experience with a more diverse set of tools, your brain changes to be able to think about a problem in different ways.  Not just in a Drupal way, or Symfony way, or Zend way, or Laravel way, or WordPress way, but in many or all of those ways, through both your own experiences and the shared experience of others.  You can look at a problem and ask “how would Drupal do this? How would Laravel do this?  How would Symfony do this?”  Then combine them all in various ways to find a solution.

It’s that breadth of experience that is your secret weapon.

Getting out of your bubble and sharing experiences with others is what a healthy community lets you do.  And that, in turn, gives you a broader perspective to bring to the table.  Quite simply, diverse community experience makes you smarter.

And it’s not just a developer thing, either.  I’ve been involved in many different communities in my time.  Only some of them have been developer related, yet all of them, over time and with exposure, have helped to rewrite my brain.  All of them have had people to learn from.  In some ways, the subtle influences that seem to have nothing to do with development can be the most important, because they’re subconscious.  You may not think of involvement in a sci-fi club, or a religious organization, or a dance community, or a sports community as having much impact on your software development, but it does, because every healthy community you’re part of has something to teach you, and you have something to teach them.

It’s that breadth of community experience that is your secret weapon.

The caveat, of course, is that I refer to “healthy communities”.  Sadly, not all communities are healthy.  Unhealthy communities demand closed-minded thinking.  They deny experiences, rather than offer them.  They encourage people to stay “on the island” rather than gathering knowledge to share from many sources.  Unhealthy communities refuse to accept the benefits that a diverse background can offer.

Fortunately, PHP is not such a community.  The PHP community is broad and healthy.  The PHP community has reinvented itself in the past half-decade to be more eclectic and mixed and diverse.  Could it go further?  Certainly, but it has come a long way, with people from a variety of different backgrounds, perspectives, and experiences able to meet, share, learn, help, build, and teach.  And most importantly, to encourage its members to meet, share learn, help, build, and teach.  Because the more varied experiences we can share, the stronger we all are.

And that’s why the PHP community needs you.  Because you have a background, experience, and perspective that we want to learn from.  You can learn from us, and we can learn from you, because that is what a healthy community does.  You are our next secret weapon.

It’s the breadth and depth of the PHP community that is your secret weapon.

And it’s the breadth and depth, and generosity, of the community that is PHP’s secret weapon.

In 2015, speaking at 21 conferences and 37 user groups around the world, I had the tremendous good fortune of meeting over 1500 members of the PHP Community.  What is perhaps most amazing about this is I was able to do so despite a near paralyzing fear of being the “ice breaker” and of making cold introductions in social situations.

So, how did I manage this? Well, certainly at some point, being a relatively ubiquitous presence at conferences and user groups, it got a lot easier as people began to introduce themselves to me rather than my having to introduce myself to them.  But it obviously wasn’t that way in the beginning.  How did I manage to navigate this social awkwardness?

In 2014, I attended my first multi-day, multi-track conference, php[tek] in Chicago. Larger and longer than any community activities that I had participated in previously, I was determined not to allow my anxiety over meeting new people undermine the experience.  With a little creativity and planning, I was able to identify five different groups of people that I could connect with organically, without the potential awkwardness of a cold introduction.

The first thing that I did was to reach out to all of the people that I had already “met” on Twitter who I knew would be there and tell them what I looked like and asked them to look out for me.  This put the onus of a personal introduction on them and I knew conversation would come easily, having already grown our friendships on Twitter.

Second, my friend David Mosher had begun organizing a side trip to see a Cubs’ game, so I volunteered to handle collecting the money and distributing the tickets at the conference. This meant that nineteen people would be seeking out and introducing themselves to me in order to claim their tickets.  It also meant that I would be joined by these nineteen people for a multi-hour activity, an opportunity to easily make conversations with otherwise strangers without feeling awkward.

Similarly, several members of the community had organized a Magic: The Gathering tournament for one evening of the conference.  By signing up to participate, I was assured an easy introduction and several hours of conversational opportunity with another dozen or so attendees.

I also realized that perhaps the easiest people to meet would be the developer evangelists – people who were essentially being paid to meet people like me and who were obviously well suited for their roles, friendly and outgoing and good conversationalists.  I made sure to spend time in the exhibit hall making their acquaintances at times when it wasn’t unusually crowded, giving them ample opportunity to break the ice for me.

Finally, I made sure to join in the extra-curricular activities at the “conference bar” during the evenings.  Rightly or wrongly, I knew from experience that even if two socially awkward people find themselves seated next to each other in a bar, eventually one of their inhibitions will loosen to the point of breaking the ice and making an introduction.

My strategies could not have possibly worked out better!  During the three day conference, I slept a total of 8 hours (!), spending the vast majority of my time working the “Hallway Track” forging the basis for relationships with people who today I count among my best friends.  Looking back at the traditional php[tek] after conference group photo, I somehow managed to meet over two thirds of the attendees over the three days.  Samantha Quinones, who I met there for the first time and who is probably my best friend in the PHP Community tweeted this following the conference:

I offer my vote for @coderabbi as #phptek MVP for 2014

— Samantha Quiñones (@ieatkillerbees) May 25, 2014

While I’m not sure that my performance at the conference was valuable to anyone but me, I appreciate her sentiment and agree that despite being very hesitant to break the ice with strangers or make introductions, it’s doubtful that anyone was able to bleed more out of the social and networking aspects of that conference than I did.

It’s my hope that by sharing these strategies, others who share similar apprehensions will also be able to take full advantage of the fantastic human opportunities that conferences present and more easily form relationships within our incredible community.