ժҿֆիւթև is a user on mastodon.technology. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.
ժҿֆիւթև @deshipu

Why are we still teaching programming like it was a new emerging technology that nobody knows anything about, and not a well explored subject with at least 50 years of solid history?

Why are the lessons like an arts and crafts course, where we just let people build something, instead of a literature course, where we read and analyze classics, and learn from the experience of others?

And why are we surprised when we discover that every generation just reinvents the mistakes of the previous one?

· Web · 89 · 102


I find this interesting because the complaint I usually hear is that programming should be taught more like engineering; which is true as long as the kind of programming you're going to be doing is the kind that's like engineering.

I'd say a literature course teaches analysis and criticism - how to read and engage deeply with texts - while an art course teaches you a variety of techniques that you can choose to apply to your own practice. In which case the "art course" approach would probably be the right one for programming as a creative activity.

@ghost_bird @deshipu i know that asserting "coding is more like postmodern poetry than hard science, in a lot of cases" gets people's defenses up, but it works for me.

that + group analysis = graduate level poetics work. having a background in that helps a great deal in wrapping my head around more complex structures/languages.


@shoutcacophony @ghost_bird @deshipu
Even though writing new code isn't a lot like writing literature, reading somebody else's code really benefits from experience with hermenuetic analysis.

The death of the author becomes a really important idea when a system is executing on all possible valid intents and the original intent is basically just a distraction from the operation. The shit people criticize deconstructions for doing is basically red-teaming & absolutely vital.

@deshipu I'm not buying this. It's not that easy because "code is not literature" [0] Imho it's just more time effective to teach best practices and then learn when to deviate from them. I never got the feeling that we know nothing about programming during my studies.

The problem with reinvention is a problem of historical literacy. Although I'm also not convinced reinvention is always bad, maybe the world just wasn't ready back then. (resurgence of FP etc)

[0] gigamonkeys.com/code-reading/

@fap @deshipu

Still learning what has worked in the past and what's been tried would make a better education in general.

Maybe one should see the historical context as essential. Otherwise everyone will do the evolutionary steps for herself. From BASIC via C to FORTH and lisp / Ada / Haskell, to OO and back.

The tragedy is that a lot of people get stuck at the OO BASIC step and think they have seen everything.

@ckeen @deshipu Yeah I can get on board with that. I'd very much enjoyed a code reading and a code history class, I just don't think code reading should be our main teaching instrument.
One problems that I also see is that more and more universities teach OO only. You have to get lucky and take a class with a professor that uses an other language than Java to learn anything else. (though the other extreme, a different language in every course, can also be very straining)

@fap @deshipu That's because a lot of universities (at least in Europe) are pressured to make student fit for industry needs and not for a primarily academic education.

@fap @ckeen I think that code reading is generally a very underappreciated skill, and that a lot of people who leave the university thinking that they already know everything they will need at their work suddenly discover that they are not prepared to handle a legacy codebase and to review the code written by their team mates. And reviewing code could be such a great homework for university — everybody gets some classic piece of code, and they have to review it and propose improvements...

@deshipu @fap Yes it would be an improvement for working in a programming team. Clever professors sneak that in as it is strictly not an academical curriculum. Not so clever ones make it the central theme of a boring seminar...

@fap @deshipu I guess my point is that it's an important skill but is best taught 'in passing' but gets tedious once you try to formulate strict rules to follow.

@fap If you don't like comparison to literature (I'm not saying code is literature, by the way, I'm just referring to the mode of learning), then take architecture. We don't give aspiring architects a few basic engineering principles and say "now go design buildings until you are good at it". A huge part of the education is learning about old techniques and styles, even though the technology has made many of them obsolete. They still learn about gothic cathedrals there.

@deshipu How would that look like? Which programs would we study? Would we study UML diagrams of them?
What would you like to change in the current courses on software architecture?

@deshipu @fap They do at least study historical FAILURES. Sometimes. Back when I was a young fox we learned about Therac-25 and The Things It Taught Us Not to Do.

Though it's surprising to me that a lot of modern CS programs don't even mention it.

