Four Things To Consider When Hiring A Developer

Things are a lot different today than there were ten years ago. This is especially so in the IT world, and companies need a different type of developer than they used to. So why are they still hiring like it's 2003?

Here are four things that will help you find the right person for the job.

Creativity is not a good thing

For god's sake, can we all stop advertising for programmers who are creative? It used to be that creativity was essential, but that was when the technology was still in its infancy. Today, we have frameworks over top of frameworks. We have APIs. We have jQuery. We have SASS. We have Symfony. We have doctrine. We have open source projects everywhere.

Ten years ago, we needed creative developers because that was our main problem: we need things created.

Not so today. There are few problems left that haven't been solved. That's why a creative developer is the kiss of death. He's more interested in building a novel solution than finding a correct solution. He's less interested in doing the legwork to find an existing solution, understand it, and use it.

A creative developer can lead you down the path of in-house frameworks that do one or two things really well, and do everything else terribly. A creative developer can shackle you to his own creation, and every new hire loses a month trying to learn a new, incomplete, buggy framework that probably has no documentation. And, worst of all, creative developers don't stay in one place very long. When they leave to follow the next Big Shiny Thing, they leave their creation behind, and a team that has to figure out what to do about this monstrosity.

A creative developer is a dangerous developer.

Resourcefulness is the new badge of honour

Don't hire someone who tells you about his ability to design solutions. Hire someone who tells you about his ability to find a solution. For every problem, there is already a solution available online. There are very few widgets that haven't been built. Trust me: every hour spent finding an available widget or module, is three hours spent trying to build it yourself, debug it, and maintain it.

One of the main strengths of a good developer should be his ability to understand the problem, then find a solution for it quickly. Nine times out of ten, the solution is already out there. That's why efficient teams are teams that go to the net.

Google first. Design second.

The more frameworks, the better.

The best developer is one who is comfortable working within an existing set of protocols and procedures. Coders who have spent their time working with an MVC framework are reliable, predictable, and will give you higher quality code.

Their code will be more standardized, which means that it will be easier to test, and easier to maintain. When they leave, if their work is inside an established framework, new hires will be able to understand it better.

When you interview a new developer, make sure they tell you what established frameworks they've used. Make sure they describe how they've used them, which ones they prefer, and which ones they didn't. This question will tell you a lot about whether or not this guy is a team player who works withing established protocols, or a maverick, who would prefer to code it like a cowboy.

Testable code is essential

10 years ago, the main principle of development was GIOTD: Get It Out The Door. There was less QA. There was less automated testing. But today, it should be a different story. There is enough evidence from empirical studies to conclude that code written with unit and functional tests is better than written without.

Developers should have experience with various test frameworks. More important, they should understand why test are written in the first place. They should have an opinion on TDD - Test Driven Development. Whether or not they agree with it, they should be familiar enough with the concept to formulate an opinion.

Defining rules for Red, Yellow, and Green status bars

Continued from: Three things that make successful red-yellow-green status bars

When setting the status of a project metric (tickets closed, lines of code written, % build passing, etc), it's essential that you have a clear and consistent policy. If one metric is green, it should mean the same thing the green means for another metric.

One person's green can't be another person's yellow. The only way to accomplish this is to have a core set of guidelines that determine the status of the metric, and this core set has to be independent of the metric being measured:

Fair Measures of a Metric Status

Color Status	Used whenever one of these is true:
RED	You are not meeting target goals* for two or more consecutive weeks You have had a catastrophic failure of the week and little got accomplished A new issue arose during the week that makes the possibility of reaching the final goal highly unlikely
YELLOW	You are meeting target goals for one consecutive week You are failing to meet target goals for one consecutive week You have discovered new issues that have yet to be assessed, but could put the project at risk>
GREEN	You are meeting target goals for two or more consecutive weeks You have made a significant breakthrough or leap in this week that makes the goal highly likely

* meeting the target goals: you have accomplished the minimum amount of work required each week to complete this project. Note that this amount is continually changing, depending on the amount of time remaining, and the amount of work outstanding

Three things that make a successful Red Yellow Green Status policy

One of the more popular Agile techniques these days is the incorporation of a simple Red, Yellow, Green status for your project. And, by extension, simple statuses for the metrics that track your project.

