@Alex Papadimoulis said:
Technical competence is easy to
measure; take a test, write a program, etc. But a programmer's
competency level is not just how well he knows Perl or the System.Web
namespace; it's only about 30% of the overall employee. There are far
more "soft skills" essential to life as a programmer, such as
communication, leadership, responsibility, reliability, etc. All of
these are measurable (Google "employee performance evaluation" for a
myriad of ways to do this) and, on a whole, the measurements are
accurate.
Yes and no - I think you are totally correct about competence being
far, far more than whether they have an API memorized, but I'm not
convinced that competence is fully measurable except by results.
I work in a consulting environment so I've worked with a wide variety
of developers. The ones I call most competent are the problem
solvers, or the "thinkers". They think about what the
requirements are, what makes sense and what doesn't, both from a
technical perspective as well as from a business perspective.
They will push back to the business user coming up with the
requirements if what they ask for seems contradictory to other
requirements. When they have an idea for how something could be
done better than specifically asked for, they present the idea back to
the business users, tech leads and PM as applicable in a way that shows
the advantages and is usually acceptable. When they are given a
requirement they don't know how to meet right away, they do some
research, tinker, and find a solution using the best practices they
can. They use basic programming and style standards so that what
they write is easily traceable by the next person to look at the code.
The ones I call less competent are the sheep and the rogues. They
will do exactly what the piece of paper says, no more, no less, whether
it makes sense or not. They will not take the initiative to point
out errors or inconsistencies in their instructions, they'll just
implement them anyway. Or alternatively, they'll get it in their
head that they know better than the business analyst and the architect
and go rogue, developing something totally off-base without discussing
it with their tech lead and the rest of the team. They don't
research the best ways of solving a particular problem, they reinvent
the wheel and introduce all sorts of kludges to force a
"solution". They don't look at the overall architecture or style
of an application nor do they use consistent styles themselves.
They favor copy-paste over writing re-usable code. And sadly,
even when instructed most of them don't really "get" it.
IMO, you can take two people with the exact same level of "technical"
knowledge in terms of a particular programming language and/or OOAD
principles, but the competent developer will always produce a better
functioning and more maintainable result than the sheep or the rogues.
@Alex Papadimoulis said:
You are exactly correct -- you put the strongest people doing the most complicated work (architecture, design, leadership, etc) and divy the less complex work *with very specific instructions* to the weaker people. This is the whole idea behind a detailed design document -- it's very specific instruction with trackable requirement numbers. The guy in the 40th percentile is never going to be able to walk away from the "daily scrum" and understand or be able to work from the notes he took. But give him specific coding guidelines, specific requirement numbers to implement, and he'll do it in a predictable amount of time. The same goes for testing and the rest of the lifecycle.
This I totally agree with. It still takes a bit of micromanagement unfortunately to ensure that the 40th percentiile guy actually comprehends his instructions well enough to produce what is on paper (I worked with one guy recently who left fields from the requirements & design docs off of a form on his web page and put new ones in without consulting either the tech lead (me) or the business user because 'he thought it was wrong' - and then acted surprised when the business analyst had a fit during testing that his pages bore little resemblance to the reqs or the wireframes), but if you have the "thinkers" mapping out the application and writing the documentation, then hopefully the application will have an underlying extensible architecture that is more easily maintained, even if some individual components aren't built with best practices.
In an ideal world, we'd all work with competent developers. Sadly, that is not always possible, and so a team lead needs to choose a methodology that will be most effective for the people he or she leads. I'm no expert on XP or Agile methodology, but my own preference would be to start with a detailed reqs doc and at the very least a solid architectural document that details the framework of the application, if there is not time to design each specific functionality. Sure, the requirements will change and the design doc can be modified over time, but personally there are very few sheep I would trust to be able to maintain a coherent design when they only get the requirements piecemeal. I've found that I have to assign anything that impacts the overall architecture of the application to my competent developers and assign "plug in" type functionality to the sheep. What usually ends up happening is the competent developers finish their functionality early and start taking responsibility back from the sheep, at which point they have to rewrite a lot of it to mesh with the architectural standards of the application.
As far as XP goes, personally it doesn't work for me because I cannot code and talk at the same time. The way I'm wired, XP feels traumatic and foreign because I need to finish my thoughts, get the code on screen, and then I can stop and discuss it with someone. I just flat out can't have the conversation while I'm working. And being the partner not in control of the keyboard bores me to tears. I would much rather have frequent team code reviews than try to actually code two to a keyboard. But, other people's mileage may vary. It isn't necessarily a bad thing if a team can work effectively that way. I know for sure I can't though.