@pasqui023 @Azure @deshipu @fap Similar here; my Intro to Software Engineering course taken a year ago covered a bunch of "here's examples of what not to do", giving reasons rather than merely rambling off best practices. Therac-25, FBI Virtual Case File, London Stock Exchange, and several others (including finding one of our own and making a presentation on it).

@digitalfox @pasqui023 @Azure @deshipu Interesting, we certainly heard about software failures like the Mars Climate Orbiter and what they did wrong but it's not like we read any code from those projects or studied their design. Did you discuss those projects in greater detail? Any online resources online you can recommend?

@fap @digitalfox @pasqui023 @Azure I never did, though I hear that the source code for the Apollo project has benn made available on Github — perhaps a good place to start?

@deshipu @digitalfox @pasqui023 @Azure Ty, for anyone wondering:

But that's not really what I'm looking for. Reading ancient assembly code targeting an unknown platform without much guidance is not exactly my favorite pastime. xD
Something like "The Architecture of Open Source Applications" [0] but with negative examples would be interesting.^^

[0] aosabook.org/en/index.html

@deshipu CompSci lecturer here.

IMO there are 2 big things going on.
First, we still don't know all that much about how to teach software engineering; even in software engineering, there is still intense debate about which methodologies are good: I'm not only referring to agile/waterfall/whatever, but also testing methodologies, design methodologies, as well as questions like “does static typing prevent bugs” (spoiler: it does).

