[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)
> -----Original Message-----
> From: email@example.com
> On Behalf Of firstname.lastname@example.org
> Sent: Friday, December 21, 2001 1:16 PM
> To: Guy Steele - Sun Microsystems Labs
> Cc: David.Simmons@smallscript.net; email@example.com
> Subject: Re: Functional Paradigm popularity and Maths (Was: XML as a
> transition to s-expr)
> Guy Steele - Sun Microsystems Labs <gls@labean.East.Sun.COM> writes:
> > > So why should I "always" need to hire a person with a
> > > foundation in computer science for working on a given software
> > > problem.
> > Because you would not hire a nurse whose only experience with
> > is anecdotal. Because you would not hire a cook that did not
> > understand that incorrectly prepared food can be fatal.
> > Thanks for an excellent parable. Let's explore it further.
> > Rather than hiring an expert chef who has been trained and
> > certified in the art of removing the poisonous parts from
> > a blowfish (fugu), leaving only enough toxin in the flesh
> > that I (probably) won't die from it, I think I'd rather hire
> > the guy who's just a basic short-order cook who doesn't try
> > to get fancy.
> > If I *had* to eat fugu for some exotic reason, I'd want the expert.
> > But for everyday breakfasts, I'm willing to settle for an omelet,
> > hash browns, and OJ. Getting the eggs to be fully cooked isn't
> > that hard, and (more to the point) I can easily tell when it hasn't
> > been done right.
> Ok, I guess the question comes down to whether `understanding lists
> and recursion' is more along the lines of removing poison from fugu or
> making hash and eggs over easy. Perhaps I'm a computer snob, but I
> put sausage links and linked lists in the same category.
> I don't expect a new hire to understand lattices and retracts, but he
> better understand a linked list.
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
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).
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 foundational building blocks for software are another issue entirely
(they are where "art & science" take center stage).
For a "hiring" (based on my hiring of employees to create, maintain,
support, and deliver software), it is the ability to "deliver" a valid
solution that meets/achieves business/organizational requirements and
objectives that matters. For a "researcher" or "architect", I would have
different skill requirements which would include both the aforementioned
set *and* formal (or solid self-taught) computer-science and software
engineering design skills.
Making the "best" software is a personal, artistic motivation that may,
or may not, be relevant for a given project. I use the phrase "best",
because it is, in fact, a very subjective term which is often
conditioned based on preconceived ideas and the
experiential/preferential basis of those forming such an opinion of
-- Dave S. [SmallScript LLC]
SmallScript for the AOS & .NET Platforms
David.Simmons@SmallScript.com | http://www.smallscript.org