Just a general question. As we all know, the industry is experiencing a digital shift and more and more processes are becoming 'computerised' due to it being seen as generally more efficient and sustainable. So do you think architects should learn how to code? If so, should this be taught from the university level?
it would be more helpful to know <I>the</I> code, rather than knowing how to code, but when you use coding to put <I>the</I> code to good use in an architecture office setting you’ll be good as gold.
Jan 20, 22 7:11 am ·
·
randomised
I clearly don’t know how to code, not even basic html italics and am useless in that respect, I also don’t know the code. Going to put my skills and education to use making nft architecture, that’s all that’s left for me to do…
I was a hobby programmer + web designer through high school and college (this was back in the late 90's, when such things were easier, but also dorkier and not as profitable), and I think being versed in the way of thinking as a programmer (that is, an understanding of algorithms, recursion, and so on) has helped me as an architect - both in a practical "I understand BIM + Databases" sense, and the more abstract "I can put together a project schedule and balance team priorities" sense. The actual "code" I know has been a fun distraction if not largely useless, but I don't work for a parametric firm (and most of you won't either).
So I suppose I'd advise today's students to take a few classes in CS, but more to learn the substructure of thought + reasoning than to learn the syntax.
In a deeper dive into algorithms and design thinking as part of a research assistantship for one of my university professors, I discovered that Christopher Alexander's, A Pattern Language, is actually quite popular in computer programming circles for a lot of the same reasons you note here, but the other side of the coin (in a manner of speaking). It's even influenced other books/essays focused on software rather than architecture.
One of the more notable is, Patterns of Software, by Richard P. Gabriel where Christopher Alexander himself wrote in the forward, "What was fascinating to me, indeed quite astonishing, was that in Gabriel's essay I found out that a computer scientist, not known to me, and whom I had never met, seemed to understand more about what I had done and was trying to do in my own field than my own colleagues who are architects."
Maybe all computer programmers should learn how to architect?
My thesis advisor was an Alexander protege and put on a bi-annual conference about pattern languages. It was more widely attended by programmers than architects (Ward Cunningham gave a fantastic lecture!)
, but as an architect I learned a lot of valuable lessons (about architecture) from the programmers.
Perhaps not coincidentally I think Alexander is one of the most frequently mis-understood (and underrated) architectural theorists of the past century.
tduds I'm curious, since you learned from a protege. From what I've read in his books, and more current analyses of his oeuvre, I think he's got a point about pattern. Why I think he's a crock is that - surprise surprise - he's got them all figured out, and if you don't agree, then you're a terrible architect. I don't buy it.
I actually think the (later published) volume 1 book in the series, The Timeless Way of Building, was better than, A Pattern Language, precisely because it was more of the theory and less of the "all figured out" patterns. But it rarely is even acknowledged by architects who just want the patterns all spelled out.
Don't get me wrong, I also think there is quite a bit of hokey thrown in there ("quality without a name" ... come on, that's the best you can do?) that you have to simply roll with to make it through. Overall, I think he was onto something, but maybe just didn't quite get it refined well enough to be taken seriously by a broader architectural audience.
I think what programmers understood, and what many architects missed, is that the "A" in "A Pattern Language" is the most important word. It's not "The Pattern Language." Most of the architecture world mistook the book as a prescriptive text, rather than a single instantiation of a framework.
Personally I disagree with many (but not all) of Alexander's patterns as a prescriptive tool, and I think a lot of his later writing leaned too hard into his personal preferences instead of the theory that his first books nailed. But I strongly support the framework as a method for organizing abstract priorities into concrete "patterns" than can be applied and checked across scales and phases of a project.
I don't think Alexander is a good architect, I do think he's a good theorist and a brilliant meta-thinker. His great success has been to provide designers with a system of organizing design thinking.
edit: EA I definitely agree The Timeless Way of Building is a better book.
I think it should be a mandatory part of architecture curriculum. It's the direction that things have been going since 2000. In the design phase of projects, when using Rhino, it's necessary to be able to program grasshopper to meet project objectives. Same with Revit, you need to know Dynamo. To best program in both Grasshopper and Dynamo, you need to know how to program in C# and Python.
Jan 20, 22 12:18 pm ·
·
tduds
I think these are all means to an end, but I wouldn't say they're crucial to architecture overall. All of these technologies are simply tools. In some cases, they're the right tool for the design you want to explore, but in many more cases other tools are more appropriate.
Jan 20, 22 12:26 pm ·
·
bowling_ball
We oversee the construction of about $100M in projects we design, every year. We've never used any of those tools. Never say never, but none of it is actually needed. It's a choice, not unlike crayons or markers.
Waaaay back in the day, I learned Fortran 77 - even though I have avoided becoming a programmer professionally (I've even turned down jobs), I believe learning the "coding" approach to logic was very useful in terms of general cognitive development.
Specific to architecture, on the other hand, if what you really want to do with your life is architecture, beware of becoming a software specialist.
So this topic came up in the office today. Currently working on a large competition 2 million + sq.ft and while I'm manually trying to figure out things on paper and small digital models... in comes some other colleagues (joint-venture) from across the country with shiny coding proposals that, in the end, will get the same results I got. I guess people rather the plastic box under their desks to do the design work.
Maybe, but IMO, it should be up to a person. For me, I tried to learn how to code but just failed miserable...it is totally not my thing. TBH, I am also new to design, so probably my opinion does not worth much right now.
Jan 27, 22 12:44 am ·
·
Block this user
Are you sure you want to block this user and hide all related comments throughout the site?
Archinect
This is your first comment on Archinect. Your comment will be visible once approved.
Should architects learn how to code?
Just a general question. As we all know, the industry is experiencing a digital shift and more and more processes are becoming 'computerised' due to it being seen as generally more efficient and sustainable. So do you think architects should learn how to code? If so, should this be taught from the university level?
Why or why not?
should? No. We have enough to do already. Let’s not romanticize our growing dépendance on automation/tech further than it already is.
Can? If you want to but it won’t rely help in the vast majority of your real world tasks unless you feel the need to be pigeon holed.
it would be more helpful to know <I>the</I> code, rather than knowing how to code, but when you use coding to put <I>the</I> code to good use in an architecture office setting you’ll be good as gold.
I clearly don’t know how to code, not even basic html italics and am useless in that respect, I also don’t know the code. Going to put my skills and education to use making nft architecture, that’s all that’s left for me to do…
If you work with parametric tools, such as Grasshopper/Rhino, then C# and Python are pretty good places to start.
They don't even teach you how to construct a building in school, they don't need to add coding.
As with anything, learn how how buildings go together first. Then you can use whatever technology comes with the times.
Learn to code to leave architecture for triple the pay.
I was a hobby programmer + web designer through high school and college (this was back in the late 90's, when such things were easier, but also dorkier and not as profitable), and I think being versed in the way of thinking as a programmer (that is, an understanding of algorithms, recursion, and so on) has helped me as an architect - both in a practical "I understand BIM + Databases" sense, and the more abstract "I can put together a project schedule and balance team priorities" sense. The actual "code" I know has been a fun distraction if not largely useless, but I don't work for a parametric firm (and most of you won't either).
So I suppose I'd advise today's students to take a few classes in CS, but more to learn the substructure of thought + reasoning than to learn the syntax.
In a deeper dive into algorithms and design thinking as part of a research assistantship for one of my university professors, I discovered that Christopher Alexander's, A Pattern Language, is actually quite popular in computer programming circles for a lot of the same reasons you note here, but the other side of the coin (in a manner of speaking). It's even influenced other books/essays focused on software rather than architecture.
One of the more notable is, Patterns of Software, by Richard P. Gabriel where Christopher Alexander himself wrote in the forward, "What was fascinating to me, indeed quite astonishing, was that in Gabriel's essay I found out that a computer scientist, not known to me, and whom I had never met, seemed to understand more about what I had done and was trying to do in my own field than my own colleagues who are architects."
Maybe all computer programmers should learn how to architect?
My thesis advisor was an Alexander protege and put on a bi-annual conference about pattern languages. It was more widely attended by programmers than architects (Ward Cunningham gave a fantastic lecture!) , but as an architect I learned a lot of valuable lessons (about architecture) from the programmers.
Perhaps not coincidentally I think Alexander is one of the most frequently mis-understood (and underrated) architectural theorists of the past century.
tduds I'm curious, since you learned from a protege. From what I've read in his books, and more current analyses of his oeuvre, I think he's got a point about pattern. Why I think he's a crock is that - surprise surprise - he's got them all figured out, and if you don't agree, then you're a terrible architect. I don't buy it.
I actually think the (later published) volume 1 book in the series, The Timeless Way of Building, was better than, A Pattern Language, precisely because it was more of the theory and less of the "all figured out" patterns. But it rarely is even acknowledged by architects who just want the patterns all spelled out.
Don't get me wrong, I also think there is quite a bit of hokey thrown in there ("quality without a name" ... come on, that's the best you can do?) that you have to simply roll with to make it through. Overall, I think he was onto something, but maybe just didn't quite get it refined well enough to be taken seriously by a broader architectural audience.
I think what programmers understood, and what many architects missed, is that the "A" in "A Pattern Language" is the most important word. It's not "The Pattern Language." Most of the architecture world mistook the book as a prescriptive text, rather than a single instantiation of a framework.
Personally I disagree with many (but not all) of Alexander's patterns as a prescriptive tool, and I think a lot of his later writing leaned too hard into his personal preferences instead of the theory that his first books nailed. But I strongly support the framework as a method for organizing abstract priorities into concrete "patterns" than can be applied and checked across scales and phases of a project.
I don't think Alexander is a good architect, I do think he's a good theorist and a brilliant meta-thinker. His great success has been to provide designers with a system of organizing design thinking.
edit: EA I definitely agree The Timeless Way of Building is a better book.
This conversation reminded me of a tweet from a few years ago that is both hilarious and a little too on the nose:
Only learn to code enough to be able to control the Matrix a wee bit. Not so much that you become 'The One'.
Well put.
I think it should be a mandatory part of architecture curriculum. It's the direction that things have been going since 2000. In the design phase of projects, when using Rhino, it's necessary to be able to program grasshopper to meet project objectives. Same with Revit, you need to know Dynamo. To best program in both Grasshopper and Dynamo, you need to know how to program in C# and Python.
I think these are all means to an end, but I wouldn't say they're crucial to architecture overall. All of these technologies are simply tools. In some cases, they're the right tool for the design you want to explore, but in many more cases other tools are more appropriate.
We oversee the construction of about $100M in projects we design, every year. We've never used any of those tools. Never say never, but none of it is actually needed. It's a choice, not unlike crayons or markers.
Yes, but also No...
Waaaay back in the day, I learned Fortran 77 - even though I have avoided becoming a programmer professionally (I've even turned down jobs), I believe learning the "coding" approach to logic was very useful in terms of general cognitive development.
Specific to architecture, on the other hand, if what you really want to do with your life is architecture, beware of becoming a software specialist.
So this topic came up in the office today. Currently working on a large competition 2 million + sq.ft and while I'm manually trying to figure out things on paper and small digital models... in comes some other colleagues (joint-venture) from across the country with shiny coding proposals that, in the end, will get the same results I got. I guess people rather the plastic box under their desks to do the design work.
i learned some coding back when it was called programming
name dropping "recursion" above still provokes an eye-twitch at the thought of mapping out how a variable self-modifies recursiveley
not my cup of tea, but i left it with an appreciation of the strategies
can you code the contractors
to follow your commands?
Coding, in this context, is more used to produce partially/fully automated designs.
well, then isn't grasshopper considered coding?
It's a VPL, yea.
a 1 credit class wouldn't hurt. beyond that it's not essential. you can do more if you want. not saying it's not helpful.
Maybe, but IMO, it should be up to a person. For me, I tried to learn how to code but just failed miserable...it is totally not my thing. TBH, I am also new to design, so probably my opinion does not worth much right now.
Block this user
Are you sure you want to block this user and hide all related comments throughout the site?
Archinect
This is your first comment on Archinect. Your comment will be visible once approved.