Pragmatic coding

Can you write me a simple script that fetches some information from an RSS feed and displays the titles? Like, just write me that script in a couple of minutes. I don't care about tests, quality, etc. Just get me the information, quickly.

I'm curious how you would handle this request. A couple of years ago I was asked a similar question. Not in a professional role, but for a hobby project that has nothing to do with PHP. There was a website, a simple website, and it needed some information displayed. Nothing fancy right? I can do that.

But as I sat down to code this little script, I came to the conclusion that it took me way too much effort to start thinking in a pragmatic, simplistic way. I started thinking...

I'll want to use a library


If I want to use a library, I'll need to use composer to install it


If I install that library then it would be useful to add some other components, to easily manage configuration, dependency injection, etc.


Wait, what is the actual question here? There is a pre-existing website, a codebase that I have nothing to do with so far. It is not built using any of the standards I use in my dayjob, and really, I should not care too much about it. It is a simple website, for a hobby. They ask me to simply add something simple. Should I really want to introduce libraries and components, tools like Composer?


As it turns out, I seemed to have forgotten how to do simple scripting. I was so used to installing a full-stack framework, adding all kinds of libraries, that the simple task of writing a script that would just do one simple thing was getting too hard for me. Instead of just getting a hammer to get a nail in the wall, I wanted to rebuild the whole wall because it was not initially built using the same type of wood I was used to. Do I really want to take on a huge reconstruction project in my house just to hang a painting? Why is it so hard to open my toolbox and grab that hammer?

Back to the basics

Since that moment I've tried to challenge myself every once in a while by writing simple scripts instead of full applications. For instance to automate simple tasks on my laptop (see: automation in this blogpost). Other challenges were simply to write something I had no use for. Just to get back to the basics of writing scripts instead of applications.

It wasn't easy, but I've learned a couple of nice lessons.

First of all, PHP as a language actually has a lot of stuff that we don't really need userland code for. Yes, the components and frameworks will make the task easier, but there are so many functions in PHP that can help you achieve a task that you don't really need a library for. RSS, for instance, can easily be parsed using SimpleXML. And I really don't need to have domain objects or entities per RSS item. Need a quick database connection to get or save some information. There really is no need for Doctrine or Propel, PDO will do what you want. And that's just two examples. There's so much more.

Second: Bootstrapping a project using Composer and frameworks works well for big projects, but if all you need to do is write a simple script, the overhead is just way too big. I had somehow forgotten that, or was just ignoring the option of just starting. I'm sure this had to do with the fact that I have been mostly working on big projects in the past 10+ years, but still... why did I forget?

And last but not least: Being pragmatic can be really useful. Sure, we all want to write the absolute best and most beautiful code ever, but sometimes you really shouldn't care. Sometimes you just need to be pragmatic, make it work, and forget about it.

Build from the basics

One of the "simple scripts" I wrote a couple of years ago ended up becoming bigger. I had written it quickly, just to make it work, but as it grew, I decided to refactor it a bit, add a bit more structure, and introduce some libraries along the way.

An important lesson I learned from this approach: We don't need the full-stack for everything. Components can by itself be really useful. Not every project I do automatically gets a full-stack framework installation these days. You can easily build your own framework for your project using components. I even have a talk about that these days, and I plan to write more specifically about that at some point.

Challenge yourself

So let's go back to the original question:

Can you write me a simple script that fetches some information from an RSS feed and displays the titles? Like, just write me that script in a couple of minutes. I don't care about tests, quality, etc. Just get me the information, quickly.

I'd say: go for it! Challenge yourself to do this, without libraries, in an hour. You can do it.

Best practices on bundles in Symfony

I know I'm late with this, but I've only recently really been discovering the podcast as a way of keeping informed. My daily commute is quite long because of traffic jams and a good way to keep yourself occupied with something useful is to listen to podcasts.

