Dear fellows in tech,
We need to talk about unrepresented groups and a new way of thinking. Let me invite you to come with me a little way on my journey from behind the curtains into the public appearance and why representation matters.

“If we could change ourselves, the tendencies in the world would also change. As a (wo)man changes her/his own nature, so does the attitude of the world change towards her/him. … We need not wait to see what others do.” – Gandhi

It’s time to bring out the light under the bushel.
As a mom of five children without higher education or recognized vocational training, I didn’t fit into the regular recruitment requirements. Despite extensive autodidactic training, there were no matching job offers where I could work from home or nearby my hometown. This led me to some unfortunate job experiences. The gap between expectations on both sides was often too big to continue contracts. This experience resulted in frustration and uncertainty.

But this never stopped me to move forward.

If there is no matching job for me in this world, I need to create it by myself.

Over 25 years, I was working for several employers besides my responsibility of managing a big family. One of my hobbies was doing creative stuff with my computer. The access to the world wide web has opened a new universe to me. Building websites for my own, later for friends until I got asked to do it for a small business why I was forced to register a small business by myself as a side-hustle. After now 13 years doing it that way, I decided this spring to start a full-time business as a trainer and consultant for WordPress.

Making a living from services around an Open-Source system like WordPress means also to give something back. One of my job experiences brought me into the ecosystem as an active contributor. I found my passion while translating WordPress, releasing WordPress with German language packs, managing the content on the German project site and many more. But I also learned about diversity and acceptance. The WordPress community is open to all kind of human expressions. But in public appearance, there are mostly men representing what they are doing. Most decisions are made by men. It’s not their fault – in most cases.

The world isn’t monochrome but its human to follow the usual paths. For decades, young girls have been tricked into behaving bravely and obediently. Contributing and working in STEM seems unreachable for many women.

Despite these findings, or precisely because of them, I use my experiences to encourage other women to unequivocally present and defend their abilities and interests. Over several years, I encourage women to speak up and find their unique voice. However, this usually happened in small discussion groups or in one-to-one situations.

You may ask me, why I didn’t make it more public. Unfortunately, I myself fell into the trap of Imposter Syndrome again. The question, “Who cares what I have to say?” is running around in my head like a ping-pong ball more often than I would like to have it.

In 2018, I finally took the chance to share my personal story how working with WordPress literally saved my life at four different WordCamps in Europe. About how I dealt with chronic illness, divorce, the death of beloved ones, about the ups and downs of having a job and losing a job. My talks were honest and very personal. After each talk, I got phenomenal feedback and admiration for my courage to share such touching stories. It was an eyeopener for me.

For 2019 I’ve committed myself to raise the awareness for more diversity and inclusiveness in Open Source communities and tech companies. Many thanks to Andreas for the opportunity, to share my learnings and future steps here as an inspiration to think about what you can do for a more inclusive world.

What are you waiting for? As Gandhi said, you need to be the change, you want to see. If you want to have more diversity in your surroundings, you need to be your own role model.

Representations matters!

Recently at the office I organized a viewing of Rafael Dohms’ talk on object calisthenics and code quality. The entire dev floor was invited. The talk and its concepts were generally well-received by our PHP devs. Our data analysis lead, however, was quick to point out that “this has been around in other languages for so long. It’s not a new concept. Why can’t we look beyond this?”
It really got me thinking: how inspired are we as a community? We have a huge amount of active user groups, conferences, and other opportunities to learn and share knowledge. There’s a lot of support, mentors aplenty, open source libraries to contribute to. It’s an easy community to fall in love with and, in turn, nestle into. But what happens when we get too comfortable?
Read more

Value Beyond Code

“Personally I would never want to be a member of any group where you either have to wear a hat, or you can’t wear a hat.” – George Carlin

When it comes to tech, it’s easy to fixate on the one aspect so easily associated with said tech – the underlying code that makes an application run. It is terribly easy to think that to work in tech, to matter in tech, you need to actually write code. Digging deep in the trenches of syntax and [fill in your favorite letter]DD, picking up the newest fanciest tools, participating in the latest framework battles. It’s not weird to think this, considering how much discussion there is around that one aspect.

But there are many more aspects that are necessary to thrive in tech than code, represented by different roles beyond software developer. Just as I’m writing this blog post, I find a similar sentiment by Emily Freeman on Twitter:

“Stop using the ability to code as the metric of value as an engineer. Plenty of folks don’t code because they’re experts in something else. Like infrastructure. A thing developers often don’t know much about.

If you don’t want to feel less than, stop doing it to other people.”

The ability to code is valuable in tech – but it shouldn’t be the only metric of value. Much of that required expertise cannot be covered by devs alone.

