Darrell has posted his opinion on how to address some of the problems in the software industry today and if there is one thing I truly enjoy, it's being able to give my opinion! I think that Darrell has nailed part of the problem, that salaries and value in general do not match up well for developers anywhere.
To find a complete solution though we must understand why this is. Surely there is "deadwood" as Darrell calls it in most organizations. Obviously if the goal is to match value to salary the first thing that needs to be done is that we must find a good way to identify the dead wood and trim the branches. How does one identify a poor developer on the job?
Makes no attempts for self improvement
When I walk into a developers area, the first thing I tend to look at is their bookshelf. The variety and quality of books the developer owns can tell you a lot about what coding techniques they prefer, and in general show that they are at least trying to follow industry standards and keep their skillset up to date. Now obviously not all developers keep a library at work, so how else can we identify developers that actively seek improvement?
- Does the developer blog?
- Are they a member of any local user groups?
- Do they take classes or seek certifications?
- If there is an education budget at your company, do they use it?
I am a big fan of companies providing education benefits. Companies should be aware that the better the education and training their staff has the more valuable they are as employees.
Code is difficult to maintain
This is something that takes time to measure. When I am managing an IT project I like to be certain that multiple team members touch portions of an application. Sure, some developers touch certain areas more than others to become specialists, but I feel it is important that a variety of developers get exposed to an area of the code. Over time, as many developers review and have to make changes to areas of the code you get a feel for whose code requires the most work to maintain. At this point you must evaluate why the code is difficult and time consuming to maintain. It will fall into one of the following categories:
- Poor specification- Here's a warning flag for poor planning and communication between the users/management and the developer/architect.
- Complex Design- Sometimes an area of the code is just required to do some really complicated things and it's no one's fault.
- Bad code- The rest of the time it's the fault of the developer. Are they not following coding standards? Do they have a fundamental misunderstanding of how to write clean code? Are they a junior developer who is performing tasks for the first time? All of these things can be fixed with time and mentoring, but if the developer is one of the above who doesn't seek self improvement then it is probably more difficult and time consuming than it is worthwhile.
Poor personalities
I know we have all experienced working with an IT professional who has a decent skillset, but is abrasive and arrogant. In a pure software shop a developer can somewhat get away with this if they are highly skilled. However (and I speak from a load of experience here) the business world has increasingly broken down the communication barrier between IT and the other departments in the company. Many new design processes go so far as to say that end users should be members of the project team. Regardless of whether you think this is a fad or something that will stick around, the bottom line is over the years of my experience I have become more directly involved with end users, not less. If a developer has an abrassive personality they can do severe damage to the relationship between IT and other departments. This sort of destructive activity can not be tolerated!
Now that I've given you tips for identifying deadwood let's talk about the real work that needs to be done: preventing deadwood from getting into the organization in the first place. Have held a mix of contract and perm positions over my career, I have gone through quite a few interviews. For the most part, they suck. That's right, they suck. They are poorly planned, in general the questions I've been asked are either too general or way too specific, and I can count the number of times I've been asked to provide code samples on one hand.
Interviewing a Developer
Here are some general tips for improving your hiring process. One of the common complaints I get when I talk to people about improving their hiring process is that it "takes time". Well, as studies have shown, hiring the wrong people is far more expensive than letting your IT staff conduct proper interviews. The interview will differ by the level of experience of the candidate, so here's some tips.
Junior Developer
This is a new graduate, or a developer with less than 2 years of experience. Being that they don't have a lot of project experience, you're probably not going to be able to get much in the way of code samples out of them. For junior developers I like to provide a workstation with visual studio .net, MSDN library, and a copy of the pubs database. I task them with pulling a sortable list from one of the tables. They can use any .NET language they want, forms or asp .net. They have all the help files in MSDN and 45 minutes to figure it out if they don't already know how to do it. This checks two things:
- If they already know how to do it then I can check their coding style and see which method they used so I can ask followup questions in the face to face interview later.
- If they don't know how to do it then I can make sure that they can actually read help files and implement solutions.
#2 is very very important. One of the biggest differences between a poor developer and a great one is that the great one knows how to research solutions. A poor developer will spin their wheels, ask someone else, whine a lot, and generally be unproductive until someone comes and holds their hand. As a mentor/team lead I absolutely hate it when a developer comes to me with a problem and they haven't even attempted to find the solution on their own. You'll get far better results with me if you say "I'm trying to do X, I did some research and tried A, B, and C but none of them work. Can you help me?". As an organization you want to staff filled with people who are proactive about problem solving.
Mid-Level Developer
Mid-Level developers have between 2 and 5 years of experience and have done a lot more coding than the juniors. For mid level developers I like to request a code sample (or in the case of an ASP .NET developer) I like to get urls of sites they have worked on if possible. Some folks are bound by NDA agreements and can't provide this, but frankly if you are a mid level developer and you don't have any "play" code laying around somewhere then immediately you strike me as a person who doesn't seek self improvement! (see how that ties back nicely above?) I'm not looking for the most elegant example on the planet, you're Mid-Level which means you still have some growing to do. What I do expect is to be able to see an example of your work, and brief explanations of how and why the work went about the way it did. I want to see someone who understands what they have done and tell me why they would or would not do it the same way if asked to code it again.
Basically, I just want to see if the mid-level developer is thinking or just doing. If they are just doing, then you are basically paying a mid level salary for a junior skill level.
Senior Developer
The senior developer should be able to talk about their experiences in leading others. Code samples are also helpful, but I feel they are less of a requirement for senior developers than they are for mid level developers but in the end it depends on how much actual coding your senior guys do in your organization. In a perfect world the senior would spend a significant (30-50%) amount of time mentoring lower level developers, reviewing code, and helping determine the overall vision for the software. I want to see that the senior developer is read up on recent trends in IT, not a person who is happy being stuck in older technologies and looking to retire somewhere in maintenance mode. Basically I want to see if there is still passion about coding and technology there, oftentimes I find senior people to be burned out and rooted in their ways. This is a potential harmful role model if they give this impression.