Left On The Web

The Inter-team Standup

| Comments

For WeCamp 2014, we were creating multiple teams that would all work on their own project. But since we wanted to maximize the exposure of all delegates to the lessons learned by all teams, we needed to create a moment where people could exchange their ideas, their lessons, their work.

Since our schedule already contained a 15-minute standup meeting for each team, it was not hard to come up with the idea of organizing a central stand-up meeting with all teams.

Our Inter-team standup was simple: All members of all teams would be meeting together. Each team would appoint a single representative that would tell everyone what the team had been working on, what challenges they encountered and what solutions they’d chosen. For us, not just the what was important but also the why of decisions. Since we want people to not just learn about the approach but also why this approach was taken, we tried to put some focus on that as well.

Taking this outside the camp

Recently at a customer, we were having a discussion about how to improve the communication between the different development teams. Both teams work (partially) on the same codebase, each with their own responsibility. While doing their work, they may (try to) solve the same problems. That seems inefficient and may result in inconsistent solutions to the same problem.

During this discussion I thought back of WeCamp and proposed we would try this approach. This week we had our first standup, which was quite interesting. It’s good to hear, in just a couple of minutes, what the other team is working on and what problems they are solving. We did notice that the meetup needs a bit more preparation from the teams to make it more efficient, but the concept of having a (in our case) weekly meetup of 10-15 minutes seems to work well.

Don’t replace normal communications

It is important to realize that this meeting is not meant to replace all other forms of communication between teams. Aside from this, it is important that individual team members can visit the other team when they have a question, that they have Skype/Slack/HipChat/IRC to communicate, that they talk to eachother by the watercooler or coffeemachine and that they go to lunch together. The inter-team standup is simply an organized and structured way of exchanging challenges and possible solutions. So far it works, I’m curious what more this will bring.

Stop Fighting

| Comments

I posted this on Facebook about an hour ago, but this is not limited to Facebook. It should not be. So I’m reposting it here.

Today was a day like any other, except that it wasn’t. It was an official day of mourning in The Netherlands. This morning as I woke up, it was still a day like any other. When I got into my car to drive to work was the first time I noticed a difference: Other music, special requests. As I got to work, nothing was different and actually work was no different. A full day of work, a meeting that lasted until just after 4 o’clock so I completely missed the minute of silence. A day like no other day. Since I went home a bit early on monday and I wanted to finish a couple of tasks that I had left, I stayed a bit longer. That “bit” became quite a bit longer as I ran into a colleague and talked a bit.

I started my way back home in the car. Turned on the radio. Again, the radio felt “odd” yet also comforting because of the special programme. Aside from some tweets and pictures, I had not seen anything of the return of the first victims, I’d not followed it yet. While on the highway, I heard the report of the motorcade of hearses travelling from the airport to the army base where they will try to identify the bodies. Bit by bit, the music, the reports, the tweets, it kicked in.

As I neared the exit of the highway that I need to take to go home, I heard where the motorcade was. A quick calculation later I realized that if I’d stay on the highway, I could reach the route they’d be taking easily. I wasn’t sure. Should I? Isn’t that just sensationalism. I decided it wasn’t. I just wanted to pay my respect, especially since I wasn’t able to join the minute of silence.

I am so glad I did decide to go on. It was a surreal experience. First of all, as I turned onto the highway the motorcade was going to use a bit later, there were thousands and thousands of people standing on the side of the road. Even in the opposite direction, cars were stopping on the side of the road. So many people. Police was trying to ensure safety of people, but they weren’t enforcing the law. Obviously it’s usually not allowed to stop by the side of the road like this. Much respect to the police for the way they handled everything, giving only focus to safety and nothing else.

The motorcade came. That was odd. Strange. Impressive. Fourty hearses, one after the other, several of the drivers with tears in their eyes. I could do nothing but stand there and watch. Silent. Tears in my eyes.

I usually have very little faith in humanity. We’re destroying our world, we’re destroying eachother. What happened is proof of that. But what I felt today, while standing there, the enormous amount of people all there to pay respect, to welcome the dead bodies home, the love, respect and sadness mixed together, shared with everyone there. What a crazy experience. It restored a bit of my faith in humanity. It is possible to have this, unfortunately it will never last long.