On one of my recent commutes I started listening to the Sound of Symfony podcast. As I had just discovered that one, I decided to listen to their most recent episode, which is on best practices for bundles. I quite disagreed with what was being said in the podcast. I started voicing my disagreement on Twitter but quickly decided that 140 characters is not enough to really explain my disagreement. So here's a blogpost.

The Best Practices documentation

First of all, I need to say something about the Symfony best practices documentation. At some point the symfony project released an "official best practices book", and in the podcast they refer quite a bit to this book. The book is being referred to as "this is how you're supposed to be doing Symfony" and "In 95% of the cases, this is how you do it". Let me state that I sincerely disagree with this. I think the practices described in the Symfony best practices book are not really best practices, but instead they are a good starting point. In my opinion, the Symfony best practices should've been called the "Getting started with Symfony" book.

I also disagree with the fact that you should be setting up all your Symfony projects in the same way "because it's easier to understand for new developers". If you do a lot of similar projects it makes sense to set up your projects the same way, but it really depends on the project. Look at the project, not the developers, to determine how you set up your Symfony installation. Code organization is, to me, much more important than how long the on-boarding process for new developers is. On-boarding is a one-time investment in a project. A good code structure will help you in the long run as well.

The AppBundle

All Symfony documentation (and also the Sound of Symfony podcast) assume your project contains a single bundle: The AppBundle. This bundle is supposed to contain all your application code. ALL your application code. When you're working on a very small application, this perhaps makes sense, but just about any project I've ever worked on, this is not realistic. There's a lot of code in most applications. Also, putting it all in a single bundle makes it very unstructured and bloated. I personally really dislike that.

Uncle Bob

While I was at ZendCon this year, I attended the keynote by Robert C. Martin. His keynote went into a lot of different programming best practices, and one thing really resonated with me: Code structure.

At some point during the keynote the slide contained a directory structure of a project. It was pretty clear from the directory structure that this was a project built on a specific framework, but looking at that structure, there was no way to see what the project was actually about. One of the statements Uncle Bob made was that the structure of your code should not show too much about your framework of choice, but should communicate to you what the code is actually doing.

Structure in a Symfony project

Now, the basic directory structure for a Symfony project will always show you that it is a Symfony project. However, you could argue that the project root is a basic filesystem, and the directories that a Symfony project have reflect the purpose of the underlying directories. app/ will contain application-specific stuff, web/ is your document root, and src/ will contain your source code. As such, I think it's fair to apply the lesson Uncle Bob was teaching specifically to the src/ directory. If that directory only has an AppBundle directory, you have no idea what the project is about. The only thing you know is that you're looking at the code for an application. Well, duh.

Bundles to structure your code

So the first thing I'd suggest is to use bundles in Symfony to add a bit more structure to your code. Name them after what it does and your code is already a lot easier to understand. If you have a webshop, you could have a ProductBundle, a CartBundle and a CheckoutBundle for instance. If you build a CMS-based website, having an AdminBundle, a PageBundle and perhaps a ForumBundle makes sense. I can take a look at your src directory and immediately see what goes where.

What about your domain code?

Now there is a slight issue with this approach. Because what do you do with your domain code? The code that contains your business logic, that is not tied to your framework but to your business. Because we don't want to tie our business logic to the framework, putting the domain code into the bundle feels wrong. We want to have it seperated. Since the src/ directory is the place to put all custom code, this would mean we'd also have to put that in the src/ directory. Following that logic, we'd now have the following directory structure:


While not necessarily wrong, this feels wrong. This feels like duplicating things, or splitting things that somehow belong together. There's a solution for that.

Adding more structure to your project

In a project I recently worked on I was introduced to the concept of Bounded Contexts. The structure of this project was really nice, because we wouldn't even leak the framework implementation in the first level of the src/ directory. Taking the webshop example I had because, the src/ directory would look something like this:


If you're new to this project, you'd immediately understand that this is a webshop, and that it has code in there for a cart, the checkout process and products.

