Response to Yampolsky From an Architect
Opinion by Michael David Rubin
I found Mr. Yampolsky’s thoughts fascinating. [See Alexander Yampolsky’s “Overcoming the Crisis In Graphic Disciplines” opinion piece at https://upfrontezine.substack.com/p/overcoming-the-crisis-in-graphic.] As an architect, I confess to being unaware of a crisis in teaching mechanical design.
The problem in architectural education is, in my opinion, a tendency towards mindless blather and salesmanship about mediocre aesthetic design – not how to draw, write specs, or solve problems in the field. Does this apply to the need for precision and integrated manufacturing in mechanical design?
Intentions in Architecture
Mr. Yampolsky’s article led me to review some thoughts about the structural-linguistics approach to teaching architectural design.
In the 1970s, “Intentions in Architecture” by Christian Norberg-Schulz [https://mitpress.mit.edu/9780262640022/intentions-in-architecture/] seemed to well-encapsulate architectural design approaches rationally, in a way that would apply generally to all practical applications. His book was a thorough treatment, emphasizing “syntactics, semantics, and pragmatics,” which could be generalizable to any client’s project. But it bothered me already back then to note the book’s strong philosophical influence from Heidegger and Jaspers, existentialists who also embodied Nazi influence -- not that Norberg-Schulz himself evinced any of that.
Anecdotally, I’ve been surprised to hear from personal friends from Russia and Central Europe who, as architects, seemed to feel a bit ashamed that they were not also philosophers — just as academic economists sneer at businessmen as mere “practitioners”, the academic economists who sanctioned inflation and currency devaluation (due to Keynes’ toxic influence) that lent itself to impoverishment, and excused outright social violence.
My impression is that trying to over-systematize practical design leads to clunky and expensive build results, the more so in habitable structures than in manufactured parts and assemblies.
Hierarchy of Influence
What’s to me telling is that at the end of Mr. Yampolsky’s own thorough and insightful analysis, we find a hierarchy of influence, by command. Government bureaucracy, in effect, determining what is to be designed, most probably in the manner dearest to the hearts of ruling bureaucrats: prescriptive versus performance definitions and specifications. From which all the analytic symbolism about physical description follows, if I follow his reasoning.
I think that, with no moral critique of Mr. Yampolsky, there is a deep cultural issue going on, which holds back the streamlining and simplifying of proprietary advances in writing code. It intertwines, so to speak, with the virtual bribing of relevant regulatory bureaucracies by the financially successful corporate software giants we all have to deal with.
(I’m one of those who found writing computer code to be a stupefying boring activity; although, where inevitably necessary, I learned how to do it middling well, sufficient to crank out simplistic subroutines, scripts, and whatever. I’m also grateful to those who excel at it.)
Freedom to Innovate
An embedded, historic belief holds that if we truly allow free individual talent to innovate, and then further allow such talent to collaborate freely with others, it is somehow “socially” dangerous. And that we must always give our rulers absolutely final control over all human activity.
I note the legal copyright/patent definitional fiddling that has been allowed for software only, along with its unjustified near-endless extensions in time. And why we’re universally pushed into subscriptions. Similarly: why major cultures such as those of Russia or China, with traditions of technical excellence and scientific advances, always seem to “choose” political dictatorships for their governance. Control, control, control? Freedom is scary? Implying individual accountability?
Well, all that to one side, why would teaching new design professionals an abstruse symbolic language, however logical (if the initial embedded assumptions prove effective), improve results? I think we’ve seen entire professional careers swallowed up by the need to master the ins and outs of one or another giant software program. It saddens me to see potentially excellent architects knowing all the tips and tricks of, say, AutoCAD, without much of any idea about how to really put buildings together. Or how to site them. Or how to cost them out. Or how to schedule their construction.
I think we could benefit from re-imagining and restoring the simple, ancient, and completely natural process of qualifying through apprenticeship. Just as you learned from your father, or I from a master architect who said, “Look!” as he drew something with anything handy on a scrap of tracing paper at my desk, to show me the rightness of it, then and there, in seconds.
My intended non-profit will establish technical training institutes that offer elective academic-type coursework for those students/trainees who deem it useful, in addition to their skills training. Issues of basic citizenship, including economic law, will be mandatory, to graduate young men and women fully competent to make constructive career and citizenship decisions on their own behalf, while doing their excellent, well-paid work.
Michael David Rubin is an architect, planner, and consultant with Integral~Design in Gloucester MA USA.


There certainly are incompatibilities between CAD systems, although not as severe as in the 1980s-2000s when exchanging files between different systems was inconceivable.
Easy networking and the Internet changed that, so that efforts like open DWG, STEP, and IFCs helped.
With many CAD packages being pretty much the same as each other, teaching technique ought to again be the emphasis over how to use the UI.