I had tears in my eyes for the whole trip home. And as I write this, the tears are again forming. Never, ever in my life will I forget this. But never ever in my life do I ever want to see this many hearses drive by. Ever. Can we please, please all stop fighting eachother?

What We Can Learn From Code Spaces

| Comments

A sad thing happened earlier this week to the (d)vcs hosting service Code Spaces. An unauthorized person gained access to their Amazon controlpanel, and after an attempt to extort money out of Code Spaces to stop a DDoS on their services, (s)he started deleting their Amazon instances. Everything. At the point where the Code Spaces people were able to stop this from happening, nearly everything was gone already.

This hacker rendered Code Spaces dead. According to the statement published on the Code Spaces website:

Code Spaces will not be able to operate beyond this point, the cost of resolving this issue to date and the expected cost of refunding customers who have been left without the service they paid for will put Code Spaces in a irreversible position both financially and in terms of on going credibility.

This is extremely sad for all those working for Code Spaces. Obviously, it’s not good for the Code Spaces customers, but they’ll replace the Code Spaces services with something else. The people involved with Code Spaces itself just lost their job, their company, in the period of about 12 hours. That is horrible.

What can we learn?

At this point, I can only speculate about how this hacker gained access to the Code Spaces Amazon account. But however (s)he did, we can learn from this. The hacker did not start deleting instances until after it turned out Code Spaces was trying to regain access to the control panel. There were backup accounts created already, so even though the main account had been restored, the backup accounts were still there. When trying to recover from such a hack, always check the accounts section to make sure there are no backup accounts present.

The most important lesson…

The most important lesson is actually not one of security. It is one of redundancy. And it’s not just a lesson we learn for our own infrastructure, it’s actually one we need to learn for everything. For all of our software projects.

This time, it was Code Spaces, a relatively small player in the (d)VCS hosting market. Next time, it may be Github or Bitbucket. Sure, I am convinced something like this could not as easily happen to these, but let’s just say this would’ve happened to Bitbucket. How would you have deployed a new version of your software? How would you have run your continuous integration? Every composer install or update would fail horribly, because we rely on the Github infrastructure for that. A huge part of the (PHP) software development would simply stall. I’ve seen it happen before when Github was down. And I’ve seen Github go down just as we were deploying an application. That is a horrible situation to be in. You surely don’t want that.

We need more redundancy. If you run an open source project, it might be wise to publish it to more than one channel (perhaps use Bitbucket next to Github). Again, I don’t expect something to happen to Github, but you may never know. Shit happens, and we better be prepared.

Perhaps Composer (or Packagist) needs to be changed for this as well. Although, perhaps not. Just yesterday Jordi blogged about Toran Proxy which, amongst other things, protects against GitHub outages and such.

Most importantly, we need to be aware. We take things for granted way too much. Things may change, services may disappear. We need to be prepared for this.

Bristol UK Area, You Need Me

| Comments

Yesterday, @phpsw tweeted:

also, still looking for people to speak about testing/CI in July/August, if anyone wants to volunteer before we start searching/goading :)

I, sort of jokingly, responded with:

@phpsw if someone can give me a good reason to travel there I could ;)

I say “sort of jokingly” because:

  • I’d love to speak on the topic
  • I’d love to visit a usergroup I’ve never been to
  • I realize just travelling to the UK for a usergroup is expensive and a lot of effort

The discussion went on a bit more and Phil Sturgeon entered the discussion, inviting me for cider and noting we hadn’t met in way too long. I agree, and I’ve not really tasted many ciders yet, so an expert on cider could definitely teach me a thing or two. So I asked him:

Nobody in your region in need of a 1-day consulting?

This prompted Phil to tweet out a call to anyone that may need something:

Dear the West Country: Who would like @skoop to come to their office and do some PHP/Symfony consulting on July 1st/2nd? @phpsw #php

