I’ve played with a few of Vagrant’s support provisioners: Puppet, Chef and Ansible. They all are very powerful and have tons of options but of course with options comes complexity. It took me hours to learn each provisioner and get it to do what I wanted and I had to fight with each one at each step.

When I first started using Vagrant I simply dismissed the simple shell provisioner. What serious developer would use such a simple tool? Real developers use real provisioners.

Anyway, long story short, I spent less than 1 hour today with the shell provisioner and got it to do exactly what I wanted. I guess I like to pretend that my provisioning needs were a lot more complicated than they actually were.


I can’t say I learned a lot at school, but I did pick up a few tips that helped me polish up my self-taught coding technique.

During my study of software engineering, my instructors always stressed two things: modular design and documentation. Simple, yet excellent concepts that will save you–and anyone after you–hours and hours of time. I’ve been applying these principles to all of my code ever since I learned about them, but I’ve only recently begun to understand just how important they really are.

I’ve been working with some very unmodularized and undocumented code recently, and I’ve begun to develop an immense dislike for the original author. I’m supposed to add simple little features here and there. By themselves, the features are simple–around 10 to 100 lines each–and would take maybe 10 minutes each to write. To add them to a well-documented, modular coded project might take an hour or two including some testing. But incorporating these tiny features into an existing project base consisting of unmodularized and undocumented code takes 10 to 20 times that. Believe me, I know from experience. I am faced with the constant urge to rewrite the entire code base from scratch. I know it would take longer to rewrite everything, but I have to say it would be much less painful.

Logical code is easy to follow and easy to change. If something is a little strange, then you fall back on the documentation to figure out why. But when the code is an absolute pile of garbage with no documentation, looking like it was written by a first-time coding high schooler, you spend most of your time trying to figure out why the previous author did what they did, how they did it, and why they were ever allowed to touch a computer keyboard in the first place.


The problem increases exponentially when dealing with web projects, especially ones coded in PHP. Modular design in web projects has always been possible but somewhat awkward, considering that up until PHP 5 we had very poor object support. Only in the last few years have there been any decent frameworks to use that employ an MVC structure. My favourite one, of course, is Zend Framework. Before the Zend Framework, I personally had been working on an MVC-like PHP framework of my own to help alleviate the somewhat cumbersome structure that even my PHP projects were sometimes taking. After trying the Zend Framework, I never touched my own framework again.

Having come to realize the power of a good PHP framework and the importance of documentation and modularized code, it just makes me want to cry–and wish horrible things upon the original author whose code is making my job so much more difficult than it should be.


Last spring while searching for a job, I came across a posting for a PHP developer. Cool, PHP! I love PHP, so I typed up a cover letter and attached my resume. I noticed that the ad also invited applicants to include some sample source code that “best shows off your abilities.” I assumed that this was an option and not a requirement, because frankly, sending a random company my source code just seemed illogical to me. To be safe, I did state in my cover letter that I would be happy to show them some code samples upon meeting with them in person.

You forgot the source code!

The next day I received a response to my application:

Hi John,

Thank you for your application. However as per [URL removed] we can only consider applications for an interview that have code samples attached. It is important to us to have a demonstration of an applicant’s coding abilities prior to making a decision on an interview – resumes simply aren’t enough to go on. Please resubmit to hiring@[domain removed] with your resume and one or two sample source files that you feel best demonstrate your abilities.

At first I thought, ok, I will comply, but then I realized how difficult and futile this task would be. For the last few years, all my PHP projects have been done using the Zend Framework. If you know anything about the Zend Framework, or any other framework employing an MVC architecture, you know that your project will have multiple files. Is the prospective employer going to look at them all? Not a chance. But what portion do I send them? A controller? Well, they use several models, which use more models… and what about the views? For the company to get a true impression of my abilities, they would have to receive and understand the entire project.


It’s all about problem solving

Software development is not about source code, it’s about problem solving. This company gave the impression they were looking for some clever PHP algorithm to show how amazing you are. Quite frankly, I think they were looking for the wrong thing. I consider a good PHP developer to be someone who writes easy-to-understand, modular, well-documented code. These skills are not so easily demonstrated in a sample piece of code. It would make more sense to me if the company in question had asked to see a complete project including flowcharts, diagrams and the entire source code. Of course, this brings up another issue. Is such a request even ethical?

What would Google do?

While I don’t mind demonstrating my code to a prospective employer, I certainly am not simply going to hand it over to them. What about non-disclosure agreements? A good portion of my code is written specifically for my clients. I don’t care if it’s Apple or Google requesting my code (mind you, they would know better than to ask), I’m not giving my code to anyone unless they license it from me.

I can only conclude that this prospective employer has absolutely no idea about good software development and lacks any experience in the industry. Otherwise, they would realize how short-sighted and unhelpful so-called “code samples” are.

They could ask questions…?

How should an employer determine a worthy programmer? Grill them in the interview. Have them write a quick PHP script on paper or even give them 10 minutes on a computer. Ask them how to solve a problem using PHP. There are so many ways of determining a programmer’s worth aside from a measly sample of code. Try talking to them! It’s simple enough: If they’ve never heard of MVC or can’t describe object orient programming to you, then you describe to them the way out the door.

Turned ’em down

I replied to the email with pretty much a summary of the above rant. Knowing full well I had just negated any possibility of getting the job (unless this was a test to see if I was stupid enough to send them my code), I asked them to remove my application request for the job. Looking back, I stand by my decision. I can only imagine how horrible it would be to work for a company with such backward thinking. The whole situation reeked of inexperience and poor management. As a side note, I am now employed as a software developer and, prior to hiring me, my current employer did not ask me for samples of my source code–go figure.