The thing is that someone that is fluent in one computer language can pick up another. Where the difficulty comes in is with nuances (arguable points), add-ons (the whole bit of frameworks, etc., tuned for the language), with libraries (say, specific implementation of functions, lots to discuss there), and more.
In brief, the 80-20 (or any other ratio) rule comes into play. In regard to the "cloud" and things of this nature, are we not under siege by those who want to create havoc? Ah, the decisions that were made are haunting us.
-------- Question ---------
Who has applied "know one, know them all?"
-
Of late, we see all sorts of emphasis on specifics in job requests, many of these related to details. Now, some of that is HR trying to make it easy on themselves. Some of it is just glorifying code and the wizards, thereof.
My motto, from decades of experience: Know one, know them all.
Let me tell you a story. I took an old engineer, gave him a little tutorial, and he did this (believe it or not): converted a lisp-based system (okay, a small portion of it, but non-trivial) to Pascal. Now, here's the key: he did it essentially by writing the new code without an IDE (that is for folks who are hung up on their tool - which, think of it, is a link to the ring on your nose pulled by the vendor) by hand. I typed it in, and things worked.
I can hear the whole chorus going off on me. Let me rephrase. The complexity in systems is what is represented in code, not the code itself. And, some things (domains) get complicated real quickly. However, we have had fifty some-odd years to try to make it better. Anyone even care?
Well-specified frameworks (et al, as this implies a whole lot of stuff) and other practices hide complexity. Wait! Every generation (and I've seen plenty, folks) has to re-write from the get-go. Therein, we see some of the problem.
If the focus was on specification (let's say, executable), then one could map to the delivery system. And, done right, the approach could be as exciting to use as getting into advanced games. In fact, rather than chasing about in a fictional situation, going nowhere, the whole of the space(s) could represent aspects of problems, etc.
That type of thing would work for the IDE experience, to boot.
Before I leave, sure, getting people to understand OO (and other advanced notions) can take time. But, again, we took engineers and taught them this; they then did their own coding and, as needed, used help from people who could debug, etc.
Motto: It is more effective, at times (when?), to teach a domain person to code in order to solve their problems, then it is to try to teach a coder (yes, guys/gals) the intricacies of a domain.
Ah, next up, would be discussing domain-oriented tools.
- John M. Switlik, Timeless autodidact
There are several problems that come to fore in the described approach.
For one, the IT/CS types might start to feel like servants; yes, the brain work is being done by the domain expert (some used to use, subject matter expert). In this case, let IT/CS dabble in the domain (there is no worse hell than a lifetime working with things from that below-the-floor view).
Too, those who are the experts might get bogged down by the drudgery of the coding/testing/etc. Put effort into building domain assists (actually, that would be one thing that could give the IT/CS people their jollies).
So, meet in the middle which is how real-world problems are solved by effective teams. Say what? Yes, for one example, think top-down meeting bottom-up. But, the axis does not have to be oriented that way.
I used TD to BU (think of the middle as a floor with an upper and lower bifurcation - all of this movable, as a feast) as I can tell all sorts of tales in this regard (as could anyone working on advanced systems (inclusive use) that solve/resolve things that other than what we see being offered to the public). One solution is having teams that cover the perspectives through the various talents actually working together (as opposed to what? all sorts of examples, but let's say, in this context, people stupidly glaring at a screen in order to see (what?) code - all day, no wonder there is such an interest in zombies) and resolving conflict, etc. BTW, agile does not cut it in this regard unless there is a step away from the code as the focus in order to allow some type of persistence of the specs (tests as specs, in the aggregate - don't think so, incomplete, for one thing - in regard to knowledge which is the realm of the human expert - notwithstanding the hoopla about big-daddy data).
You see, for some reason, the computer has taken precedence. When the heck did that happen, folks? I'll tell you. When what became the cloud (ah, to me, insidious stuff) took people's touchiness away. When you deal with the whole of it (which truth engineering says is necessary), then you have better intuitive grasps (the cloud, people, takes away your control - ah, managers/bosses/money people - did you do this little shenanigan on purpose? well, that would require better insight than is actually there).
To teams, the key thing is trying to get some balance in a multi-dimensional space, of which some of the factors relate to convergence (not to be thought of as a simple fixed-point issue - for now, think metaphorically) toward something that is unknown (and hard to know). Enough on that, as it can be expanded elsewhere.
Remarks: Modified: 10/17/2015
08/11/2015 -- This was originally posted on 8/07; there are rules for questions that I'll post, if they are public. This one could be broken into parts. But, we have the total thing here, for whatever review might be done.
10/17/2015 -- This was the end of the honeymoon (to be explained). A later occurrence of the same thing: Quasi- empiricism.
No comments:
Post a Comment