I would agree in spirit with your comments. We do have in this
forum programmers who would do well as statisticians and
statisticians who would do well as programmers. As you indicate,
though, there are probably degrees of proficiency that we
have across the various disciplines. This renders collaboration
across disciplines beneficial if not necessary. Statisticians
and programmers need not stake out domains and engage in turf
wars. As we collaborate, the inquisitive mind will pick up tools
that are employed in the other's domain that they might employ
on their own at another time. Still, it is healthy to keep
before us some recognition that there may still be much to
learn from each other.
Toward that end in a thread that seemed rather amorphous and
conjectural in nature (was there ever a clearly stated problem
which needed some resolution?), I thought it necessary to butt
in with the statisticians point of view when there was some hand
waving about condensing data into a single record per subject.
The history of the thread did appear to be essentially
directed toward efficiency from a programmers perspective,
and then some statements cropped up which went straight to
possibly erroneous statistical analysis. At that point, I felt
it necessary to weigh in. Given that such an eminent member
of the list as Paul had assented to what was an egregious
overstatement, I knew that I could assail him without any loss
of his friendship. Heck, with only a little time reviewing
the relevant concepts of correlated data analysis with Paul,
I would have no trouble turning over to him some difficult
analyses. He would, I am certain, perform an appropriate
analysis and find ways to do so efficiently.
--- Jack Hamilton <JackHamilton@FIRSTHEALTH.COM> wrote:
> There seems to be a distinction in this thread between "programmer"
> "analyst", a distinction which we don't really have here.
> For the most part, "analysts" here are expected to take
> for their own data manipulation (with help from more experienced
> programming colleagues as needed), and "programmers" are expected to
> understand the meaning of their programs (with help from
> knowledgeable colleagues as needed) and how those programs help
> accomplish departmental and company goals.
> For example, if one of my programs needs statistics beyond the simple
> descriptive statistics that I understand I'll get someone else to
> me write the proc reg or whatever, but in the process I'll learn
> about proc reg to understand the basics of what it's doing, even if I
> can't (and shouldn't) write the proc reg code myself next time. And
> statisticians might come to me for help on the data step or SQL, but
> afterwards they'll have an idea of how the data step or sql code
> even if they wouldn't write it themselves.
> The alternative method presented in recent postings, where there are
> programmers on one side of the room and analysts on the other side,
> strikes me as both less fullfilling and more likely to produce
> How well does it work in practice?
> Manager, Technical Development
> Metrics Department, First Health
> West Sacramento, California USA
Fred Hutchinson Cancer Research Center
Ph: (206) 667-2926
Fax: (206) 667-5977
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software