[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Functional Paradigm popularity and Maths (Was: XML as a transition to s-expr)
"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
> 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
> 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.