Left On The Web

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:

GET ME OVERTHERE! SPECIAL PRICE, JUST FOR YOU

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.

Seniority

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.

Communication

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.

Isolation

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.

Concluding

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.

Prototyping Your Experience

| Comments

Whether in a professional environment or in private, prototyping (or making a proof of concept) is a useful tool. It is something people underestimate though. Frequently I hear people thinking the time spent on a prototype or proof of concept is a waste of time. NO, IT ISN’T

Just this morning, I was reading this article by Ed Finkler on Tribalism and I was thinking about it. Ed describes tribalism in the tech-world, and I could totally understand what he was talking about. The fact that terms like “browser-war” and “framework-war” come by in our world. The fact that we always put Drupal against Joomla! against Wordpress is proof that we live in a tribal techworld. And as Ed writes, this is not necessarily a bad thing, but it usually comes with some negative side-effects.

I’ve done projects at a lot of web agencies where the company had standardized on a single framework or a single CMS. And with “standardized”, I mean, that was the only technology being used, and aside of perhaps some individual libraries, if some solution did not exist for that chosen technology, they’d build it themselves without looking outside of their tribe. I usually question such behaviour, and the response I regularly get is “we can’t all know everything about every (framework|CMS)”. Of course I agree with this: In the fast-moving world of technology we live in, you can’t be an expert in every available technology. The thing is: You don’t need to be an expert in every technology. You need to know just enough to know when it can be useful.

And so I get to prototyping. Prototyping (or making a proof of concept) is nothing new. It’s definitely not limited to software either. Better yet, given the dynamic nature of software and the pretty static nature of other industries, it is even better suited for those other industries; imagine building an airplane without building a prototype first. You’ll never know what’s wrong with the design of your plane until it crashes with 250 people inside.

Aside from building a prototype to testdrive your design and see if it is any good, you can use the prototyping approach also for your own good. An important thing to realize is that a prototype is not a production-ready product. It is something you build to prove to yourself that a concept works, or to try out one (or several different) approach(es). And once you’re done, you can always decide to throw away the prototype and start all over.

The thing is, you can use prototyping for the projects you do (and you should definitely consider this approach when you’re not sure about a proposed solution), but you can also use prototyping for learning things. Actually, while prototyping, you usually learn anyway. But consider using it for learning a new technology for a change.

LinkTuesday

Let’s take a practical example. When Symfony2 came out, I was deep into symfony 1. However, Symfony2 was completely new and different from symfony 1, so I needed something to try it our and learn the concepts. I decided to build a very simple website that would aggregate all the links posted to twitter with the #linktuesday-hashtag. I started my first Symfony2-project and started playing around. Once done, I decided to open source it and publish the website. But the most important thing of this project was: I learned the basics of Symfony2.

Gowat.ch

A similar example is gowat.ch. I wanted to dive into the Silex microframework. It was a hip thing to do at that time to have your own custom URL shortener, and since a microframework is a good fit for that, I decided to write my own shortener with Silex. As with LinkTuesday, the end result was good enough for me to actually put into production. For me at least. But again, the most important thing was that I now know Silex and knew when to use and when not to use Silex.

And it goes on…

You might be aware that I’m a big advocate for interoperability and using multiple frameworks in projects wherever it makes sense. I’ve done several talks on the subject. One of those talks I did with Enrico Zimuel of Zend Framework fame. We’d done a talk where we used some simple examples. Last year, we were going to do the talk again at the Forum PHP conference in Paris but we decided we weren’t happy with the examples. They were clear, but did not contain practical use cases. So we sat down together to write a prototype of an application that would actually use both frameworks, or in this case it would use Symfony2 and Zend Frameworks Apigility project for RESTful APIs. It took us a day of playing around, but we ended up with a prototype that worked and showed exactly what we wanted: That it is possible (and easy) to use the Doctrine entities from a Symfony2 project to create a RESTful API with Apigility. In the process of doing so, Enrico learned some stuff about the Symfony2 bootstrap (hell, I learned some things about the Symfony2 bootstrap), and I learned the basics of Apigility. Enrico even shared this knowledge in a blogpost.

Failure is success

The examples I’ve given so far are all examples of projects that actually made it to the outside world in one way or another. But there are many projects that I’ve started that either failed or that I just decided were not good enough. The thing with the prototyping approach is that failure is success. It’s not about the end result of the project, it’s about the process of building the prototype. It’s about using a new technology, about finding out how that technology works, how to solve the problems you encounter with that technology. It’s about gaining knowledge on which problems this technology solves, and which problems it doesn’t solve. As I mentioned before: The goal is not to become an expert, but to know when you should and when you shouldn’t use the technology, so that in a future project you can decide which technology you should use to solve the problem at hand.

The business side of things

Coming back to the agencies that said “we can’t all know everything about every (framework|CMS)”: Absolutely! However, you should be aware more of the world around you! Invest a couple of hours a week or even a couple of hours a month in working with a different technology so that you become more aware of other technologies. You don’t have to completely switch to a different technology, you don’t even have to master that technology, but just being aware that it exists is already a great asset for your company and your development team(s). You could even have different people look at different technologies and then present their findings to eachother. Or make it a competition: Have different team members build the same proof of concept with different technologies, and see which is the better solution. Enough possibilities to get more knowledge with a limited investment.

Learning is key

We work in an ecosystem that is ever changing, always evolving. New technologies come in to replace old technologies or to work side by side with the technologies we all love. It may sound cliché, but the snoozers lose in this world. Standing still is not an option. We need to keep learning. Forever.

Get Rid of Session Files in an API

| Comments

A quick blogpost about building APIs with Symfony2 and FOSRestBundle, just so I won’t forget this and can always refer to this blogpost if I start wondering about this again…

Some time ago I inherited an API project that was built on top of Symfony2 and the FOSRestBundle after the previous developer was unable to continue his work due to personal circumstances. I finished the project and everything was up and running fine. A couple of weeks ago, I got an e-mail from the customer because their systems had lots of issues. It turned out that the session-directory contained a couple of hundred thousand session files. This seemed odd, since there is a very limited web interface to this API.

The first thing I did was pragmatic: I wrote a simple command to clean out the session directory from files older than 1 hour (since sessions typically last only a couple of minutes). This was the quick fix, but it didn’t sort the cause of the problem.

This morning, I actually dove into the code to try and solve the problem. And the fix was literally a one-liner. In the firewall configuration, I just needed to add a single line:

firewalls:
    wsse_secured:
        pattern:   ^/api
        wsse:      { nonce_dir: null, lifetime: 3600, realm: "Secured API", profile: "UsernameToken" }
        anonymous:    true
        stateless:    true

The last line was all that was needed: It configures Symfony2 to work in a stateless way for this firewall. And stateless applications don’t need sessions. Such a simple fix, but it takes a short while to figure it out.