> > Personally, I still think that chosing a language is a secondary task.
> Being
> > able to formulate a thought process, pinning it down to a computable
> > algorithm, that is the main thing.
>
> No, the MAIN thing is to be able to understand real work processes (the
> workplace logic) on the health system coal-face - including how to insert
> revised processes (using e.g. new computerised tools/systems) in the same
> real-life situation.
>
> THEN to analyse those work processes and devise "computable" structures
and
> algorithms.
Sorry, I am biased. You are very right.
I always developed software for my own domain, so understanding the work
process was inherent in my all of work. You are right when concerning
contract work / "external" IT staff. However, in the past 2 decades I made
the experience that "pure" IT staff does simply not deliver. The reason is
that they never get to understand the real work process, being outsiders.
You can get away with being a mediocre software engineer / software
developer and still deliver "good" software that does the job if you know
exactly what it is supposed to do. But the most superb software engineer
will fail miserably in a domain foreign to him, because the people within
the domain can't be bothered to spend months and months to explain what it
is all about.
For this very reason we have only very few "pure" IT people on board. I
prefer them with dual degrees or at least a few years expertise in both
domains.
Horst
