Re: Functional Paradigm popularity and Maths (Was: XML as a transition to s-expr)

[address@hidden]

"David Simmons" <David.Simmons@smallscript.net> writes:

> Personally, if we're prioritizing valuable skills for a desirable
> generic industry "hire":

> a) How to *never* break a team build.  And that goes hand-in-hand
>    with understanding what it means to be on a team; and
>    understanding what commercial quality software production really
>    means.

> b) Bug reporting, tracking, and escalation management [based on
>    managed processes and business constraints/priorities]. 

> c) Quality Assurance Processes - not the least of which is beginning
>    with consistent "team" practices for style and naming
>    conventions.
> 
> d) Feature set management.  Ability to compromise under a schedule.
>    Ability to create "safe" workaround solutions when a bug/design
>    problem cannot be resolved within scheduled time/budget.
> 
> e) Understanding of what "ship-date" means, and the phases of
>    mastering software and lockdowns to get there.
> 
> f) Experience with foreign (human) languages and cultural issues.
>    Understanding of necessary design infrastructure for
>    globalization and localization.
> 
> g) Experience with multiple language paradigms.  Experience with
>    multiple platforms (operating systems, windowing/graphic
>    systems).  Ability to design for cross/multi-platform
>    architectures and deployment.
> 
> h) Experience with design [and implementation] of:  real-time
>    software, embedded software (devices), shrink-wrap applications,
>    device-drivers, re-usable documented libraries, server systems,
>    mainframe architectures and environments, etc. 
> 
> i) Experience and understanding of modularization and versioning
>    issues in the "real-world".  I.e., ability to design and/or create
>    architectures for patching and updating software elements in view
>    of legacy software, backward compatibility, or unanticipated
>    configurations of related elements and deployment environments.
> 
> j) Ability to read and critique code in a "constructive" manner to
>    improve the level of the entire teams efforts.  Understanding and
>    patience for working with and getting the most out of "star"
>    players and skill in integrating them into a team (or in being
>    one on a team).

You don't demand much.

At Content Integrity we had a difficult time finding people that had
the courtesy to *show up* at an interview. 

> So, yeah, formal-linguistic training in recursion and thinking in terms
> of s-expressions; for me, that pales in comparison.  The point being that
> software is (or should be) "engineered" [as opposed to being researched,
> theorized, and proven]. 
>
> And, I'll say it again, real understanding of recursion and the ability
> to think in terms of lists (or more properly a solid grasp on discrete
> mathematics) is not essential.  While such skill/ability is highly
> desirable, it is also not a realistically available skill in the average
> worker within the software field and it does not get the same rewards as
> other skills such as those I mentioned (nice run-on sentence, ehh).

The skills you mention are valuable and rare.  I'd be surprised if
someone had mastered them but had not in the process picked up a few
`pointers' on how to use a linked list.

In general, I expect applicants to have *none* of the skills listed
above, and I expect to have to train them.  I'm not looking for an
understanding of recursion to the depth I'd expect a PhD candidate to
have, I'm looking for an understanding of recursion such that a
recursive program doesn't blow their mind.

~jrm