This started out as a joke, but I seriously want to go and travel to speak at the phpsw usergroup. So here goes nothing:


I’m offering a discounted price for the company that flies me out for a single day of consulting or training. I’ll happily brainstorm about your application, help you fix issues with your PHP application, give some training on PHP-related topics, review or audit your code, or just hang out at your office. My normal single day rate is ~1000 euro, but the company that agrees to fly me over to speak at phpsw will get a 50% discount. I will work for you for the day for 500 euro + whatever the cost of the flight is. Let’s make this work! Interested? Tweet @skoop and @phpsw, or e-mail me: stefan@ingewikkeld.net.

Want to Be More Productive? Work Less!

| Comments

There are many people (myself included for a long time) that will work more and more when they have more stress. Whether it’s a deadline or simply too much work on your hands, you just start working longer, open your laptop when at home just to finish that one feature, skip lunch or ignore your RSI-breaks. While this may sometimes work, in the long run, this will only make you less productive.

Less productive?

Yes. In the long run you will be less productive for several reasons:

  • You get tired very easily because of lack of rest
  • You get really stressed
  • Your real life will suffer, adding more stress
  • Your constant focus on work will narrow your vision, making it harder to solve problems because of tunnel vision
  • If you suffer from RSI or related arm/wrist-problems, they will get worse

I’m pretty sure there are more reasons than just these, but these are some reasons I’ve found. I notice that if I work too long and focus too much I easily get one or several of the above problems.

Take back that productivity

Becoming less productive may introduce a vicious circle: You get more stressed because you are less productive, you get less work done, that causes more stress, etc, etc. So make sure you take back that productivity or, preferably, prevent losing your productivity. Here’s a few things you can do:

Take breaks

When trying to solve a problem, take a break when you get stuck. I know this is a commonly known solution, but some people still need to hear this. Taking a break and doing something completely different (at my current client, that’s fussbal) helps clear your mind so you can look at things with a fresh perspective when you get back. Even just going for coffee or taking a toilet break can already help.

Even when you’re not stuck on a problem, try to take regular breaks. Consider the Pomodoro technique, which gives you short bursts of productivity with regular short breaks in between. Doing this will prevent you from even getting stuck on a problem in the first place. There’s several apps for computers, tablets and mobile devices that serve as a timer for pomodoro. And even you don’t strictly adhere to the pomodoro technique, just taking regular breaks will help you.

Take regular days off

Short breaks may help during your workday, but every once in a while, you need to recharge your internal battery. Taking a day off every once in a while is a great idea! In most countries, you should have enough vacation days to, just once in a while, be able to take a day off.

Leave your house

Taking a day off is a good idea, but when you do, it might also be a good idea to get out of your normal environment. Leave your house. Go on a long bike ride, visit a themepark, just break out of that normal environment. Sometimes, home may remind you of the stressful period you are in at work and that doesn’t help you unwind. Leaving the house and going somewhere else may just be what you need in this case.

Holidays are good

Aside from single days off, make sure you go on a holiday. Some people go on a long summer holiday, other people take multiple short holidays, it doesn’t really matter, as long as go on a holiday. I personally prefer regular short trips, but for instance Mike took a whole month off at the beginning of the year and Jelrik will be doing a similar thing soon. You need to find the right way of taking a holiday. Whatever works for you, works for you.

Don’t always work from the office

An office can be a stressful place, even if your work is not stressful. People around you may be stressful, people may interrupt you while working, there may be too much noise for you to focus, or too little noise to focus.

Don’t always work from the office. If your employer allows remote working, then make use of this. And don’t just work from home, but go work in a co-workingspace, coffee shop or hell, you could even work from your tent on an island!

Do “fun work”

Sometimes it is good to break out of your normal work cycle by doing some “fun work”. Fun work can be different things, depending on your preference:

  • Finally refactor that bad implementation that has been bothering you for ages
  • Do some research on a new technology that you’re interested in
  • Have a brainstorm with the rest of your team on how to improve your codebase

These are just a few suggestions, I’m pretty sure you can think of more. The most important thing is that you can get your mind off of your regular work, yet still do something that is useful, a task that needs to be done (even small unimportant tasks can add to your stresslevel).