Second, there is no incentive for lecturers to give a damn. :(

@deshipu on that I think teaching the basics of code and then getting those learning into the open source community might be a cool thing, showing them some common mistakes or even some funny hysterical ones.

Teaching someone how to use the resouces available to them (or better teach them how to learn to use things like say a search engine, and let them go their own way)

I find learning in creative fields is WAY too restrictive and marking is way too limiting.

@deshipu education over all needs a good rethinking.

@deshipu It's an interesting idea. What would you nominate as classics worth studying? Widely used stuff like BSD? Obscure might-have-been paths that never made it into established technology or only did so slowly and in distorted form?

@deshipu For a while there was some interest among the Lisp People to create a software-as-literature journal called Code Quarterly but it never got off the ground for various reasons.

@Azure @deshipu Most CS programmes have courses on algorithms and datastructures. Arguably, any program is simply a concrete instance of these. So we don't analyze programs but we do analyse algorithms and we learn from the experience of those who invented better ones.

Many CS programmes also have courses that teach e.g. the lambda calculus as an underlying universal formalism.

Programming in a particular language is a very specific skill and I do think learning by doing is an important component.

@deshipu @Azure the linux kernel. it's (ofc) not necessary to read the whole thing, but seeing the architectural decisions and comparing to what preceded them and had problems that needed fixing is super insightful

@martensitingale @Azure I'm not sure I would recommend studying Linux architectural decisions (and the whole decision process) to an unprepared student. It's too horrible even for many experienced programmers. Could turn people off from programming and cause permanent psychological damage.

@deshipu @martensitingale That's arguably a problem with all widely used software of sufficient complexity :)

@deshipu @martensitingale There are at least some places that do some history. Not reading the CODE per se, but looking at the development of ideas over time and why people did one side over the other and the like. I think those tend to wait until later years and get shoved into topic-oriented classes.

@Azure @martensitingale I think that looking at the actual code is really a very important part of it, and even better, stepping through that code, or changing something in it, so that you actually *feel* how it works. There is a huge difference between being told something and actually trying it. On the other hand, that would require at least a basic familiarity with the programming languages of the time — which might not be such a bad idea either, to be honest.

@Azure I don't feel competent to set a curriculum for 4 years of university, but I would imagine it to be organized by topics, for instance, you could explore different approaches to graphical user interfaces (starting with Smalltalk, through early DOS programs, early Windows, then maybe Delphi, Java (swing and gwt, etc.), up to modern API). Or maybe compilers, starting with some early stuff like COBOL and ALGOL, and exploring different approaches up until today. This kind of stuff.

You're really on the mark with the comparison between CS education & arts and crafts classes.

Having taken CS courses at a school where it's part of the engineering program and another where it's liberal arts, the way it's taught really differs from even engineering programs. The general lack of focus on history and justifications for best practices is weird.

In terms of the 'classics', we really do have some good readable open source candidates.

The plan9 implementations of standard unix shell utilities are amazing examples of beautiful, clean, concise C code. But I get how someone who hasn't read the plan9 source would think that all non-trivial C code is either messy, proprietary, or too big and context-dependent to show to students.

I haven't ever seen well-written non-trivial java code, though.

A big problem I have with CS pedagogy is that it has an emphasis on principles divorced from practice, with the principles standardized by bodies that are largely unconcerned with practice. (Students who have never written non-trivial projects write endless trivial ones with strange demands based on 25 year old Sun marketing material, while being tested on their ability to parrot back that marketing material.)

Code reading can help add context. I push for language variety, personally.

@enkiv2 Isn't that pretty normal in Academia in general? Even if you turn to poetry, what you discover are "canonical" interpretations and analyses of classics, which you basically are supposed to learn and emulate.

I have nothing against small projects — a lot of small projects of which some are failed and some successful let you learn more, than one huge, inevitably failed project.

Small projects are different from trivial projects. In this particular case, unrealistic toy projects are chosen because they best illustrate principles that, in non-trivial projects, are almost never actually true.

I may be lucky, because none of my lit classes expected me to memorize other people's canonical interpretations of classic works to the exclusion of the creation of my own!

@deshipu because large portions of the industry base their self-respect and careers on doing things in back-assward ways and saying it's better for reasons of machismo or gatekeeping or whatever. see: Go


To teach programming like (or, rather, as) literature, we'd have to acknowledge that it has more in common with the humanities than it does with anything we might term STEM.

apropos: 10print.org/

@beadsland I don't know if it has to have *more*. It has something in common with both of them, do we really have to choose one or the other? Can't we have some variety?

@deshipu Is vs. ought.

My contention is that programming is language, and thus literature, yet our pedagogy largely insists that programming is math, and thus STEM.

One can say that programming ought to be both, but that doesn't mean that programming is both.

Does engineering (broadly) involve the production and consumption of texts? Yes. Does that make the production and consumption of texts the subject of engineering? Or is writing and reading (broadly) a subject onto itself?

@beadsland Does gardening involve walking around the garden? So that mean's it's a sport, right?

@deshipu Engineering is not literature. That does not mean the language arts employed by engineering is thus best studied as engineering. Insofar as engineering uses tools of literacy, those tools of literacy are the subject of literacy.

Gardening is not a sport (usually). That does not mean the physical exercise employed by gardening is thus best studied as gardening. Insofar as gardening uses the tools of physical fitness, those tools of physical fitness are the subject of physical fitness.

@beadsland That's why I argued for variety. Text is not the only tool used in engineering and programming — you need to study each of the tools involved with methods best suited for those tools.

@deshipu Ah, but programming isn't engineering. Just as programming isn't math.

There happen to be some engineers who write programs in the course of their work. But most programmers don't do anything resembling engineering.

Corporate title inflation notwithstanding.

@beadsland The programming that matters (that is, is not just a hobby one does in one's free time for one self) is engineering. Often bad engineering, mostly because lack of experience, but still engineering notwithstanding. It's building and maintaining of public infrastructure.

@deshipu Your very last sentence here is the very first time I've heard anyone make a cogent counterargument to my programming is not engineering assertion. Most are too busy insisting (incorrectly) that programming is math by virtue of logic.

But "buidling and maintaining of public infrastructure" circumvents that, as it doesn't depend on a postulated basis in math.

Thank you, this gave me something the chew on. I'm not won over, but at least its an argument that requires consideration.

@beadsland To be honest, I'm a math major, but in the 20 years of my programming career I never really had to use any of my math skills in an actual practical case. Sure, they come in handy when playing with code, but the professional work is mostly about solving trivial-but-not-obvious problems discovered in practical use. And I believe that the main focus of engineering is exactly that — solving problems with technical means, preferably with minimal amount of those technical means.

@deshipu When interviewed by Cosmopolitan, Grace Hopper said of programming "It's just like planning a dinner!"

One could say that planning a dinner (especially, when planning for predelictions of guests) is all about trivial-but-not-obvious problems. Does that make it engineering?

Should catering be taught as hospitality engineering? Or can we agree that trivial-but-not-obvious problems is not strictly the domain of engineering.

The infrastructure assertion makes for a stronger argument.

@deshipu Also, I'm not convinced that programming qualifies as "technical means". There are technical aspects, techniques, to writing and composition in any genre, but that doesn't make writing a "technical means".

@deshipu Insofar as programming is taken up in the construction of public infrastructure, I will grant that the construction of such public infrastructure is, indeed, engineering.

However, most of those involved in any given public infrastructure engineering project are not engineers and are not doing engineering. They're doing architecture, project management, pile driving, crane operation, ironworking, masonry, pipefitting, carpentry, landscaping… Very few are engineers doing engineering.

@beadsland Back in the days there used to be coders, who would take the math formulas and convert them into assembly, and assemblers, who would take the symbolic code and convert it into machine code, and transcribers, who would take that code and type it out onto punch cards. There used to be computer operators, who run those punchcards through the computer, attach the printed results and send it back. All those positions succumbed to automation nowadays. Only engineers and architects are left.

@deshipu And then folk like Grace Hopper invented programming languages. Which allowed trivial-but-not-obvious business problems to be solved without resorting to math.

The languages were still symbolic, but in the way that languages, qua languages, are symbolic. It wasn't engineering, but communication.

Programming using languages was something new, different from math, assembly, transcription, computer operation, architecture, and yes, different even from engineering.

@beadsland Agreed, the engineering didn't come there with the programming languages. It was there before in the "business problems" part. Programming languages just got adopted there, because they were a good tool for solving those problems. But the engineering was there already.

@beadsland So you are right that programming is not engineering, just like, say, roads are not engineering. They are just tools that are mostly useful in engineering tasks. Of course, you can use programming for, say, art (though most artists are actually part-time engineers, especially when they do things at scale), entertainment, education, science, leisure, etc. — it's just not the biggest and most visible use.

@deshipu Agreed. Bricks can be used in art. But the biggest and most visible use of bricks is in building construction.

An engineer, I think we can both agree, was involved in the construction of such buildings. (Just as an engineer was involved in the fabrication of such bricks.)

But those who operated the mixers and mortared the walls, most of those were not engineers and were not doing engineering.

Interestingly, those jobs are typically paid very well without resort to title inflation.

@deshipu Right. The engineering was there. If the engineering wasn't there, you couldn't do the programming. That doesn't make programming engineering.

You couldn't do papermache without materials & chemical engineering to make paper and paste either. Doesn't make paper mache engineering.

Engineering was part of building Microsoft Word just as engineering was part of building the Brooklyn Bridge. But most of those doing work on either project were not engineers and were not doing engineering.

@deshipu *notices the absence of a question mark where a question mark was due*

*wishes once again for a typo revision feature*

@beadsland Well, maybe I'm weird, but I do think that organizing a big and complex enough event (be it a dinner, a conference or a rock concert) involves a lot of engineering work. Of course if it's a tea for 3 people, the engineering aspects become so trivial, that they practically disappear, and the task can be handled without much engineering training.

Gardening is engineering too, when done at scale. Or, say, opera — all those stage engineers are there for a reason.

@deshipu I agree, because I don't think that solving trivial-but-not-obvious problems is engineering work. It's work, surely, but not engineering work, as such. We can call it engineering, if we want to engage in title inflation. Title inflation is rampant in many industries.

Stage engineers, to the best of my knowledge, have specific liability concerns that stage managers do not. As with public infrastructure engineering, this is an issue of how one's work is regulated in the public interest.

@deshipu *notes other typos*

Where the hell is that typo edit function??!?!?!

@beadsland It's just like writing books is literature, as long as you publish them, but of course doesn't have to be if you just write for yourself.

@deshipu Okay, no, this stretches your argument a bit further than it will go.

The vast majority of programming in published form is not, in and of itself, public infrastructure. It's public, and thus may be (and often is) taken up and used by those who construct public infrastructure, but that's not the same as being infrastructure, as such.

Similarly, construction materials (bricks, glass, sheetrock) aren't public buildings. Even if they are taken up in the construction of public buildings.

@beadsland That is true. So not all the software engineers do jobs of civil engineers. Some do the job of tooling engineers, some do the job of logistic engineers, some do the job of fabrication process engineers, and many are just maintenance engineers. And if any of them do their jobs badly, because they don't have engineering training, you have a disaster coming. Remember that factories that build fabrication materials also require engineers.

@deshipu Most of those involved in a public infrastructure engineering project (bracketing the equivocation that is "crane engineer") are not doing engineering, but using the products of engineering.

Fabrication process engineers, for instance, fabricate commodities that are then purchased by a project manager. They may *talk* to the public infrastructure engineer to work out specs, but they aren't building the public infrastructure, only materials for it.

As for "do their jobs badly"...

@deshipu Here's the thing, vis a vis public infrastucture engineering. The engineers who are engineering public infrastructure are typically required by their jurisdictions to be licensed or otherwise certified to even market themselves as engineers.

Moreover, those engineers generally must be insured against liability for doing their jobs badly--as engineers. They risk losing the right to call themselves engineers.

Others involved in such projects may have liability, but not as engineers.

@beadsland Yes, and the people who are building the public computer/network infrastructure don't have any responsibility or certification requirements whatsoever. I think that's because it's such a new area that grew so explosively, so all the hands were needed. But I don't think it can continue like that for much longer.

@deshipu Those who apply asphalt to a road are not liable to lose their engineering licensure for shoddy workmanship. They may be liable for shoddy workmanship, but not as engineers. Whether the engineering of a roadworks project is sound is distinct from whether the workmanship of those who are building such roadworks is sound.

Yes, it's a new area.We should be licensing the engineers who do software infrastructure engineering, but building software infrastructure is not engineering, as such.

@beadsland Fabrication process engineers design the process of fabrication — they don't fabricate the products themselves, they plan and organize the fabrication, so that it's as efficient, safe, consistent, etc. as possible. And they also maintain it, to make sure it continues to run smoothly.

@deshipu Right. They design the process of fabrication for the firm doing the fabrication. Most of those involved in the fabrication (without whom no product would be fabricated) are not engineers and are not doing engineering.

The fabrication engineer is an essential minority role in the production process, as engineers typically are in all projects if anything is ever to be built.

Engineers typically don't make things. They engineer what others make. Programming is about making things.

@beadsland That's true. But as I already pointed out, in the case of software, all the non-engineering jobs have been gradually automated away, and today are done by the compilers, deployment scripts, continuous integration automation, etc. — all that is left are the engineers who design and maintain them.

@deshipu As you have asserted without defending. My counterclaim is that all engineering jobs have been gradually automated away by programming languages, which means that most public infrastructure projects that involve programming languages require very few engineers.

But then, most public infrastructure projects that don't involve programming also require very few engineers. As it should be. In both cases, engineers are essential, yet nonetheless a minority in terms of who is doing the work.

@beadsland The problem is, engineering can't be automated. There has to be someone who plans everything, someone who makes the decisions, someone who sets the milestones and sub-goals, someone who decides *what* the computers are supposed to do. Someone has to design the processes. That is engineering, and it requires a lot of knowledge, imagination and foresight. There have been attempts at automating it, and it's a wet dream of anybody who is not an engineer to be able to do so. So far no luck

@deshipu Agreed!

Engineering's essential or nothing will get built. Granted, most of what you list here isn't engineering but project management—which is also essential—or again, nothing will get built.

But project managers don't mortar bricks. Neither do engineers. They're essential, but most of those who work to make a thing aren't engineers or project managers.

As for knowledge, imagination and foresight. Ever written fiction? Nonfiction? A post-it note asking someone to remember the milk?

@deshipu In other words, all that is left are those who claim the title "engineer" to do non-engineering work, whether work of programming (writing programs) or--to take your examples--operating (running programs that others, also not engineers, wrote).

A bricklayer can claim the title of wall assembly engineer. They don't have to be licensed as an engineer and be liable for engineering faults to do so. But they can.

They're paid well for important work with or without such title inflation.

@beadsland A brick layer doesn't make decisions. He follows a process, that he has been taught, probably developed over the years by a number of engineers. They don't have responsibility, because nobody asks them to modify the process they are following to adjust to ever-changing real-world situations.

Writing programs is about making decisions about what the computer is supposed to do. Once a program is designed, it can be reused as many times as necessary, there is no need for someone for it.

@deshipu In spurts between appointments yesterday, I managed to get down some 1800+ words (something like 25 toots worth of verbiage) on this topic into a google doc, fleshing out my further thoughts. Out of my appreciation for your challenging arguments thus far, I’ll spare you the copypasta of that text and try to distill only some highlights here.

@deshipu Before I pick up with your last few toots, I want to explain a seeming contradiction in my previous argument, and then expand on several points that I contend engineering is not, before finally setting forth a clearer statement as to what I believe engineering is.

@deshipu So first, the seeming contradiction. At one point you re-asserted a claim that automation in computing meant that only the engineers (and architects) were left. I countered with a claim that programming languages meant that only the non-engineers were left. You then, rightly, pointed out that you can’t automate away engineering. Which I agreed with, asserting that engineers were essential.

@deshipu This seeming contradiction arises from the fact that the words engineer and engineering are not univocal. As we’ve already covered, a (civil) engineer on a building project is not the same thing as a fabrication engineer at a supplier for the same project. Engineers can be found throughout a supply chain, but always are the minority in terms of specialization of labor.

@deshipu Likewise, a computer engineer is not a software engineer. In asserting that PLs meant only non-engineers were left, I was thinking in terms of computer engineers: engineers those subject matter expertise in the historical moment formed when programming consisted of plugging leads into a control panel and thereafter working out problems in terms of hardware-specific machine instructions.

@deshipu In the same way that commodification means sourcing Post-It notes for a project does not require consultation with a chemical engineer, so the automation under the hood of compilers and interpreters ensures that programming generally does not require the involvement of a computer engineer. That doesn’t mean engineering is no longer required, only that prior engineers have been so good at their jobs as to render themselves superfluous at that node in the supply chain.

@deshipu Which is all to say, you can automate away engineers, within a given scope of production. Indeed, one might say that this is the ultimate expression of good engineering. Nonetheless, the need for engineering will always crop up someplace else.

This, of course, brings us back to the question of what, exactly, engineering is. First, some things it is not:


1) Engineering is not what everyone on an engineering project does.
2) Engineering is not solving trivial-but-non-obvious problems.
3) Engineering is not project management.
4) Engineering is not knowledge, imagination and foresight.