Now, within every directory, the same structure could be found:



The Bridge/ directory and namespace would contain code that would connect to external systems. It provides the bridge between our domain objects and the storage/persistence systems we were using. This code is not part of our domain code, but not really part of our application either.


The Bundle/ directory and namespace would contain our actual Symfony bundle. It contains all the code that one would expect in a bundle: Controllers, configuration, templates and any other code required to tie our domain code to our framework implementation.


Of course, the Domain/ directory contains all our domain code. This may contain interfaces for certain code, domain objects (usually POPO's that reflect data structure), specific exceptions for our code, etc.


This directory will contain all the tests that we've written. This could be unit tests, but also integration tests. Anything that tests our code will be here.

The importance of structure

As a consultant and freelance developer I go into a lot of companies. I either develop with an existing team, make changes to an existing (and sometimes unmaintained) codebase, I do code reviews or help in improving a codebase. I agree with everyone who says that having a common structure in a codebase will help with getting to know the codebase, and as such I understand people going for the standard structure that a framework provides. While I prefer Symfony in many situations, I am not tied to a single framework. Over the past two years I've worked on projects built on top of Symfony, Zend Framework, Laravel, Slim, Code Igniter and Silex. I've worked on projects that adhere to their framework default structure and also on projects that have a custom structure (such as the structure above). For me, it is a lot easier when the structure reflects what the application is about instead of what tool it is built on top of. I am therefore extremely happy to have worked on a project with the above structure. It has taught me a new way of structuring code that makes more sense than anything I've done before. It was a good confirmation to hear Uncle Bob describe a similar structure in his keynote at ZendCon.

I can understand if you opt to go for the default structure of the framework you're working with, but perhaps it is good to think a bit longer about it. While the initial learning curve may be a bit more steep when you go for another structure, it may actually make things easier in the long run. And if you document your choices well, everyone will have a place to check for reference.

Keep on learning

I've said it before and I'll say it again: It is important to keep on learning. One of the things I've learned this year is a new way of structuring code, which is part of the Domain-Driven Design approach. I've been learning about DDD a lot this year and I already realize that I'll need to learn even more about this. If the concepts in this blogpost are new to you, then you probably want to learn about this as well.

24PullRequests 2016

Last year I already wrote about different initiatives in the period leading up to Christmas. In one of my talks this year, Level Up Your Team I've been discussing many ways of learning, and for this year I want to highlight one of the initiatives that I participated in last year, and again am trying again this year: 24 Pull Requests.

What is it?

The idea is that you send (at least) one pull request to an open source project in the days leading up to Christmas, starting on December 1st. The website will keep track of your progress and give you a list of suggested projects.

Why would you do it?

The most obvious reason is to contribute something to open source. If you, like me, earn most of your income by using open source code in your projects, this is most certainly a good reason to contribute to open source. But there's more...

When do you learn most? I learn most when I am challenged, when I am pushed out of my comfort zone. This is one of the reasons we get so much positive feedback for WeCamp, because we push people out of their comfort zone in every possible way. That same thing applies with 24 Pull Requests: You are forced to send a pull request to an open source project 24 days in a row. While they can be 24 PRs to the same project, it works better to have a look at the suggested projects and try to contribute to multiple projects, preferably ones that you don't know (that well).

Is it easy?

No. Not every project has a low hanging fruit or easy pick tag, and even if they have them, it may not be easy for someone new to the project/codebase. Also: Actually writing a PR every single day for 24 days is not easy. At least if your calendar is as busy as mine, it's not easy.

Actually last year, I completely failed. I can't find the actual stats anymore on the 24PullRequests website, but I think I sent maybe 5 or 6 pull requests. Time was mostly the reason for this failure, but I tried. And even though I didn't succeed in sending 24 pull requests, I did push myself to contribute to open source, and I did learn about some projects. For instance, I had not looked at Disco until last year. And this year, I've already contributed a simple typo to RMT, which I did not know until yesterday, and I've contributed a bugfix to Bolt, a CMS that I've been using a lot in the past year.

Join in!

So go ahead, start contributing!

Get rid of -m

I can't remember where I actually first read about this little developer's lifehack, but I've been using this for a while now and really like it: Not using the -m option anymore when commiting with git.

What I used to do...

I use Git nearly exclusively on the command-line. My main reason for that is being burned by a version control integration of an IDE somewhere in the remote past. Since then I don't really trust any version control integration anymore and I want to have the full control over my version control tool of choice, these days mostly Git.

Committing changes had a certain never-changing process:

git status

To check which files I've touched.

git diff

I'd diff each file separately to see if the changes in that file belong to the stuff I currently want to commit.

git add

I'd add every file that belongs to the current change.

git commit -m ""

Then I'd commit the staged changes with a small comment about what the change contains

The main problem with the above flow was that the -m promoted short and simple messages. And tempts a bit too much to write bugfix or just a little change in the controller. It is just too tempting. Also, even though I'd just changed on which changes there are in the files I'm committing, I wouldn't have it all in my head anymore.

Get rid of -m

Some time ago I'd read a tip from someone that said "just don't use -m. It took some time to process the usefulness of this tip in my head, but eventually I decided to try it. It works!

The last step in my flow now is:

git commit

This opens up (in my case) vi, where I see a list of the staged files and I can type a commit message. Because I'm not on a command-line anymore but in an editor, I'm less tempted to write only a short commit message. Instead, I can describe what is in the changeset. And since I have the list of changed files there as well, it's easier to remember what I changed and for what reason.

It's a simple lifehack for a developer to write better commit messages, and it works (for me)!

The Serendipity Machine

I recently finished a book that has been in my possession for quite some time already, The Serendipity Machine by Sebastian Olma. Subtitled A Disruptive Business Model for Society 3.0 sounds very buzzword-y and startup-y, but despite the subtitle it was a very good book.

I've been a big fan of the Seats2Meet concept for quite a long time. The idea of getting a free working place including free lunch in exchange for sharing your knowledge and experience with others really appeals to me. I was first introduced to the concept quite a while ago by a colleague. Despite my business model causing me to work on-site with customers most of the time I've worked at Seats2Meet on several occassions, and with PHPAmersfoort we also organized meetups at one of their locations.

Some of the things discussed in the book really already describe what happens naturally in the PHP community. Especially things like sharing knowledge is happening a lot. One of the things where I think we can still improve though is the facilitating meetings. On the higher level, I mean to combat the isolation of the "islands" inside the greater PHP community, such as Drupal, Joomla! and all the different framework communities. But on a lower level, I also mean the people attending usergroup meetings and conferences. In a way, initiatives such as FIG provide a way of doing this, but on that smaller, lower level, we fail to do this, perhaps also because we fail to facilitate this. The fact that the majority of PHP developers is pretty introvert does not help, but all the more reason to facilitate these meetings.

So how do we facilitate this? you may ask. This is where we can have a look at how Seats2Meet does this. Their platform, where all visitors of the Seats2Meet locations sign in, allows people to "tag" themselves. In their profile, they list the topics they're expert in. For instance, my profile for Seats2Meet contains the following:

Tags in Seats2Meet profile

When you've book yourself a seat, you'll see the tags of other people that are there together with you, and you can look for the specific knowledge that you need. This is an active facilitation of meetings between people that have something in common. If at some point during the day while working at Seats2Meet you find yourself in need of some specific knowledge, all you have to do is check their system to see if someone with that knowledge is also at the location you are at.

The hallway track

This is where the hallway track at conferences becomes useful. While most people are in a session, staying in the hallway is a great way of meeting other people that made the same choice of a skipping a session. These kinds of random meetings are harder during breaks: There are so many people in the hallway at such a moment that it's hard to really decide who to talk to outside of the people you already know, also because everyone else is also talking to people they know. During a session though, there is little choice. So next time you skip a session, just talk to someone else that made the same choice. Even if you can't help eachother at that moment, you've expanded your network (or value network as Sebastian calls it in the book).

Conferences may facilitate these meetings by allowing "tagging" of people. Either through an online platform or by allowing people to add "tags" to their name badge. I can't tell you exactly how this should be done, but I do feel this is something that can be done in a better way, to facilitate these "random" meetings. To enhance the serendipity.

If all this sounds good, I would recommend you picking up a copy of The Serendipity Machine. It is an inspiring read, especially for those that are active in the PHP community. And if you're near a Seats2Meet location, book a seat for a day every once in a while. It's free and it's awesome.

The Serendipity Machine (ISBN 978-90-8169, November 2012, Creative Commons BY-NC-ND) is also available as free PDF download.

ZendCon 2016

It's just past 5AM as I start writing this. I'm sitting downstairs in the ZendCon hotel, with a view on an empty bar and brightly coloured gambling machines. Since I woke up at 3AM (don't you love jetlag?) and today is the day I travel back home, I've been reflecting on the conference. I'll be missing a few sessions because I had to leave early, but I've already gotten a lot of new stuff to ponder about, my head is pretty full. Time to let it sink in a bit.

As I was pondering the lessons of this conference, I thought back to the last talk of yesterday, Exploiting the brain for fun and profit by Alena Holligan. One of the things Alena talked about was how you can improve your learning. One of the things she mentioned was teaching others. Teaching others really helps you to learn stuff yourself. But the other thing was: Write it down. Writing things down will help you to not forget stuff. She even mentioned the situation I've been in a couple of times: Googling for a problem only to end up on your own blog, where you discuss the solution. As such, I'm writing down some of my lessons of ZendCon. So I won't forget, and hopefully to help others learn about this stuff as well.

Let's start with the opening keynote by Andi Gutmans and Rod Cope. Andi and Rod looked back at where we came from and where we're going with technology. While the picture for the future that was painted sounded awesome for users, it sounded horrible for privacy. I'm really curious to see where this will be going.

I also attended the Composer for corporate use talk that Stephan Hochdörfer did. One of the things I learned from that talk is the composer license command, which gives you an overview of the licenses used by your dependencies. Related to that, I also learned about VersionEye, which seems like an interesting service. That is now on my list of things to check out.

I was really looking forward to see Uncle Bob do a keynote at ZendCon, and this turned out to be an amazing keynote. He gave a nice overview of some common patterns from the past as well as the present. It also taught me that at my current project we're doing pretty well for some of these topics. There's always room for improvement, but we're on the right track. It is good to get that kind of confirmation.

Next to the talks I also had a nice chat with some of the sponsors at their booths. My most important lesson there was the Clean Coders video platform. Before ZendCon I was not aware it even existed, but with a lot of material delivered by people like Uncle Bob, Corey Haines and Michael Norton on topics such as architecture, technical debt, testing, SOLID etc it looks like an amazing opportunity.

It has been another amazing ZendCon, and I'm bringing the lessons back home with me.

On Priority

I got a private message on one of the Slack networks I'm on on August 2nd. Mike Bell invited me to write something for Geek Mental Help-week. As usual, I delayed to the last moment to write that, and the Geek Mental Help-week was last week. I'm publishing this now, a couple of days too late.

For quite a while I was thinking about what to write about. I had quite a few good topics I could possibly write about, but I just hadn't decided yet. I've thrown out all those topics (for now at least) because I am too late, and that actually gave me the best topic.

Last Thursday was a horrible day. I felt my mind being tricked into depression. I specifically use these words because I can not really control when it happens, or what happens. I've had cognitive behavioural therapy to recognize when it happens and to try and counter it, which usually works, but on Thursday I had a really hard time actually doing so.

I had a full-day training session scheduled on Friday, a training session I had already postponed earlier. I could not cancel that. So I set my mind to delivering that on Friday and was able to do so, in a way I feel was good. It went much better than I had anticipated, which made me feel a bit better. It was also incredibly exhausting, and I've found myself to have an extra hard time keeping myself out of depression when I'm tired. I succeeded though, but again, I struggled.

Over the past years I've tried to force myself to have actual weekends more than before. I try to stay away from the computer a bit. During therapy I learned that one of the ways to try and stay out of depression is by staying active, doing things, going out. And so when the idea came up to head into the nearby city to catch Pokémon, that sounded like a good plan. It worked. It kept my mind occupied enough, distracted enough. It was still hard work to keep my head straight though. On Sunday, this resulted in me sleeping quite a bit through the afternoon. Unsurprisingly, I may add.

And now it is Monday. The day started just as bad as the previous days, but somehow as the day progressed, my head cleared. And for the first time in 5 days, I started feeling quite well again. By the end of the day, my head had cleared. What's left is this tired feeling in my head. I'm pretty sure that will clear though.

It's been a long 5 days, but I've survived. And while I never can tell for sure, I'm pretty sure it had to do with me setting priorities. Going out with the family on Saturday, not working on either this blogpost or my keynote for PFCongres next Saturday or my talks forZendCon the week after. And while I'm sorry that this blogpost is a bit too late, it illustrates all too well that it is important to set the right priorities. The great thing is that many people had their priorities right last week. This list of articles is the proof of that.

PHPStorm & OSX: Mouse Stopped Working

This is just as much a post for future me as it is for the rest of the world.

While I was working on preparing a training for the end of the week and was using PHPStorm to create some example code, all of a sudden my PHPStorm stopped responding to my clicks. I could click whatever I wanted, it just would not work anymore. As you can imagine, this is quite frustrating when you're trying to get some work done. The weird thing was: My trackpad worked anywhere else in OSX, just not in PHPStorm.

I took to Twitter to vent my frustration, then tried the more constructive approach of tweeting to @PHPStorm with this problem:

@phpstorm somehow my PHPStorm does not respond to mouseclicks anymore, just to keyboard strokes. What can I do to fix this?

Kevin Boyd quickly responded with a link to the Jetbrains forum. The problem seemed similar, but aside from "reinstall the IDE" there was not really a good solution there. While I was searching for other people that may have the same problem, another tweet came in, from Damon Jones:

@skoop @phpstorm Mac? You've zoomed the window slightly (pinch to zoom). Zoom back to normal and you should be okay.

OK, that seems very weird, but let's see what happens if I "unzoom" while in PHPStorm. WHOA! This was it! Apparently, while using my trackpad in PHPStorm I had accidentally pinched to zoom just a little bit. Not enough to be noticable, but enough to make PHPStorm stop responding to any mouse interaction.

Thank you Damon. I owe you a beer at a conference some time.

Win a FREE PHPNW ticket

I've said it before and I'll say it again: PHPNW conference, every first weekend of October in Manchester, is the best PHP conference I've ever been to. I buy my ticket blindly as soon as they go on sale every year. I've been accepted to speak very regularly in previous years and then raffle off my ticket. I was not expecting to need to do that this year, since I did not get accepted to speak. I was looking forward to experience PHPNW as a delegate this year.

Things have changed though. Unfortunately one of the speakers had to cancel their speaking and I've been asked to be the replacement. Of course I said YES! Speaking at PHPNW is a fantastic experience, and I'll gladly help them in a situation like this. But this also means that I don't need my ticket anymore.

This means, however, that I have a spare ticket. As it has become a tradition by now to raffle my conference ticket once accepted as a speaker, I'm again raffling my PHPNW ticket. The ticket has full access to all events of the main conference, including the hackathon on Friday, the social on Saturday and the Sunday conference day. The only thing is: The conference is THIS WEEKEND!

So: If you want to win my ticket, the only thing you need to do is send me an e-mail: Please only send an e-mail if you can actually make it this weekend. On Wednesday I'll do a random draw of the winner and send them an e-mail.

PHPNW will be awesome again. See you in Manchester!

The Speaker Package

I've been meaning to write more about speaking recently, so after I wrote about my personal CFP rule, let's write about a very related topic: The Speaker Package.

What is it?

The speaker package is the term used for the package of reimbursements and other advantages you have as a speaker. This may (or may not) include a free ticket to the conference, travel and/or hotel reimbursements, a speakers dinner and some other things.

Why is it important?

When submitting to a conference, it is important to realize what the speaker package consists of. For instance, if you can not pay for your own travel or hotel and don't have an employer that does so, you need to be sure that the conference can cover this. Also, for planning purposes it may be useful to know about speakers dinner, so that you block your calendar so you are able to attend it.

I made the mistake once of making assumptions about the speaker package (in this case: I assumed travel was being reimbursed) when submitting proposals to a conference. I got accepted, but then found out my flight was not covered by the conference. Because of that, I had to cancel that conference. Cancelling a conference is never fun, but especially not because of something like this.

Speaker package unclear? Ask!

If something is unclear about the speaker package, do not hesitate to contact the conference about it. I've found that many conferences these days use OpenCFP for their call for papers. The OpenCFP standard template contains some information about the speaker package, including:

Complimentary airfare/travel (according to conference policy)

Unfortunately, conferences usually do not elaborate on what this conference policy actually is. Since some conferences only give partial reimbursements for airfare, you're never really sure how much of the flight you're going to pay for yourself. If a conference has this standard text and no additional information on their reimbursement policy, just get in touch with them! Get them to clarify this before submitting to their CFP.

Another personal rule

In my previous article I explained about my personal rule to not submit to a conference unless I'm sure I can make it if I get accepted. I have another personal rule, this one concerning the speaker package:

I will not submit to conferences that do not make an effort to reimburse their speakers

Unfortunately, there are conferences out there that do not offer to pay for anything for a speaker. These conferences mostly seem motivated by the idea that "you're already coming to this conference anyway, so become a speaker while you're here". I can sort of understand this sentiment, but I personally feel like this implies a certain lack of respects towards the speakers.

Speakers invest a lot of their time in a conference. They spend hours, sometimes days on preparing a talk, creating slides, rehearsing it, finetuning it, submitting it to conferences. They also spend a lot of time on the conference: car trips or flights, actually being at the conference, talking to people before and after their talk. They even spend money because they come to the conference: They need to eat and drink, park their car, etc. If the speaker is a freelancer or entrepreneur, they'll also miss income because they can not make billable hours while at the conference. All this is a huge investment, to be part of the conference. Speakers are usually passionate and willing to do this, but when conferences do not even make an effort to reimburse at least part of this, this is a reason for me to not submit to a conference.

It is the effort that counts

I'm not saying that all costs should be reimbursed. As I mentioned before, speakers are usually passionate and willing to invest in conference speaking. I know I am more than willing to do this. I've spoken at conferences where travel is not being reimbursed (the best PHP conference in the world does not reimburse travel) and I've spoken at conferences where I offered to pay for travel (because the conference offered sponsorship packages in return for covering travel). All of these conferences have one thing in common: They all offer to pay for (part of) the cost of speaking. And in case of PHPDay, they even offer a valid way out of their reimbursements by offering sponsorship in return for not having to reimburse. It is the effort of trying to cover expenses that counts to me.

So now what?

Next time you open the CFP page for a conference, look for the speaker package information and make sure that it meets your requirements. If you have an employer, talk to them to figure out if they can perhaps cover part of the cost, so you can help make the conference an even bigger success. If anything is unclear in the speaker package information, get in touch with the conference to clarify before submitting. And if it doesn't meet your requirements, simply don't submit.