[clug] Programmer Competency Matrix
paulway at mabula.net
Sat Aug 8 00:47:15 MDT 2009
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.
More information about the linux