In the first case, I think I’ve already belabored this point pretty thoroughly. To save verbiage going forward, I shall simply invoke this as Proposition 1.

In the second case, your maths background is perhaps showing, as triviality vs. obviousness is--a little research reveals--a hobgoblin of maths, and in particular, maths-related humor. One might translate this construction as “simple once you know the answer”.


My contention remains that the world is chock-full of trivial solutions that are non-obvious to those who don’t yet know them, something that is painfully evident in the office I visited today, where a fresh crop of college freshmen are messing up everything from laying out the elements of a business letter to printing and stamping envelopes.

As a fictionalized Jaime Escalante expounds in Stand and Deliver: “It's not that they're stupid - they just don't know anything."


The key to trivial-but-not-obvious is not that you know the answer, but that you recognize the problem as one that will be trivial once you do.

This, in turn, informs the search pattern you employ in trying to find out what that trivial answer happens to be, rather than invest a great deal of energy in reinventing what has most likely already been solved by others more knowledgeable than you. Your clause amounting to “minimal technical means”.


Thus, Proposition 2.

Another way to put this is that “Engineering is not wisdom.” Good judgment in recognizing the triviality of deceptively new problems is down to experience, regardless of the problem domain.


In the third case, you began to stray into describing engineering in terms of figuring out what needs to be done when. If this were true, then there’s a large section of my bookstore’s self-help aisle that should be recategorized as engineering literature.

