Subj : Re: Software Job Market Myths
To   : comp.programming,comp.software-eng
From : CTips
Date : Sat Jul 02 2005 07:44 am

shelley@osel.netkonect.co.uk wrote:
> CTips wrote:
> 
>>shelley@osel.netkonect.co.uk wrote:
>>
>>
>>
>>>How do you evaluate the performance (not just their CV) of a good
>>>programmer? (Real question here - I find this hard to do and have made
>>>mistakes) Is it good design skills, low numbers of defects (almost the
>>>only measure of software quality - which can't be right), lots of code,
>>>great personality... what?  All these are good but don't seem to be the
>>>essence of good programming. Can you trade off good design for lots of
>>>bugs? There are flavours of good but again evaluation is not easy.
>>>
>>
>>
>>1. Look at their experience - see what they've done solo, and what
>>they've contributed to a group project.
>>2. Quiz them about the theory underlying what they've implemented - e.g.
>>if they implemented a wavelet transform, see if they can explain why a
>>particular wavelet family was picked.
>>3. Check their problem solving skills (give them small problems, and see
>>how many hints are needed to get the answer).
>>4. Check their programming skills (see if they can implement simple
>>functions)
>>5. Get them to explain something they are both passionate about and is
>>somewhat relevant to the job.
>>6. Look for breadth and/or cross-disciplinary experience
>>7. Look for a solid mathematical/CS education
> 
> 
> That's a good list of personal attributes to look for when hiring - I
> like 5.)
> 
> When you've worked with them for a year or so what would you use to
> characterize their contribution? What attributes in what they have
> contributed - rather than their personal attributes would you value?

We work in a "one-person, one-project" mode, where a project consists of 
anything from writing some scripts to interface various EDA tools 
through getting an RF card up and running to porting Linux to a new 
platform.

Ideally, in the first year, we'd like a new hire to have finished the 
project which he was hired for (~6months) and at least one other major 
project.

Of course, complete means it works acceptably, where "acceptably" can 
mean tested to oblivion with no outstanding bugs, or just that it works 
well enough for a demo but will break otherwise - depends on the goals 
of the project/program.

> Ideally a balance of all positive attributes of course - but what gives
> the order of magnitude difference - more or better or faster - what is
> this sixth sigma effect? Can it be measured?
> 

I think one common thread is the ability to get the details right. The 
nature of the details involved in writing a pthread library, a GUI, or a 
device driver are different, but to get things done right you have to 
pay attention to them and make sure that they are all dealt with.

After that its a matter of how long it takes to get things done.

Good "programmers" (I'm using the term somewhat loosely here) when 
tackling a problem will put together a structure that allows them to get 
the problem done correctly as quickly as possible.
- If there is knowledge that they need to solve the problem (e.g. where 
does it make sense to use lock-free algorithms/how many taps in the Tx 
Filter for correct waveform), they read/experiment/acquire this knowledge.
- If the scope of the problem is not known, they can separate the 
problem into fixed, probable, and unknown, and generate a solution that 
will allow the program to grow as the unknowns become resolved.
- Where possible, they will write code that generates code (little 
languages)
- They pay attention to making the program correct. This can include 
doing formal proofs, defensive programming, writing test generators, as 
well as the usual testing
- They understand the implicit requirements as well as the explicit ones 
(typically, things like "it should run in 10s or less, most of the 
time", or "we'll eventually have to port it to run under PowerPC, so 
don't screw up the endianness")

In general, you know 'em when you see 'em

.