Kill that stress

I’ve been having some stress-related issues recently where I’d had a hard time focussing, I was feeling ill (I’ve actually had to take some days off in the past months because I was physically feeling ill that I suspect was actually stress-related), tired or just not happy. Since we started going to Vlieland, where we have a tent, I noticed that my stresslevel dropped considerately. Even while having to do some work from there, the completely different environment, the laidback atmosphere and the fresh air ensured that I felt much better.

I’ve also recently done some small sideprojects: Help one client by analysing several price quotes they got for a project, meeting with another potential client that might need some expertise, fixing some bugs in a project of a former client, things like that. It helps to sometimes just do something other than what you’re doing all day.

And even now, while I sit here in Chicago in my php[tek] hotelroom, I feel I get a little bit less stressed. This blogpost has been in my head for a couple of weeks now but I couldn’t find the time to actually write it. So I skipped some talk and sat down to write this. One more thing to remove from my TODO-list. And hopefully, it helped you a bit as well.

Be Yourself, Stay Yourself

| Comments

Today I spoke a short bit at the funeral of my grandmother. I told my family about an important lesson I learned from my grandmother. I’d also like to share this lesson with you, as I think it is an important lesson for everyone.

When I was a teenager, I suffered a lot from acne. This became a huge issue for me. My grandmother kept telling me one thing: Ignore other people making fun of you. Just be yourself and things will get better. Now, many people told me similar things, but the message was much stronger from my grandmother: She had a skin disease in her face that everyone could easily see, so clearly she knew about this.

The thing is: I did stay myself. I tried to ignore other people making fun as much as possible and I tried to stay myself as much as possible. Whether or not I completely succeeded I will never be able to say, but one thing I know: Until this day, I am myself. I don’t listen to people telling me to change. I only try to change when I feel this is a good thing to do. So no, I don’t walk around in a suit while running my business. If you hire me, you hire me for one reason only: My knowledge and experience with software projects, with working with the community, etc. I say no to clients expecting me to dress smart or wear a suit.

I’ve been accused of being unprofessional by behaving this way. I feel I just am me. I am Stefan Koopmanschap, and this is me.

And thus I am here to say to you: Keep being you. This is why your friends like you. This is who you are. And of course you can change. You can change who you are, but only do so when it feels good to you. If you’re being asked to wear a suit and it feels good to you, there is no problem. If you are asked to wear a suit and you hate it: DON’T. If you’re asked to learn Java and it feels good to you, go ahead! If it doesn’t, DON’T. You are you.

WeCamp: Everybody Is Welcome!

| Comments

Last month we announced WeCamp, an event where developers can improve their skills not just by listening to people, but also by actually doing things. Response has been amazing: Many people love the idea, we’ve already sold quite a few tickets, and we’ve even got Magma giving a ticket as a price (At the time of publishing of this blogpost there’s only a couple of hours left, so if you want to win, be fast!). Since announcing the event, I’ve talked to several different people who had the same doubt/question about the event, so I thought I’d clarify things a bit more.

Who should come to WeCamp?

Everyone! We don’t want to exclude anyone and we actually think everyone would be a huge asset to the event. I’ve had people say “I’m not experienced enough in development to attend”, to which I could only respond “untrue!”. The idea of WeCamp is that you don’t just train your technical skills but also your social skills. For a less experienced developer, the practical experience of working in a team with more experienced developers is priceless. In that same team, however, the most experienced developer gets the additional experience of helping a less experienced developer with the work, gaining a lot of experience and knowledge on how you can help others. This social aspect is easily just as important as gaining technical skills. So both developers come out of this gaining experience.

But I’m a frontend developer…

So? If you’re a frontend developer, have a look at the many websites created by pure backend developers… do they look good? Are they accessible? Built according to W3C standards? Most probably not. You’re needed! While we have a focus on PHP, you’ll learn to work with PHP developers: How to communicate with them, how they look at frontend work, what tools are available in the PHP ecosystem for frontend. And I know this may sound scary, but you’d perhaps even get some PHP skills as well.

