[colug-432] Computer Programmer Productivity Ratio

[Ethan Dicks]

On Mon, Jul 21, 2014 at 12:26 PM, Scott Merrill <skippy at skippy.net> wrote:
> I agree that there is a necessary modicum of skill to be considered
> "competent", but "obvious things" is a moving target based on situation.

I would never presume to assert that it's a fixed target.  Quite the
opposite.  We used to obsess about cylinder boundaries and latency
optimization.  None of those skills are remotely useful now, nor have
they been in a couple of decades.

> I rarely use anything other than the arrow keys to navigate my history
> because I rarely have any situation arise in which the arrow keys are
> insufficient.

So 'history|grep foo' is rare for you?  I wouldn't want to arrow
through hundreds of entries to find something I did last week...

>  If someone can be productive and successful with a
> limited subset of the tools you find indispensable, it does not
> necessarily make them inferior or subpar.

I suppose that depends on your threshold for productive.  You can
drive from NY to LA in first gear... you will get there, but the guy
who knows there's other gears will get there days before you.  In the
end, the same payload is delivered, but how long did it take?

>> One of my standard interview question threads explores how much
>> the candidate knows about signals and processes...

> A lot of this kind of thing gets into self-congratulatory navel
> gazing. While I know that `kill` sends signals to processes, I can't
> tell you offhand what the individual numeric signals equate to.

And a) that answer is entirely fine in this context, and b) an answer
of that exact quality and content is beyond more than 50% of the
people I've asked it of.

>  It
> doesn't matter within the context of my job: knowing the numeric value
> isn't necessary to know how to send the signal I want to send.

Agreed.  99% of the time, you are sending either 'kill -9' or 'kill
'-1' and don't need to know about any others.  I'm not talking about
subjecting a candidate to a trivia contest about memorizing signal
numbers.  That _is_ pointless (I don't care if you know the four
letters that aren't valid switches to 'ls', but I've been asked that.
'man' or The Google can tell you the answer to trivia).  I'm talking
about not knowing what signals are or _why_ you'd want to send one to
a process (and even knowing that different applications respond
differently to a SIGHUP - that what an application does is entirely up
to how it was coded).

I consider knowing how to manage processes a rather fundamental skill
in a UNIXy environment.  It's a difference between being a System
Administrator and a System Operator.  If you don't know how the system
works, it's a lot harder to understand and correct problems when they
arise.

> The Linux world is different now than it was a decade ago.  It's
> possible to be professionally successful without the kind of hard-won
> deep expertise many of us acquired through years of tinkering and playing.

When the waters are calm, sure.  When something goes wrong, that's
when knowing the layout of the engine room pays off.

-ethan