On Thu, 16 Jul 2020 20:56:59 -0400, xxxxxx@gmail.com wrote:

>Counterpoint: If an architect was thrown at building a nuclear plant (when
>his day job was normal commercial real estate) or asked to build biomedical
>systems or develop a system to generate reasonable yet playable universes
>for RPGs, he'd kinda struggle. Yet, because a 'software developer/engineer'
>is allegedly discipline of sub-specialization, we get asked to do all
>manner of things on the assumption 'well, it's all just software,
>right....?'.

[propitiations to the deitic principles governing bandwidth]

Don't think for a moment that I disagree; your points are entirely valid.
But we in the industry do have to accept some of the blame; too many of us
encourage that "he's a programmer, he can write a program for anything"
mentality, and those of us who don't encourage it, and who do distinguish
between code-monkeying and systems analysis and design too often acquiesce
to the PHBs that love the idea of "IT guys" being perfect generalists.

We're _starting_ to see the _beginnings_ of specialization, but mostly in
the non-programming (i.e., non-coding) disciplines - we have SysAds, DBAs,
Information Security specialists, network engineers, et cetera - but the
same guy who just got a handle on managing an office-wide LAN is often
expected to be able to handle an enterprise-wide WAN including VPNs,
firewalls, DMZs, et multae ceterae, and the DBA is assumed to know how to
manage any of three or twelve different SQL servers, plus the DB2 on the
legacy mainframe, plus all those little dBase/FoxPro apps that are sharing
datafiles on a file server, plus MS-Access ditto.

And on the codemonkeying side of things, we no longer have programmers and
programmer/analysts (and systems analysis should be viewed as a
specialization itself, separate from "programming"), we have
<language-and-framework>-coders - the guy who comes in knowing
ruby-on-rails can't handle ECMAscript or node.js or C#.NET or ... and most
of them don't recognize 'standard' algorithms, and don't really understand
the frameworks and libraries that they use, so that you end up with
inappropriately-used library calls and blotated code that barely does what
the spec asks for...

®Traveller is a registered trademark of
Far Future Enterprises, 1977-2020. Use of
the trademark in this notice and in the
referenced materials is not intended to
infringe or devalue the trademark.

--
Jeff Zeitlin, Editor
Freelance Traveller
    The Electronic Fan-Supported Traveller® Resource
xxxxxx@freelancetraveller.com
http://www.freelancetraveller.com

Freelance Traveller extends its thanks to the following
enterprises for hosting services:

onCloud/CyberWeb Enterprises (http://www.oncloud.io)
The Traveller Downport (http://www.downport.com)