Additionally: WeCamp is not just about technology. We’ll go through all stages of a project, starting at thinking of a good idea through planning to development, deployment and perhaps even marketing! There’s more than enough to learn throughout this whole process.

But I wonder about…

If you have any more doubts or questions, please let us know! This is the first time we’re organizing WeCamp so we’re still very much looking for what works best with a lot of things. If there’s any unclarity, or you have comments for improvements, let us know! You can always tweet at us @wecamp14 but you can also shoot us an email: we-can@weca.mp. We’re also here to learn, so please help us do just that!

Why Your Current Developer Is Terrible

| Comments

Earlier today I got pointed on Facebook to this article by Shamoon Siddiqui on Medium.com. I would very much recommend this article to both developers and managers. This is an excellent read. It also made me think about my role.

First of all: I’ve been on both sides of the above story. I’ve been the new developer hating on the previous developer, and I’ve been the guy who left hearing stories about the new developer. And to be honest: When you’re a new developer looking at an existing codebase, you’ll spot a lot of bad things. You’ll probably also spot a lot of things that you think are bad things, but are simply different than how you would’ve solved it. There is a difference!

My current role is different. As a consultant, I come into companies with existing teams (or sometimes just a single developer). I’m still in the same role though: I am the “new guy” coming in and spotting weaknesses, errors, problems etc. The difference, however, is that I’m there for this specific reason: I’m usually called in to help improve a codebase, fix a project, etc.

Over the past years of doing this work, I’ve also found out that there are many reasons why the codebase is, let’s say, suboptimal. This has to do with many things, but interestingly, very often it has very little to do with actual technical causes. Just to list a few:

  • The developer presented himself or herself as a senior, while they were actually not that senior
  • The management was not able to make decisions, causing developers to have to switch between tasks and solutions constantly
  • The developer(s) and management don’t communicate well
  • Sales and delivery are two seperate isolated parts of the company

There are more reasons, but the above are the most common reasons I’ve encountered so far. Let me dive into all of those a bit more.


I’ve seen it happen many times: A new developer is hired by a company. Their CV looks impressive: 8 years of experience with PHP. Definitely a senior developer! And since we need to focus on good quality, we need a senior! Then once the developer starts, it turns out the developer isn’t all that senior. Tasks take longer than expected, the software contains more bugs than expected, what happened?

Now, the first problem is: What is the definition of a senior developer? To me, a senior developer is not necessarily someone with lots of years experience. You could have 8 years of experience building websites and CMS’es for customers, but when you join a company building enterprise-level e-commerce solutions, you’re not a senior. Sure, you know PHP and you’ve solved the CMS-problem over and over, but what’s your experience with payment systems? Invoicing? E-commerce has a completely different set of problems to solve. Some solutions that work for a CMS might not work for E-commerce. Seniors know this. They don’t know the solution to all the problems, but they know the solution is not always the same. They communicate well, can explain a problem, and know where to look for a solution. A senior knows (s)he doesn’t know everything.

When hiring a developer, don’t blindly look at how many years of experience the candidate has with PHP (or whatever language you work with). Also have a look at the variation of the projects the developer has worked on. Unless, of course, your company operates in the same business as this developer with 8 years of experience in a specific field. Then you do want to hire the developer. Well, if everything else checks out.

Decisions, focus and quality

Talk to any developer and ask them what is one of the biggest causes of bad code, and they’ll tell you it is a lack of focus. Not being able to focus on a single task from start to finish ensures the code that is being delivered is of less quality than it could be.

One important reason for a lack of focus is not the fact that your developer checks their Facebook or Twitter regularly, or that they go out for some football or play on the gaming console three times a day. No, it’s usually that your developer(s) are not protected from distraction caused by the business.

When I worked at a product-focussed company years ago, we had this issue. On a regular basis, while working on a feature, someone would stand at the desk of a random developer and ask them to “quickly do this” or “fix this bug, it’s highly critical!”. Because of this, we never made our planning and the amount of bugs in our code was sometimes unacceptable.

