One of the biggest issues with modern development is how to practically test programmers. The heart of the problem is that for many years, one could segregate the good or experienced programmers from the inexperienced or bad programmers by their knowledge of the deep syntax of the language.
The problem with this method of testing is that now the answer to a question about a command or function is available at the drop of a Google search. Without this divider, suddenly all developers are at the same level. Worse even, developers who are less good, but have studied up are able to make themselves look better initially than their better comrades by cramming harder before the technical screening. Employers and clients are now stuck in an untenable conundrum. If they hire the person who can best answer their technical questions, they still can not be assured that they are the best person to do the job.
Here is where logic testing comes in. Not boolean logic, but flow logic. If you make a potential developer lay out how they would structure their functions, CFCs, Classes, or Methods then you will be able to see instantly if they are an experienced developer or not. The experienced developer will think out their application in a manner that separates the data, display, and logic and allows for maximum modularity and reusability of components. The language doesn't matter. A semi-decent developer with a good understanding of logical flow can pick up the syntax of most any language in 3 – 6 months. Which is a long but acceptable ramp up for someone who you can be assured will do the job right.
What if you don't want to wait 3 – 6 months. Then I would recommend combining the syntax test and the logic test and weighing carefully the results of each. If the candidate can answer all your syntax questions, but can't layout a simple application, then they probably will not ramp up quickly enough to perform to your needs. Likewise, if they excel on the logic portion of the test, but have difficulty with the syntax, they will have the same difficulty in ramping up acceptably.
In a web development environment, I have found that learning Java has helped me tremendously in tackling the difficult concepts of inheritance and even modularity. I was average at ActionScript until I learned it since much of ActionScript is based on Java. I would now consider myself good at it. The same goes for ColdFusion. I thought I really understood it, but after learning Java I realized how little I truly knew about it. Many programmers will scoff at learning the languages from which the others are derived, however it really does help. I had to learn basic C before I could even begin to understand Java, and even then it was a struggle to get my head around its strongly typed nature (declaring variables, and initializing objects before using them), and especially the nature of public and private objects. I had many long nights tearing my hair out over the only one public method-per-class rule, which makes sense, but in all the documentation I had read, I had never seen that rule explicitly stated. All programming languages have their do-or-die moments of explosive frustration, and all programmers know that we have to push through that to get to the real payoff, but that frustration is magnified by a factor of 10 when we don't really understand why something works the way it does. All-in-all learning C and Java is definately worth your time.
All of this leads us to more questions than answers about how to pick a good programmer. Employers should remember that probably the most un-natural thing for a human being to do is to program. Developers take nothing and turn it into nothing that looks like something different. All software is just thought perpetuated, so what you are really interested in is how the individual thinks, and there are many ways to test that. What we are left with is that businesses and clients should be hiring individuals not skill sets. What I mean by that is that they should select a particular programmer because they think in logical patterns and have a strong work ethic where planning is concerned. The measure twice and cut once allusion works well for development. It is much better to find a problem in the planning stage than it is to find it after customers or other employees are using the application daily.
If the development cycle is too short, programmers are set up to fail. There is no way that a group can develop good robust software with a micro-development cycle. True, there are people out there who could take 20 years to develop, and still turn in an unusable application. However, the majority of good developers given a well planned and stable development cycle will deliver good code, which will make for a good maintainable application. The problem comes when developers have to rush. The part of the cycle that is always cut is the planning portion. Wireframes aren't adequately tested, flowcharts are never completed, and the developers have to rush in and just start building uncharted methods, this quickly leads to spaghetti code and extraneous methods that lead no where. Dead code stripping IDEs are cool, but unnecessary if developers are able to create quality flowcharts and wireframes. Should the development cycle be indefinate? No, but the PMs and clients should talk to the developers and make sure they have a complete understanding of the specs before delivering the final draft with timetable to the client. The developers will know how long it will take them to plan and whiteboard the entire application, then the actual construction will just be follow through. If this process is adhered to, you will have happier developers, because they won't have to work insane hours to remain on target. Happier PMs, because they won't have to constantly reassure the client when the project goes over time. And ultimately happier clients because they will have strong robust applications that will deliver in the short term and remain upgradable in the future.
Then what of team dynamics? It is obviously best if you have a team of developers who respect each other's ideas, and it is superlative if you have a team that likes each other as people. It is crucial to have a good team dynamic. A developer's best resource is another developer. One of my favorite things about being a developer is the sense of comradery that comes with being a part of this incredible group of people that spans all races, geographical locations, and political affiliations. Well, maybe that is too grandiouse. Most developers share the common thread of being way too into technology and a overwhelming desire to show someone who can understand why using bit shifts instead of old math to speed up Java operations is cool.
So, evaluate logic, personality, and some syntax when hiring developers and you won't have a problem with your development teams. Set proper expectations with the client, and you won't have problems with your development cycle. Build enough time into the development cycle and you won't have problems with buggy spaghetti code and applications that need constant repair. Do all of these and you will have a bubbly productive environment in which everyone is happy. Fail to do the above, and you will have a lot less hair. The choice is yours.