Ok, so basically what I can tell from this is that one can pursue programming and architecture simultaneously. That is in itself an ok idea, but I am doubtful about employment. Here it is either one or another. Maybe it is different somewhere in USA or somewhere.
If you get free education in programming, and think it'll get you a job, then it seems like a good idea. What I'm trying to say is don't limit yourself thinking it's an either-or situation. Interdisciplinarity is on the rise, even if the market for it doesn't exist in your country... yet. In a world of intense competition, a rare combination of skills is what separates you from the crowd and makes you valuable. If you have two passions, why not do them both? Why not create
About computational/algorithmic design: I get a kind of thought that it is a trendy theme for an academic thesis in university, but not in real business, well, not unless you are not Zaha Haidid (but my knowledge is limited, I now somewhat well what's going on in my area, not so well around the globe, well not in the industry, at least).
These things in the present are just beginning to be explored, largely, yes, as academic BS and marketing gimmicks like Zaha (IMO shit). But that's not what I'm talking about. They're making utopian stuff, capricious stuff, that just happened to be made in computers. They've barely begun to scratch the surface. The fundamental thing is that it's not about how it looks
, but how it was made. It's about the process
and the system
of architecture, not the objects themselves.
Modern Architecture revelled in the discovery of new materials and the cheapness brought about by the first industrial revolution. The computation/information revolution has yet to have its most significant impact: currently you use computers to represent
, to make what you would on paper and models, on a screen. But the designs are still conceived in the same way as before computers. The computer is not yet
a real design tool, merely a glorified pencil. It computes perspectives so you don't have to draw them by hand, it computes vector graphics, and model super complicated curvy stuff. But it does not really help to shift the paradigm of the design process: to compute and coordinate the numerous and complex parameters that give buildings performative shape; to make explicit, and scientifically investigated and documented, the recurrent patterns that make good, efficient design
that are currently a matter of pseudoscience and personal intuitions developed by decades of practice codified into half-baked concepts in unintelligible books, if codified at all.
The real business, and thus real inevitability of the revolution that computation will bring forth is that the robotization and the actual leveraging of simulation tools and scientific understanding of buildings and how people use them can and will lead to significant cost reductions to construction and operation ("sustainable" they call it) even on seemingly very complex projects; more efficient structures, more pleasant, buildings entirely simulated for their resource performance, easier and faster to design as well as construct, and perhaps de-construct. And the data generated by intelligent buildings can be used for so many things, one could build simple smartphone apps, or giant city-level systems (like IBM is trying to do). And the people with the money love
to get more with less.
What I'm trying to say is not that you must do any of these things, in particular, but that you have to be very aware that the fields of Architecture and Programming are barely just beginning to collide, and there will be a vast array of opportunities in both in the not too distant future, so you should not limit your vision to the present state of things.
Also, I'm planning on making an essay/presentation on the future of Architecture, so I'm using this opportunity to rant/draft some arguments, so I'm sorry if this is a bit tl;dr
I agree on the majority of what you say, I am aware of such things. My comment was largely rhetorical: you were painting a very rosy, very narrow view of a very broad field. It seemed grossly unbalanced.
I concede the point on budget, partly. I was taking a perspective not from being an employee focused only on software development on some big company, but more of a startup mentality, involving hardware and other business stuff...
Hardware (perhaps this is not the proper term of what I had in mind) limitations still exist though, if you're working on squeezing everything out of small devices of, well... limited
capacities. Granted that miniaturisation, Moore's law, etc has significantly reduced the problem, but it does remain in certain contexts.
What's the limitation? Managers are investors, they want you to maximize the value of your time, don't you want that too? Of course bad bosses are a limitation, but why would you work for one of those?
Indeed. But not everyone has the luxury of choice.
Clients don't control us, we control them with the power of software. There's the point, we don't call them clients, they're customers or users.
You're again taking a very narrow view from your own situation, which might be an ideal
one, but not necessarily the most common one
Curiously, in Spanish there is no distinction between "client" and "customer", there is just the word "client" (as far as I know). I'm not exactly sure what's the difference here, the subtle nuance. Is a client someone who seeks a service (and thus has a set of demands) vs a customer who seeks a product (that is accepted mostly as you offer it)? Am I making any sense?
That's not a limitation. There are three legs to the project stool; resources (people), features and deadline. Most of the time you can pick two, usually it's deadline and people. Therefore features is scoped to fit those two thereby removing it from the picture.
Precisely... time variable exists as a constraint, considering the whole project on a higher level.
Is it ok if I replace "limitations" with "factors", "variables", "constraints", "considerations"?
business will of course try to tailor their human and other resources, their time, and the required features to have it all operating smoothly. That is again an ideal
scenario. What happens if the development process of X feature gets stuck, and can't advance no matter the human resources you throw at it, and how much you planned for such things?
I don't believe in gods, but I'm pretty sure deadlines are a universal reality, and if there's a law that unifies our understanding of it, it's quite likely to be Murphy's and Hofstadter's...
my core point is that it's all up to you. There are millions of good jobs available, or you can invent your own, the only limitation being yourself.
I can agree on this point absolutely. Wether that is what your first post communicated is a different matter altogether, though I'm not interested in discussing that further