Our team lead then made the best decision ever: He told us to redirect everyone to him. He would then decide on the priority of the request and put it into the planning. This was paradise! Within weeks, people didn’t even come to us anymore, but instead went directly to the team lead. We could focus on our tasks, reached our goals, and the quality of our code was higher than ever.

Our team lead, however, got no programming work done anymore. Instead, he would gather requests, determine priority and requirements and ensure all the tasks were ready for us to pick up. Another very important task: He made sure that the request was an actual decision, instead of just an idea that would have to be rolled back again in a month. A lot of bugs are caused by implemented features that have to be rolled back, partially rolled back or changed after being implemented.

Looking at current methodologies, the scrum master role comes to mind. But you shouldn’t just name someone scrum master and expect things to work well. Being a scrum master is usually a dedicated task. You can’t really expect the scrum master to get much work done aside from being a scrum master. At least not if you want the scrum master to do a good job.


Good communication is an art. It is a specialty. As I said above, a true senior developer is able to communicate. Communication isn’t easy.

The most important thing in communication when it comes to (technical) projects is to ensure that both sides mean the same thing. This can be really hard, because of very specific terminology being used by developers, customers, managers, etc. They all use different words for the same thing, or sometimes the same word and mean different things. It is important to realize this. Once you know this happens, you can ensure that you all mean the same thing. If a feature request comes in, make sure that the specifications are extensive. Go through the specifications together to ensure you’re on the same page. Do anything you can to ensure you mean the same thing, then both sign off on it.

Whatever you do, always try to keep an open mind in communicating with everyone. Make no assumptions and try to clear up any unclarities there are. This makes a lot of sense, and seems common knowledge, but I’ve seen so many problems arise from not actually doing this to want to write this down. Again. And again. And yes, I’ve fallen into this trap.


One of the worst situations I’ve ever been in (at several different companies, a lot of people seem to make this mistake) was that sales was an isolated team. They’d go out to customers, talk to them, try and find out what they wanted, then “communicate” (yeah, see what I did there?) the requirements to the developers to get an estimation. Then they’d go back to the customer with the estimation and a price. The customer (it is a customer after all) would try to get a lower price, which usually would succeed, and then the project would be given to the developers. Development would take up the specs, build what was in there, deliver it, and the project would (partially) fail. Time and time again.

The cause of this would usually be the isolation of both sales and delivery. Sales did their thing, then delivery did their thing. But they’d hardly ever communicate. This would cause incorrect specifications, incorrect estimations, incorrect end products and unhappy customers, developers and sales.

It might sound scary, but development is teamwork. And the team consists not just of developers, but also of sales. You work together. Talk to your customer together. Write specifications together. You share the praise together and you share the blame together. Sales needs to understand how development works and developers need to understand how sales works.

So why is my current developer terrible?

Actually, your developer isn’t all that terrible. Chances are, the developer is exactly what you could expect of him or her. Your expectations might be wrong though. Or you might need to work on communication, on processes, on your company. Have a good look not just at development, but at your company as a whole. Then you might understand the cause of the problem. Or, of course, hire a consultant to do that. Here’s a good place to find one.

WeCamp Excitement

| Comments

Last night I made one of the most exciting announcements of my professional life. At the AmsterdamPHP meetup I announced the first conference-like event that we’re organizing with the Ingewikkeld-crew. One of those things that I’ve done quite a while now for different usergroups (organizing events) is now also part of my work, and that feels pretty good.

Ever since I organized my first event (PHPCamp) for the company I worked for at that moment (Dutch Open Projects) I’ve liked doing that. Arranging speakers, the venue, sponsors, thinking of cool stuff to do. All that stuff is awesome, and I love that. From the moment I started Ingewikkeld I wanted to do an event. And we’re finally doing it!

To give you some background: I love conferences. They inspire me to dive into new technologies, research topics, hack around a bit, play with stuff. My main frustration around conferences is, though, that once I get back from the conference, I need to get some work done again. And usually that means my “technology to check out”-list only grows longer. I hardly have time to really dig into things after the conference is over.