Less flippantly, I’ll just reassert that the essential role of an engineer on any project is something other than managing that project.


A corollary to Proposition 3 might be: “Project management is essential. But it’s not engineering.”

Of course, an engineer may also manage a project, just as an engineer may also hammer nails. Refer to Proposition 1.


The fourth case is where I had to step away from the discussion to attend to other responsibilities.

Just as wisdom is not the exclusive domain of engineering, so too knowledge, imagination and foresight are not engineering-specific capacities.

Everyone from accountants and advertising execs to veterinarians and writers can claim these three traits, with the relative abundance of said traits being reflected in how well they do their jobs.


Heck, one might argue that these traits likely rank in the top 10 for what any of us wants in a life partner, after kindness and consideration. We generally want the human beings around us to know things, to form new ideas and to anticipate likely outcomes.

These are good qualities to have, whatever one's career trajectory.


It was once said that a lawyer will tell you why you can’t do something. A good lawyer will tell you how you might be able to do it.

An engineer who lacks knowledge, imagination and foresight is not a good engineer. It doesn’t mean they’re not an engineer, as such.


So what, then, is an engineer. Here’s my contention:

First, and foremost, the engineer has the role of inspection: It is for the engineer to determine if existing structures, not only the product of a project, but all those structures--natural and built--that are implicated by said project, fulfill specific constraints, both physical and regulatory.