But the problem with a RYG method is that it quick descends into blind pessimism or blind optimism. If the criteria for setting the status isn't clear, it will trend towards the general mood of the team. A team with high moral will call things green. A team with low morale will call things red.

If the goals for the project aren't clear, it will trend towards the general nature of the team. An optimistic team will have more green status bars. An older, grumpier team will have more red status bars.

A lazy team will have more yellow status bars.

There are three things that are essential for a working RYG Status policy:

Defined and measurable project goals: If you can't even state what makes a project successful, how will you ever know if you are on track? If you can't state what it will take each week to get to a successful project, how will you know if the week was successful?

Transparency: The status chart should be visible to all, and the reasons for each status color should be clearly communicated. Never leave the status color up to a single individual, unless you have clear and objective measures that everyone understands.

Policy: The choice of what makes a metric green needs to be clear and consistent. A green status for one metric should represent the same condition as a green status for another metric.

Continued: Defining rules for red, yellow and green

A template that extends another one cannot have a body. Woe is you

If you are new to twig and symfony, you are probably going to come across this error message in a hurry:

A template that extends another one cannot have a body (Twig_Node_Text(data: '}')) in "ScribeUserBundle:Main:user.template.twig"

When you get this message, you have done one of two things:

1. You have added raw text to a twig file which extends another twig file:

{% extends CoreUserBungle:Main:index.html.twig %}
>!-- html comment here -- WHOOPS THIS CRASHES THINGS. -->
>!-- everything you write MUST be inside a block -->

{% block well_well_this_is_safe_content %}
>div>
    Safe text! No crashes!
>/div>
{% endblock well_well_this_is_safe_content %}

2. You say you didn't add raw text to a twig file, but you did, and you don't know it.

{% extends CoreUserBungle:Main:index.html.twig %}}

{% block html comments %}
>!-- This SHOULD be working but it isn't. -->
>!-- NOW, what's the problem, for chrissakes -->
{% endblock html_comments %}
{% block well_well_this_is_safe_content %}
>div>
    This might work, if it weren't for the extra closing bracket 
    at the end of line 1 ...
>/div>
{% endblock well_well_this_is_safe_content %}

Using int in your doctrine entity will break symfony2

If you define your doctrine yml file using shorthand 'int' instead of 'integer', you will be in for a world of annoyances.

Suppose you create an entity named students, and one of the database fields is age. In the yml, you mave have done this:

YourApp\StudentBundle\Entity\Student:
  repositoryClass: YourApp\StudentBundle\Entity\StudentRepository
  type: entity
  table: students

  ...

    age:
      type: in

  ...

  lifecycleCallbacks: {  }

Without complaint, doctrine will generate your entities for you, but they will contain the following declaration:

/**
 * @var int
 **/
function setAge(\int $age)

This is going to throw an error, when PHP comes across it and has no idea what the 'int' class is.

Always use 'integer'.

An example of how to set up SSL on your virtual machine

If you are developing in a VM, you will usually want to duplicate secure sites, too, especially if you are doing maintenance on existing websites. Setting up SSL on your VM In order to access your development site under https, you will need to install a self-signed ssl certificate on your virtual machine. It's a straightforward process.

Set up your certificates in your apache2 directory

Set up a directory to hold your certificate, and then generate your pem file.

$ sudo mkdir /etc/apache2/ssl 
$ sudo /usr/sbin/make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /etc/apache2/ssl/your_site_name.pem 

Create a conf file for your ssl

$ sudo touch /etc/apache2/sites-available/your_site_name-ssl.conf

Edit your conf file

Add the following to your_site_name-ssl.conf:

 
  DocumentRoot /var/www/path_to_site_document_root
  ServerName your_site_name
  ServerAlias your_site_alias
  
  SSLEngine On
  SSLCertificateFile /etc/apache2/ssl/your_site_name.pem 
 

Verify that you have ssl set up

*a2enmod* enables/disables apache ssl
*a2ensite* makes sure that there is a symbolic link in /etc/apache2/sites-enabled to the specified conf file

$ sudo a2enmod ssl 
$ sudo a2ensite your_site_name-ssl.conf 

Restart apache

Check the configuration of your apache file, and see if you have added any errors to your conf file. Apache will not restart if you have errors in your file.

$ sudo apachectl configtest 
$ sudo apachectl restart