Combine that with the fact that I learn much more when actually doing stuff and I hear the same thing from many people I talk to. I thought it would be good to do an event where people don’t just listen, but actually work on a project.

On a great day somewhere in the summer last year, Mike, Jelrik, Marjolein and myself sat down for a brainstorm. We started just throwing out ideas to see what we could do. We let it sink in for a while, and then started working on filling in the blanks, finalizing some ideas, and arranging things we had decided on.

The location turned out to be the first major challenge. Our initial idea was to find some kind of boyscout-venue. This would ensure electricity, some basic facilities and hopefully an Internetconnection. It turned out this was actually pretty hard, and we didn’t find such a location. We had a quick brainstorm to think of alternatives. Campsites were an option, but then we started considering more special locations: islands. Some searches led to island De Kluut, and after a meeting with someone from De Kluut, we knew we wanted to get this place.

There was only one big challenge: The island is very natural in that it does not have cables of any kind leading to the island. Electricity is not really an issue: They have solar energy collectors and backup generators. But the other pretty big challenge when you don’t have cables is an Internet connection. We had two main options that both turned out not to work for our situation. Eventually, someone came up with a company that provides sattelite Internet for events, and that turned out to be exactly what we needed.

For ticket sales, EventBrite was our best option and since I’d had enough positive experience from the buyer-side, and after researching it could do all we wanted, I signed up for an organizer-account and set up the event. This was very easy. The only frustrating thing was that I had to make my event public before being able to get an embed-code from their control panel. Since we were trying to create a hype by anonymously dropping some goodies at local usergroups, we didn’t want any trackable lines leading back to us. With some last-minute working, we got all of this sorted. Apparently, there were people thinking WeCamp was initiated by Ibuildings or AmsterdamPHP. Only a few people actually thought it was us.

And now it’s there. We’ve announced. A good feeling. Especially with all the positive response we get from people. Everyone basically says the idea is awesome. And ticket sales are already going better than expected. All early bird-tickets are already gone. And since we’re keeping this event small, that means there’s only 30 regular tickets left. Exciting times. There’s still much to do (organize fun activities, arrange some more sponsors to at least break even, arrange a couple more coaches, etc) but it’s a lot of fun. I’m looking forward to the last week of August. It will be EPIC. It will be WeCamp!

Some Thoughts on Recruiting

| Comments

Recruiters. Many developers hate their guts, and (in most cases) rightfully so. They usually have no clue about technology or about how to communicate with developers. It is also pretty clear most of the times that they’re only out for quick wins. I’ve seen recruiters call a developer they’d placed in a company exactly 6 months after he started to see if he wanted to move on, because 6 months was the period in the contract between the employer and the recruiter. I’ve seen recruiters tell candidates that the employer wasn’t interested, just because the employer didn’t want to pay the extremely high recruiter-fee. Hell, my first professional PHP job was like that. I ended up having direct contact with the employer because I didn’t believe the story the recruiter was telling me, and landed a pretty cool project. Some of the people I worked with there are still friends.

There is a flipside though: There are recruiters out there that do understand how things work. They know how developers work, communicate, what they feel is important. They are rare, but they do exist. So it would be stupid to just say “don’t work with recruiters” to companies or to developers. The thing with working with recruiters is: It takes time. You can’t just give a recruiter a profile and wait until they get you developers, or tell them you’re looking for a job and wait for the interviews. You have to invest in the relationship with the recruiter, do some research, get to know them, and ensure you’ve found one of the good ones.

The role of a recruiter

Many companies I’ve worked at, with or been in touch with expect a recruiter to look at their huge list of available developers (here’s your first mistake, because how many developers are actually available?) and give you the best developers based on a (usually incomplete) profile. But what exactly is it that a recruiter does?

Most recruiters have very little technical knowledge. They’re networkers, they create a network amongst developers and companies and try to link one with the other when they get a request. So from the majority of the recruiters, you should not expect that they make a judgement on the seniority of the developer or his skillset.

