Skip to content

It’s all about culture

Culture is not a Crime by Dawn EndicoDear Reader,

The problem of hiring PHP developers is actually deeper than just finding developers and collecting resumes. You are hunting for a scarce and prized person. To succeed you need to be able to attract them, and then convince them that they want to use their skills to further your company’s goals. To do this, you need to show them that they will be happy at your company. This comes down to culture.

Culture is not having a foosball table in the break room, or a kegerator on tap 24/7. Those are trappings. Trappings – silly benefits made up to help get developers in the door and then keep them at work as long as you possibly can – worked well in the late 90’s. After the first bubble burst, developers began to see them for what they really were.

  • Free lunches
  • Dry Cleaning Service
  • On-site gym
  • Social hours
  • Movie nights

All of these and more have been employed by companies with the single goal of keeping their developers on premises and working for the maximum number of hours. This is not culture. Culture is recognizing that work is only a part of someone’s life. That work-life balance is important. Culture is knowing that while a project may be important to the company, it should never be more important to a developer than the other parts of his life; family, God, community, etc.

The bedrock of a good developer culture is respect. Respect for the fact that you have developers to build things on which the company is based. Respect for the fact that without developers, the company most likely would not exist. Culture is not putting developers on a pedestal and offering them trinkets as tribute. Culture is understanding that developers aren’t cogs in a machine that can be replaced on a whim. If you build a culture of respect, you will find it much easier to hire developers. If you get this right, the rest is easy. Like a house’s foundation though, if you don’t get this part right, the rest doesn’t matter. In the long run, your developer culture is only as good as the foundation it is built on.

Until next time,
I <3 |<

Photo Credit: “Culture is not a crime” by Dawn Endico.
Used under CC:By

Recruiting 101:Posting Jobs to a Mailinglist

Dear Reader,

Those of you who know me know that I speak to 2 recruiters these days, Lonnie Brown and Scott Gordon. (With a hat-tip to Scott’s partner Alex Nadell, who doesn’t piss me off either) I have little patience with recruiters outside of those 3. One of the main reasons is I fell that recruiters, other than Scott and Lonnie, don’t bother to figure out how to “speak developer”.

One of the things you learn real quick when dealing with developers is that there is a pretty strict mailing list etiquette. The problem is, the rules are different for each mailing list. There are some universal truths though, especially when posting jobs to a user group mailing list. Since I’ve seen this flare up recently, I’m going to share with you a few of the rules.

Rule Zero – Check the List’s Rules First

A lot of User Groups don’t allow recruiters to post on their main list. This is their privilege. If you can’t determine whether it is acceptable, ask before posting. It is NOT easier to ask forgiveness than permission in this case. It is a lot harder to get unbanned from a list than sending an email to the list asking permission.

Rule One – Don’t Hype

Don’t tell us it’s a GREAT opportunity. You have no idea what our current situation is, so you are not in a position to make that judgement call.

For most developers, a great opportunity looks like this:

  • Hires us for what we can do, not where we are located
  • Pays a salary that is commensurate with the contribution to the company
  • Understands that we, not they, are the experts at writing software, and treats us with the respect deserved

You can probably begin to see now why we roll our eyes when we see GREAT OPPORTUNITY.

If you absolutely MUST hype, run your client through the “Joel Test” first. Any company that scores 12/12 on the Joel Test can rightfully be considered a great opportunity. otherwise, skip the hype and just tell us about the job.

Rule Two – Gives Us Information

To fill all the space left in your job posting when you took out the hype, give us facts. Two important facts are:

  1. What does the job pay?
  2. Is your client more interested in what we can do, or where we sit each day?

Yes, clients hate revealing how much the job pays. However, if you tell us, we can figure out if we can afford to take the job. A lot of us have families and we know our burn rate. If you send out a job that sounds awesome but pays lower than we can afford to make, you waste your time and ours. We can help you by not wasting your time on jobs we can’t afford to take.

Also, if your client won’t consider a remote worker in this day and age, expect to have a hard time filling the position. In case you haven’t noticed, there are more development jobs out there than there are developers looking. ’nuff said.

Rule Three – Don’t Feed The Trolls

