[clug] Programmer Competency Matrix

[Paul Wayper]

On 07/08/09 16:50, David Tulloh wrote:
> On Friday 07 August 2009 16:11:24 Alex Satrapa wrote:
>
>> > On 07/08/2009, at 15:34 , steve jenkin wrote:
>>> > > What do people think of this approach?
> I think it's useful but clearly has to be adapted for each company. I'm
> currently writing my CV and it's given me some interesting pointers.
>
> Going through Alex's initial email I disagreed with most of his
> objections but rather than arguing the points, what I felt was that the
> level three column represented the more passionate and curious
> developer, the kind of developer that explores different languages and
> tools to gain a wide range of knowledge and skills. Clearly these aren't
> all going to be relevant at any given time but I feel that that
> developer is better overall and is clearly the kind of person this
> company is looking for.

I tend to agree here.  I read about a study of geniuses that found that the 
crucial thing that they all shared was interest in a huge variety of 
techniques and ideas.  When they needed to solve something they would just 
know that differential analysis, or the Bresenham Line Algorithm, or 
Burrows-Wheeler Transform, would help there - and they would then just be able 
to write it out or use the correct module or whatever.

What I've learnt from doing Red Hat exams, and from working as a sysadmin, is 
that in order to pass the exam you need to be able to just be able to 
instantly know what goes into a resolv.conf file or a named.conf file or a 
sendmail.cf file or whatever.  You need to be able to look at one and 
instantly have the problem stand out to you.  This comes not from diligently 
doing the same thing over and over again but by constantly learning new ways 
of doing things, trying different configurations, and implementing new systems 
or old systems in new ways.  Then when you find you have to implement (e.g.) a 
Google Wave Federation server, you've done most of the steps beforehand and 
it's just a matter of putting it all together.

The other factor here is the classic powers of ten observation: one hour of 
planning equals ten hours of coding equals a hundred hours of debugging equals 
a thousand hours of maintenance.  The next stage down is someone who can tell 
you in six minutes what would take an hour of planning, because they've 
accumulated that knowledge elsewhere.  And hiring a programmer for $100,000 
that can write code as well as four costing you $50,000 each is a big win (as 
Joel Spolsky observes).

I think of this more as an 'average score' thing: if you're more in the O(n) 
space then you're an improvement on the O(n^2) space, and still need to look 
at things in the O(log n) space...  It's not an absolute 'if you do this then 
you're stupid' judgement.

Have fun,

Paul