In an ideal world, the recruiter you work with actually has a development background and keeps his/her development knowledge up to acceptable levels. Ideally, the recruiter should be able to judge the skills and level of any developer they send your way.

Think about your reasons for hiring a recruiter

Before even contacting a recruiter, you need to ensure you’re doing this for the right reasons. Many companies simply expect the wrong things from a recruiter. As I mentioned before, you can’t just give them a profile and wait for the developers to come in.

Simply outsourcing getting potential candidates should not be your only reason hiring a recruiter, at least not if you want to save yourselves some time. The time you save by getting in the candidates, you will most probably spend doing interviews with candidates that do not actually fit your profile. The amount of times I (specialized in PHP with very little experience with other languages) got approached by a recruiter for a Java or Python-project is beyond belief. Getting 10 CV’s from a recruiter is not a good thing. It’s a bad thing. Instead, you’d want to get one or two CV’s of developers that actually are what you look for.

Even if you have a good recruiter, don’t expect to save much time on the recruitment process. Even if they immediately pass you the right CV’s, you’ll still need to make the final judgement on whether the developers are good or not, and of course convince them to work for you. You’ll still need your own HR-people to handle everything.

Take back your own recruitment

It may be worth your while to consider taking the recruitment back into your own organization. The most important task for a recruiter is to find the right developers for your organization. This may seems like a task that takes a lot of time, but it is easily combined with other stuff you already do (or should do).

The best representatives of your company when it comes to finding developers are your developers. They can speak to potential developers on the same level, can explain what the challenges are and what the fun aspects are of working for your company. They are also the best people to try and find out if a potential developer would fit your company, both in skills and in personality.

So if you have a position for a new developer, send your existing developers to usergroup meetings and conferences. Let them get in touch with other developers, potential employees. Don’t tell them to go out and find people, but tell them to keep their ears and eyes open. They should not try and force the “want to work for us?”-conversation on people, but once the topic comes up, they can of course start talking about it. And they should. The best advertisement for your company is your developers who passionately speak about their work at your company.

Invest in finding the right recruiter

There are many reasons for not putting the recruitment task on your developers. One of them would be the fact that the job opening is there because the developers already have way too much work.

Whatever your reason is for wanting to hire a recruiter, you need to invest in finding the right one. When you hire the wrong one, there’s many things that can go wrong:

  • The recruiter might start spamming his whole database. This reflects badly on your company
  • The recruiter might come up with completely unfitting developers, spending much of your time on nothing
  • The recruiter may not represent your company well, leading to expectations with your potential developer that you can’t fulfill.

If you think it through, there may be even more reasons that can go wrong when you’ve got the wrong recruiter. So invest time in finding the right one: Meet with several recruiters, don’t just hire them based on a single phonecall. Meet with them in person and try to find out how they work: How do they find the right developers? Do they just mass-mail, or do they select the right people from their database and approach those people? How do they find out what the level is of a developer?

Another good idea is to have one of your developers talk to the recruiters. Developers are pretty sensitive about recruiters so they usually have a pretty good idea about what type of recruiter they have in front of them after only a short meeting with the recruiter. Learn to trust this gut feeling. It is more powerful than you might think.

Do some research. Bad recruiters are easy to spot. They are the ones that have a lot of job openings on LinkedIn, preferably in the discussions-area of LinkedIn Groups instead of the Jobs area. They may try to start their own PHP usergroup in a city where a popular PHP usergroup already exists, just to lure developers to them. Their names get mentioned on Twitter and Facebook by developers who get easily annoyed by them. There are enough ways to spot the really bad ones. Also, since good recruiters are rare, they are often recommended by developers. You’ll find good recruiters actively participating in the PHP community, their company names may be listed as sponsors for usergroups and conferences and they’ll actually be at conferences and talk to people.


There is nothing wrong with the concept of recruiters. There are a lot of really bad recruiters though, and you’ll want to avoid them. First of all, decide whether you need recruiters in the first place. And once you decide to use recruiters, invest some time in finding the right recruiters.

Update: After some feedback from Phil Sturgeon and Ivo Jansch, I’ve slightly updated the wording of this article.