We all make mistakes, you are going to also. If you slip up and post to a list you don’t have permission to, if you post a message with the title in all caps, if you misspell something, or if you generally make a nuisance of yourself, you are going to get an ear full from the list. Take it in stride. You have no idea what we are going through and it could be that you did something stupid on a bad day and someone just needed to vent. It’s gonna happen. What ever you do, do not reply to the list and apologize or explain yourself. If they don’t ban you from the list then you’ve got another chance. If you reply, you just make it worse.

Read and think about each criticism given. Some are just going to be mindless rants, others will contain nuggets of truth that will help you do better next time. Read them, think about them, take them to heart. DO NOT REPLY TO THEM.

Rule Four – We are Developers, not Rockstars, not Ninjas, not Gurus, not Mavens, we are Developers.

No matter how cute you think it is, if you use one of these terms in your ad, we roll our eyes and hit the delete key. Before you use any term like this to describe a developer, read this. Then, if the pay scale measures up, go ahead and ask for a rockstar. Otherwise, take it seriously and tell us what you are actually looking for.

Wrapping it up

One final note, this is not a rule, it is just advice. A job posting is a sales piece. Gone are the days where you could simply put something out on craigslist and get 150 resumes – 10 of them actually qualified. You have to sell US on the job. Then, if we are interested, we will sell you on our skills.

Pay attention to these rules, learn to talk to developers in their language, and most of the time, we’ll let you hang around. Buy the beer once in a while for the meeting and we’ll let you hang out and drink with us. Learn who we are, what we do, and what we want to do…and then bring us those kinds of jobs, and we’ll do business with you.

Until next time,
I <3 |<

p.s. If you are a recruiter, especially if you are new to recruiting, you need to study Lonnie Brown and Scott Gordon. Follow them on twitter, read their blog, study how they interact with developers, learn. They have very different styles, but they both understand how to talk to developers. If we had more recruiters that those two gentlemen, we’d have fewer blog posts like this.

How do I find good PHP developers?

Dear Reader,

Twice this week I got asked a similar question, “How do I find good PHP developers to hire?” The first one was a recruiter who had originally tried to hire me because she “read my resume”. (Obviously, she skipped over the part where I’ve not written any serious code in several years) Since she didn’t bother to really read my resume to begin with, I’m pretty sure she won’t bother to read this post.

The second one, however, was a just someone trying to find PHP developers for his team. Since he wrote me a nice email asking advice, I decided to reply in kind. Three pages and one thousand words later, he had my answer. (Honestly, I didn’t expect it to be this long) I share it here with you – slightly edited to remove some geographically specific advice that probably won’t apply to you – in hopes that when you are in the same position you can get a head start in finding good developers.

Why won’t you call me?

Dear Reader,

I have exactly 1 friend who is an IT recruiter. Don’t get me wrong, I know a lot of them and even speak to most of them but in my entire circle of friends, only one of them is a recruiter, Scott “The Anti Pimp” Gordon. Scott isn’t like other recruiters, which is probably why we get along so well. He’s rude, brash, more than a little profane, most of all though, he understands how to talk to developers.

Recently Scott posted on his blog one of his usual rants, “I could care less what they say….“. The post itself, while interesting, does not really stand out among Scott’s posts; it’s good, not great. However, it seems to have set-off another recruiter who felt it necessary to comment on the post and even exchange emails with Scott about the subject matter. Scroll down after you have read the blog post and read the comments, paying special attention to the exchange between MattyMatt and Scott. Go ahead, read them, I’ll wait.

Ok, if you’ve read them then this blog post is about 2 things that come out of that conversation that exchange.

Open Teams

[UPDATE: New Slides posted, the link is below.]

Dear Reader,

Pop Quiz: How many of your developers wake up in the morning excited to work on your project? If the answer is not “all of them”, you probably need to look at how open source projects attract developers and motivate them to write code for free.


Put yourself in your developer’s shoes for a moment.
You are a professional developer, you work on a project all day at work but you live to get home and start working on your passion, an open source project. Suddenly, instead of slogging through the day, you are actively engaged in a project that may be much more complex than the one you are working on at work. Worse yet, you may actually have more responsibility, more input, more voice on your open source team than you do at work. You wish your day job excited you as much as your open source project. You wish you could be as engaged in it.