

Ungineering - mwcampbell
https://glyph.twistedmatrix.com/2014/09/ungineering.html

======
lukifer
The term "engineering" has a place: to convince non-techie stakeholders to
take us seriously and trust our domain expertise.

Outside that context, I prefer to think of myself as a _craftsman_ for small
projects, and a _gardener_ for large projects.

Software never exists in isolation. It is interwoven with countless other
hardware and software stacks, and more importantly, the humans that use and
maintain it, as well as the organizations and processes those humans inhabit.
And every single component in that system is constantly mutating.

The true masters of the craft are those who strive to understand and tame this
chaos: weeding the garden, but also leveraging that wildness in constructive
ways, allowing the garden to grow organically. By making code so readable,
flexible, sharable, testable, and durable, that it exists in a non-stop
feedback loop with its ecosystem. (Taleb's "antifragility" is a useful mental
construct for this ideal.)

Most software projects are not run this way, whether due to a lack of
expertise, budget, process, or all of the above. But given how easy it is to
write bad software (or good software that decays into bad software), I believe
gardening is the proper metaphor for non-trivial software systems.

~~~
jMyles
> The term "engineering" has a place: to convince non-techie stakeholders

This is my biggest gripe with it. I don't want to label people "non-techie
stakeholders."

------
pixelmonkey
I think what people think when they hear "engineer" is, "someone who builds
useful objects that are limited by technical constraints and/or expertise."

As software engineers, we are constrained by software technology and knowledge
of software and computer science / mathematics. This is similar to how civic
engineers are limited by material technology and knowledge of materials and
physics / mathematics. I actually think the analogy fits. I don't see what's
wrong with it. However, I do agree that sometimes the "builder analogy" can be
taken too far.

~~~
tzs
> I think what people think when they hear "engineer" is, "someone who builds
> useful objects that are limited by technical constraints and/or expertise."

That would also describe what many people think when they hear "technician" or
"craftsman".

There is overlap between engineers, technicians, and craftsmen. Wikipedia has
a good description of where engineers fit in: "The work of engineers forms the
link between scientific discoveries and their subsequent applications to human
needs and quality of life".

Here is what it says about technicians: "A technician is a worker in a field
of technology who is proficient in the relevant skills and techniques, with a
relatively practical understanding of the theoretical principles".

It describes a craftsman as a "skilled manual worker who makes items that may
be functional or strictly decorative".

I think most people who are described as "software engineers" are doing things
that most closely match "technician".

------
je42
Very interesting point of view.

However, here is a different definition of engineering:

"Engineering (from Latin ingenium, meaning "cleverness" and ingeniare, meaning
"to contrive, devise") is the application of scientific, economic, social, and
practical knowledge in order to invent, design, build, maintain, and improve
structures, machines, devices, systems, materials and processes." \-
wikipedia.org

It looks like wikipedia has a bit a broader definition of engineering. I would
use the term "engineer" whenever I refer to a person that exactly does this
when creating software.

Further, you could say that "development" is referring to a broader set of
approaches to create software; "engineering" would be a subset then.

------
dasil003
I understand why "real" engineers balk at the idea of calling software
developers engineers. It's because traditional engineering has a litmus test
of hard science that one must master to be even become an entry level
engineer. I mean you can't just go out and start claiming that you're a
mechanical engineer to get a junior position, you have to have mastered some
pretty heavy math concepts, and our educational system is pretty good at
verifying a baseline for such hard knowledge.

But software engineering is still a thing, despite its differences. It does a
disservice to pretend that software engineering is somehow not as difficult a
technical discipline simply because it has a low barrier to entry and
credentials are a dubious proxy for any appreciable skill in the discipline.

The reason programmers deserve to be called engineers is because software,
especially large systems are as merciless in their cause and effect as the
real world. Just as a civil engineer has to master the physics to make a
bridge stand up, software engineers have to deal with the unforgiving nature
of the logic engine and all the abstraction layers built on top of it. But
unlike physics which never changes, the hardware and software substrate that
programmers work with is constantly in flux. All of it is layers upon layers
of predicate logic concocted from the minds of other programmers. It is as if
the very rules of the physical universe were themselves variable and invented
by other engineers. Given this kind of environment, and also the diverse
applications to which software can be applied (any thought as opposed to any
physical object), it's no wonder that software engineering does not have
agreed upon branches and standard academic credentials.

------
cevaris
There is such a thing as an Software Engineer, what you are getting confused
with is an Software Developer. Engineers do require deep knowledge of the
language and hardware at the register level, all the way up. Developers just
download an SDK and hack off some app that is patched together. Big difference
that one word makes. I would like to think myself as a Developer, working
towards becoming an Engineer.

------
bikamonki
Currently, I believe Software Architect is a better term/analogy. My dad is an
architect that also built his designs: he did it all from design to
construction including project/budget management. He's over 70 now, graduated
almost 50yrs ago and since then the 'field' has changed: it has become
specialized. Now the architect only 'designs' the building, the civil engineer
calculates the structure, the PM makes sure times and budgets are met; and
there are a dozen more specialists handling a specific task. The same
transformation is happening to the production of software to the extent that
we now even have UX specialists. Most of us are still like my dad 30 yrs ago,
we are 'full-stack' devs, we are craftsmen (or craftswomen!), we do it all.
Give it time and the software engineer will have is place with a specific
skill and task in hand, the title won't be ambiguous. This is already
happening with big ticket projects, it will eventually trickle down to the
small ones.

------
jMyles
Glyph, thanks for laying this out so clearly. I've often had the inclination
the being called an "engineer" just ain't quite right, but now I really
understand the basis for those feelings.

For my part, I'm not crazy about any of the labels that come in and out of
fashion. I particularly don't like being called "technical." It's such a
divisive term.

I generally just refer to myself as an activist. If I'm being tasked with some
feat of logical expression, then I'm a logic activist.