(Aside: yes, even programming projects have physical constraints.)


The second role of the engineer that of design, follows from the first role: wherein the engineer takes into account the constraints of both preexisting structures and planned structures to determine the tasks that must be performed so that all relevant structures will pass inspection going forward.

It is this inspection-focus that makes the design work of an engineer different from the design work in other disciplines.


A graphic designer, for instance, must also consider both physical and regulatory constraints in their work.

Arguably, graphic design can involve more constraints than engineering design, for in addition to the physical properties of medium and materials and the legal requirements germane to the industry they’re operating within, a graphic designer must also contend with constraints of corporate branding and style guides, as well as cultural norms and customs of use.


The difference between graphic design and engineering design is that in graphic design, if the designer fails to meet constraints, it doesn’t take another graphic designer to evaluate their work and identify where they fell short.

If colors aren’t true or salient elements are cut off in the bleed, if a design is confusing or illegible or censurable, the consumers of the work will notice, and likely speak up, without any special training being required of them.


By comparison, a bridge that does not meet load-bearing requirements or a building with insufficient fireproofing can stand finished for many years before the compliance failure is discovered or revealed.

It is for this reason that engineering requires licensure or the jurisdictional equivalent, and it is for this reason that engineering incurs forms of liability that other trades and disciplines do not.