So if you want to work in tech, but not as a dev adrift in a sea of code? That is absolutely fine, and let me underline why.
Read more

Developers don’t like PHP

According to StackOverflows Developer Survey, 58,4% of all PHP developers would like to move to another Language (https://insights.stackoverflow.com/survey/2018/#technology-most-loved-dreaded-and-wanted-languages).

They show it when they write PHP code, too: There is no other language getting close to PHP when it comes to the usage of words like “crap”, “fuck”, “hate” or “shit”:
https://github.com/Dobiasd/programming-language-subreddits-and-their-choice-of-words

The reasons for this dislike are well documented in online rants, for example in https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/:

• PHP is full of surprises: mysql_real_escape_string, E_ALL
• PHP is inconsistent: strpos, str_rot13
• PHP requires boilerplate: error-checking around C API calls, ===
• PHP is flaky: ==, foreach ($foo as &$bar)

He is right: these APIs are neither predictable, nor consistent, nor concise. Current APIs in other programming languages tend to be a lot better nowadays.

Nevertheless, PHP is still used for 46% (https://webspotter.io/category/platforms) or 79% (https://w3techs.com/technologies/overview/programming_language/all) of all dynamic websites as the server side language of choice.
PHP or the spin-off Hack is the base technology for some of the largest internet sites:

• Facebook
• Yahoo
• Wikipedia
• WordPress
• Slack

PHP is even, being a pure web language, on place number 4 of the GitHub language popularity index (https://octoverse.github.com/projects#languages)

What is going on here? Why do these companies still use PHP? Are they just stuck with a bad technology decision they made in the beginning before they got famous?

Cathedrals and Bazaars

1997, at the international Linux day in Wuerzburg, Eric S Raymond told the story about “The Cathedral and the Bazaar” (http://www.unterstein.net/su/docs/CathBaz.pdf) for the first time.
He describes to major strategies to develop software: the cathedral strategy and the bazaar strategy.

The Cathedral

ESR writes:

In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you’ve winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect

Cathedrals need architects, they need a good structure and a big design upfront. The design of the cathedral is important, there is no room for variation, for spontaneous ideas of the people building it.

The Bazaar

In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena – or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.

There is no architect for a bazaar. Somebody provides space, sets up a number of rules and invites people to participate.
The bazaar is free. If you see that there is a certain product missing on the market, you can simply open up your own stall and wait for people who would buy it.

Linux is based on the idea of the bazaar. ESR even calls this model “the Linus law”.
In the first days of Linux, a lot of people did not believe that Linux would work out. Everybody can participate? Everybody is able to add a feature, drivers, modules, and functionality? This is going to end up in an inevitable mess. People will introduce bugs and unforeseen bad interactions since they don’t understand the whole software. Linux is going to collapse under the weight of uncoordinated efforts!

Today

Today we know that “Linus Law” worked out. Linux is not less stable, in contrary, it’s used for the majority of mission-critical systems. It’s the foundation for the major cloud providers today.
The bazaar model itself was a major success, too: Github is basically a technical implementation of it.
The late success of the most popular programming language today, javascript, is based on nodejs and npm – another bazaar.
PHP has been a bazaar right from the beginning. It was always easy to participate and provide extensions to the language. I have been working with several release managers and core developers of PHP. If you know what you are doing and willing to discuss your ideas with other developers it was always easy to play every role in the PHP world.

Agile Architecture

Cathedrals and Big Design Upfront

The original idea of software architecture was a cathedral approach: start with a proper, well designed and understood big design upfront. Start to implement after you defined how your architecture is going to look like.
If we don’t know how our software is going to look in the end, how should we define the architecture for it now?
Maybe somebody invents new technology that is going to be useful for our platform in 3 months? Maybe we discover that one of our base technologies does not live up to the promise it made?

We know that we need to be prepared for change when it comes to internet applications. Youtube started as a video dating platform, but the customers rather wanted to upload videos. Slack was an interactive game, but the chat appeared to be more useful. Twitter was a podcasting platform before iTunes came and they had to reinvent themselves. Paypal was a palm pilot app that nobody used, Pinterest was a mobile shopping platform with no demand. None of them would have survived if they would have kept their initial architecture.
But how do we create an architecture if we already know everything is going to change?

Emergent architecture

Agile development answered with emergent architecture (see https://submissions.agilealliance.org/system/attachments/attachments/000/000/2342/original/Emergent_Architecture_-_Just_Enough_Just_in_Time.pdf). We’ll figure out the right architecture on our way to the final software. KISS (keep it simple, stupid), DRY (Don’t Repeat Yourself), YAGNI (You Ain’t Gonna Need It) are parts of an emergent “just enough architecture” strategy.
In emergent architecture, it’s ok to change your mind and choose another architecture a few sprints later. It’s ok to try out new architectural options as “Spikes”.
But emergent architecture is not cowboy coding, where everybody implements whatever he wants – it’s an architecture that allows changing your mind.
It’s not possible to change your mind if your software isn’t flexible if it’s not modular. It’s not possible to change your mind if your software is entangled. It’s not possible to change your mind if you rely on a certain component, like a special database system.
The easier – and cheaper – it is to change your mind, the better the architecture can adapt to changed or newly discovered architectural requirements. Strategies like the SOLID design principles or microservices try to achieve exactly this. If it’s hard or expensive to change your mind it’s not emergent architecture, since it relies on learning, adapting and trying out new things.
If everything works out you end up with the architecture that is the best fit for your current requirements – and not, like in Big Design Upfront architecture – the best fit for the idea of the software you had before you even started developing it.

Bazaars are distributed emergent architectures (on steroids)

The bazaar model already implemented a lot of emergent architectural patterns, like the Unix principles, that have been a major influence on microservice design.
And it implemented emergent architecture in an even more powerful way – as something that was free, attractive, open and distributed. Why evaluate 2 spikes at the end of the sprint if you can have 10 people implementing their ideas of a good solution for free and trying them out for months? Why not adding other peoples brainpower to your ideas and implementation and have them suggest – or even provide – better implementations?
It’s useful to be able to choose one from multiple solutions for a certain problem. If a lot of people do this it’s even possible to figure out what solution is the best fit for most of the problems, simply by looking at the number of downloads or GitHub stars.
Bazaars are emergent architectures on steroids. They provide a multiple of implementations and empirical data, a multiple of learning and adaption.
Does this kind of architecture result in beautiful implementations? This just happens if beauty is the major driver to choose an implementation. Most of the time it is not, it’s simply the most usable, the most useful implementation. Whatever the benefits of using a certain module are, the one with the best overall fit is going to be the most popular.

PHP as an application of distributed emergent architecture

How do You create a platform that works well with emergent architecture?
Obviously, it needs to allow experiments, and these experiments should be fast and easy to implement.

That’s how PHP does it:

Existing open sourced functionality

There is already a mountain of existing PHP functionality out there. It is GitHubs fourth most popular language, and most of the repositories are free. There are 4-5 major solutions for every kind of problem, be it CMS, e-commerce or frameworks, with large infrastructures with hundreds of additional plugins and modules behind them.

PHPs builtin functions

PHP comes with thousands of builtin functions for the average setup. You need something? It’s probably already there. Is this good design? Certainly not! Will you be able to move fast? Yep.

Focus on functionality, not on parsing HTTP, restoring session variables, typing or memory management

When the PHP script starts all variables, request or session variables, are already there. By default, you don’t need to care about typing or memory management. There is no HTTP-event loop, everything is already done. With fewer things to care about you get faster and cheaper experiments.

Fast feedback for local development – the inner loop

Hot Module Replacement? The fast save-reload-check-cycle was a part of PHP right from the beginning. The default delay until a developer sees if his idea actually works out is 1 second.

Fast feedback for teams – the outer loop

PHP deployment is file-based and immediate. Update the file and you’ll see the changes with the next request. There are no compile steps, no build artifacts needed to see a change another developer created on your machine or in the test environment. A simple file transfer – most of the time as a part of the version control system – is enough.

Fast integration of existing libraries

If it can not be solved in PHP code, it’s easy to create a new PHP Extension. It’s even possible with limited C knowledge, and most of the times a few lines of code are enough to integrate a function.

Star Treks BORG as a role model

The PHP culture is not afraid of stealing ideas. If something looks interesting, it will be assimilated. If there is a nice idea in the Java world, in Golang, in rust, in ruby or python – we are going to steal it.

All these strategies support PHPs bazaar architecture.
They make PHP a marketplace of ideas. It’s not build to look beautiful as a cathedral. It’s not there of aesthetic purposes. But it is made to provide fast easy solutions for most of the requirements you have.
And if there is a solution missing for exactly your problem, most of the time it’s easy to create it.

So, why – and when – should i use PHP?

PHP is optimized for environments where you don’t know for sure what is going to happen next. Not by design – by emergent practice. By the survival of the fittest for the purpose.
PHP could not provide fast and cheap solutions and feedback loops for most of the problems if the focus would be beautiful design instead of, well, fast and cheap answers and feedback loops.

If you know exactly how your future will like – don’t use PHP. But if your future is unpredictable and risky – PHP will help you to figure out what works and what doesn’t in a very efficient way.

Do you know if there is a user group in your area? And if so, have you been there? If you answered one or both of this questions with „no“ and you are wondering why you should care? Let me tell you a little story.

Read more

Monday morning. Your previous project just wrapped up, and they are going to assign you a brand new one. They even promised you the lead on this project. Who said Mondays couldn’t be great?

A few hours later and you are staring at the most dreadful code you have ever seen — controllers of more than a thousand lines, PHP that injects jQuery in the views, raw SQL statements that could challenge a Dostoyevsky novel in size. The list goes on and on. This Monday is going to need a ton of coffee.

The previous few lines might sound very familiar to you. You might even be working on a project like this at this very moment. If that is the case, … lucky you.

Why do these horrible applications exist?

Most applications don’t start like this. As you know, green field applications start full of hopes, dreams and rainbows.
A new business idea gets launched. It does something small, pretty good. People like the application. They like it a lot. More and more customers flock to the application. You excitingly add more functionality to your small idea. Soon, one of your more prominent clients, asks for a very valid use case.

Hmm, you haven’t thought about this particular flow in the application. To be honest; the application doesn’t support it. However… it’s a big client, and it’s a great idea. You know what, this small little hack won’t make the difference. We’ll document it, so everyone knows about it.

Fast forward a few months. You have a dozen developers working for you, and your Kanban feature board is filled to the brim. The strange thing about the board, however, is that most of the features on that board don’t come from your hand, they come from customers. Moreover, they all want concrete things very tailored to their workflows. That little hack that’s been made a few months ago is now not even considered a hack anymore; it’s just how the application works. Moreover, if you take a step back, most of the application is now a collection of these small little hacks.

You might think that this is a horrible product, and from a code perspective you might be right. However, from a business perspective, this is a vital process. The product has a ton of customers, and they are invested enough to want to tailor it to their workflows and they even reach out to you with suggestions. Granted, not all of these suggestions are great, but they wouldn’t come forward if there weren’t a need for them.

Is this the low point?

However, now where does that leave you, It’s entertaining to have a company with many customers, but at the end of the day, you’re still the one that is in the trenches of despair.

Not necessarily;
Having a product like this tend to generate income. The most significant part of that income is invested back into the project. Once the legacy code hampers the production of new features or generates too many bugs, the discussion surrounding refactoring parts of the code tend to start getting more and more speed.

Once you start refactoring, you suddenly notice that you have so much value in front of you — a ton of use cases already implemented, a wealth of user behaviour and data, metrics and most important of all: the budget and infrastructure to match.

Working with legacy day to day

Most refactorings tend to start with the question from management that is frequently a variation of: “what are the worst parts of the application, and how can we make them better”. This sentence is poetry to a developer’s ear. A great chance to go over the entire application note down the pain points, look at technologies that might ease trouble, have lengthy discussions with colleagues about the architecture of the pesky service classes. Not only are you going to learn a ton on the technical side of things, socially you’re going to improve in ways of persuasion and proposing ideas.

After a while, the most significant part of the spec will be done. Moreover, I can guarantee you that you’ve never been so excited to work on the project before. You can now look at the project and see a road to be walked, where before it was just an end to a means.

Now comes the tricky part, refactoring one of those huge files. The first time you read over the class, you might get some doubts about this whole refactoring stuff. Luckily you stick to your means of attack and write your first end to end tests. Once you’ve established a safety net, you regain a big part of your courage.

Ok you think, this piece of code I might be able to extract to a separate class. You write the unit test. You extract the code, and everything is green. Ok, great start! Let’s do it again.

A few hours later you stare at the construction you’ve made. It’s a vast improvement of what it was before (every single indentation you fix is an improvement), but looking at the loose classes, you can see some definite improvements still. You could leave it as it is, and that would be great, or go further. Either path you chose, at one point you’re going to create a PR, and sit back and stare at the diff screen of your favourite git hosting service … what a beauty.

Growing with the application

Working on applications like this is all about responsibility. Every decision you make as a team will impact you in the future, in a good way and sometimes in a not so good way.

This kind of pressure might sound like a burden, but in reality, it is indeed a blessing. It forces you to slow down and think about your actions as a team. Should I write a test for this? The answer is going to be yes, cause once it has a test, it’s going to part of the test coverage for maybe years to come.

So that’s the beauty of legacy code: You get a rough stone that you can shape into a gem. The pressure of delivering new features won’t be lower on a legacy application over Greenfield, but management often understands the need for refactoring and architectural meetings better.

Moreover, all the technologies and paradigms learned in the refactoring of legacy code are invaluable when you move on to Greenfield projects as you now have the context for the need for value objects, testing and decoupling.

So yes, if you’re about to start on a legacy code base. Lucky you. You’re about to have one hell of a ride.

Ps: Happy birthday Taylor Swift

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).