That said, such potential for dormant, hidden problems is shared by some other fields, corporate accounting being one.

If you really want to know if an accountant did their job correctly, you bring in another accountant to examine their books. Rarely are corporate accounting failures readily evident to a layperson on casual inspection. So it is for engineering failures.


That engineered structures must be designed to pass inspection by a qualified engineer--and not just pass muster with one’s general audience--is what makes engineering design different from most other sorts of design. Or so I contend.

And that’s... 1400 words. Oh well, I’ve committed to it. So here goes...


"A brick layer doesn't make decisions." This evidences a degree of chauvinism, no?

Everyone makes decisions. Every job involves decision making. Try laying bricks and not making decisions. I dare you.

The scope & consequences of decisions may differ from one job to another, but the capacity and requirement for making decisions does not. There is no job that doesn't require adjusting to ever-changing real-world situations—because all jobs are performed in an ever-changing real world.

@beadsland OK, I think that at this point we are basically arguing about the meanings of words, so we might as well just stop there. Thank you for your time, you made me think about some issues that I didn't think about before, that are very relevant to what I'm trying to do.

@deshipu For me, the whole argument comes down to the importance of the meanings of words, and the very real consequences of gratuitous misuse of words, hence my regular return to the question of "title inflation".

That said, I'm glad you got something to cogitate about out of the discussion. I certainly did! So thank you again!