[crimsonalucard]

Architecture is way easier than algorithms. I'm actually the opposite. I hate the idea that people are studying intensely for architecture because it just takes reading the wikipedia summary to get the main point.

Architects are usually just managers who are ex-engineers and have been out of the front lines for so long that they aren't technical enough to get back into coding. This is fine, but the idea that "architecture" is some kind of talent is absurd. Anyone can study a blog article about the latest architecture buzzword and understand the concepts front to back. Not to mention that the more physical nature of architecture makes it less flexible than code itself so "architectural" patterns are, as a result, significantly less abstract and complex than coding patterns/algorithms.

The true difference in ability is measured by who can actually Build an architecture, and usually its developers who build it, while architects (mostly) just talk about it.

[scarface74]

Not to mention that the more physical nature of architecture makes it less flexible than code itself so "architectural" patterns are, as a result, significantly less abstract and complex than coding patterns/algorithms.

This is the reason that software engineers need adult supervision. The fact that you think that modern infrastructure is physical and static displays a lack of experience. There is nothing static about modern cloud infrastructure.

I just had to deploy an API to ECS/Fargate (Docker). We had to determine the best combination of memory/cpu of the Fargate runtime environment and what hardware we wanted to give the ElasticSearch environment. I basically wrote a CloudFormation template (infrastructure as code) that defined the environment and then wrote a Node script that ran the CF template and passed in parameters to vary the hardware environment (cpu/memory). After the environment was created, the script then ran a series of Artillery load tests, recorded the results of the load tests, gathered metrics from CloudWatch and estimated the monthly cost compared to the performance.

We reported that to management to let them decide how much they were willing to spend for the throughout they needed.

I’ve created entire environments with databases, Redis Caches, ECS clusters (think AWS version of EKS), etc as a proof of concept by using CloudFormation deploying code to it, showing management as a demo, and then tearing it all down just by clicking delete until we can come back to it after the contract is signed and then spin it back up with one command.

[crimsonalucard]

>This is the reason that software engineers need adult supervision. The fact that you think that modern infrastructure is physical and static displays a lack of experience. There is nothing static about modern cloud infrastructure.

Note how I said "more physical nature," meaning that it's closer to physical but not completely physical. Either way, all abstractions suffer from leakage from the physical world. Data and processes, while seemingly abstract all occupy physical and temporal space and this fact leaks to all layers of the stack. Thus, technically, everything in the universe including computation is physical and nothing is ever purely a virtual entity.

Honestly, you think I don't know about docker? You think I don't know about the cloud? "Infrastructure as code" oooh buzzwords, you're just using a shittier domain specific language to write something that you can also do with Regular code (such as python, no buzzwords needed).

Give me a break, what web developer doesn't know about the above stuff? None.

>I just had to deploy an API to ECS/Fargate (Docker). We had to determine the best combination of memory/cpu of the Fargate runtime environment and what hardware we wanted to give the ElasticSearch environment. I basically wrote a CloudFormation template (infrastructure as code) that defined the environment and then wrote a Node script that ran the CF template and passed in parameters...................

OK, the stuff you did isn't even usually what a "architect" does. It's devops. An architect just diagrams the boxes and lines and gives it to the devops guy to spit out working infrastructure or a POC. But that's besides the point...

Can you write your own programming language? Can you write your own database? Can you write your own Operating System? These are actual specialties (none of which involve "architecture"), not some garbage made up specialty like "architect." At the very least, if you want to be part of an actual specialty in the IT world you need to build shit and that shit needs to be HARD to build, you can't just do some easy diagraming of a bunch of stuff while acting like you have some superior understanding of the latest architecture pattern you can look up on wikipedia.

[perfectspiral]

>Honestly, you think I don't know about docker? You think I don't know about the cloud? "Infrastructure as code" oooh buzzwords, you're just using a shittier domain specific language to write something that you can also do with Regular code (such as python, no buzzwords needed).

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

[idoby]

Well, using general Turing-complete code languages for infra and config vs specialized templates/languages is a legit point of contention in the industry right now, although judging by the style, GP isn't considering the pros and cons of each approach, which include:

* Forcing users to learn a specialized language vs reusing knowledge of a general purpose language

* Inevitable Turing-completeness creep and increasing complexity in specialized languages

* Complexity and difficulty of reasoning about general purpose code (and analyzability)

So GP does have a point. He/she is just not making it very well, I think.

[crimsonalucard]

The tradeoffs you mention are obvious right? I'm just sort of downplaying the huge bragging Scarface was doing when he mentioned he did some cloud formation and "infrastructure as code" because it's really not that impressive.

It's obvious that the logical consequence of using Turing complete languages for devops introduce a lot of complexity into infrastructure and can introduce configuration that executes continuously as well. Bugs that only existed in the application layer now creep into infrastructure. Infinite recursion can now be spinning up infinite instances.

That being said the devops thing was a side detail and that's besides the point. The point is that the role 'software architect' is useless.

[idoby]

Obvious? No, and even less straightforward. Personally I think it's a good thing both kinds of tools exist, because each dev/team/project has different needs and different sensibilities.

Personally, I prefer my configuration to be written in a plain-old language (e.g. Python) instead of a specialized config language (be it YAML or JSON based or whatever). I can test that code, I can reason about it, I can review it for bad stuff like infinite loops (not perfectly, but still), I know how it behaves when diffed and merged, etc.

Regarding software architects: I've seen a few companies where architects are hands-off demigods who prescribe complete architectures without ever having to contend with the results of their decisions. Those companies are, in my experience, few, and tend not to do well.

In a lot of other companies, the role of an architect is very similar to what Herr Scarface describes - individuals with a lot of experience who can make broad decisions based on both experience and data, and leave it to lower ranking engineers to work out the exact details. They do the hard/open-ended stuff and come to conclusions about the broad strokes (e.g. "yeah Redis will work well for this problem, but since you have denormalized data you might need a background process to restore consistency"). This is often called "scoping" and it is the main responsibility and impact of higher-ranking engineers (whether they're called "architects" or not, I personally dislike the term).

[scarface74]

While I agree the pendulum goes both ways - for instance a AWS’s CDK builds templates using your language of choice. How can someone know the tradeoffs without a breadth of experience who thinks they can learn everything they need to know from Wikipedia? “There is no compression algorithm for experience.”

[crimsonalucard]

You don't even know how much experience I have. I'm saying architecture patterns can be learned from Wikipedia not 'everything'.

A devops configuration language (outside the domain of architecture) is not included in this category. Please don't be manipulative and please do not lie.

[crimsonalucard]

Let's stay on topic rather than make passive aggressive comments on my intelligence.

You're implying that my comments are stupid and arrogant. Prove it if you can, let's get to the bottom of whether or not "architects" is a worthless specialty or not. I think you know I'm right and the only thing you have left are personal comments on my intelligence.

[scarface74]

Honestly, I also had a long reply but I thought why bother? You haven’t gotten past the first step to knowing what you don’t know.

We all thought we were the smartest people in the room at one point, you’ll grow out of it too one day.

[crimsonalucard]

>We all thought we were the smartest people in the room at one point, you’ll grow out of it too one day.

Again with the insults.

Why bother? Because you can learn and I can learn. I don't come here to trade insults. I come here to lay down the actual reality of what I see unimpeded by social norms. Yeah I'm sure I touched nerve here, but it's nothing personal, the internet allows me to talk about truths that are uncomfortable and forces me to face those truths as well.

I've been proven wrong tons of times on HN, so I'm hoping that if you disagree, you can prove me wrong and I can learn something and I'll return the favor in turn if you're the one that's actually wrong.

I find that this isn't the case with most people, they don't want to face reality. The fact that you turn to personal insults and have this whole "why bother" attitude seems to me as a cover. You don't bother because you got absolutely Nothing to offer.

[cle]

Where I work, architects are responsible for disambiguating requirements and breaking down the implementation across teams into achievable milestones. It’s the intersection of technical chops and social skills. One of those is a lot easier to develop than the other.

A good architect makes it seem like their job is easy, but there’s nothing easy about taking a vague idea and leading a huge cross-team effort to solve it.

[crimsonalucard]

>Where I work, architects are responsible for disambiguating requirements and breaking down the implementation across teams into achievable milestones. It’s the intersection of technical chops and social skills. One of those is a lot easier to develop than the other.

Good thing we're on the internet where we can talk about the actual reality and lay everything out as it is without worrying about the social and political bureaucracy that infests corporate culture.

That being said, isn't what you described the role of the tech lead or manager? The best tech lead ultimately derives technical architecture by aggregating the expertise of the team and puts that plan into motion exactly as you said.

The term "architect" usually implies greater knowledge of "architecture" where the "architect" uses this "greater knowledge" to lay down a high level plan of the infrastructure. Additionally your initial post implied that this is what you think, because this is what you study for interviews.

Like I said, usually the architecture role is actually ends up in practice becoming an ex-engineer manager. That's the only actual role they can fit while maintaining the respect of the engineers and without being completely useless. This is basically what you described about yourself.

[scarface74]

Additionally your initial post implied that this is what you think, because this is what you study for interviews.

Thousands of people study about how to reverse a binary tree on a whiteboard and other needless leetCode to “work at a FAANG” even though they don’t do that everyday.

What you study for an interview is unfortunately often only vaguely correlated with what you do on a job.

[crimsonalucard]

>What you study for an interview is unfortunately often only vaguely correlated with what you do on a job.

Agreed 100%. Interviewing is hard. I would argue though that interviewing for "architecture" causes another issue. To give an analogy... it's like studying english for a programming job because english is used all the time on the job.

Architecture is just too easy and too obvious and if you just happen to not know a specific architecture or way of speeding something up, all you have to do is read about it on the internet like looking up vocabulary on a dictionary.

I would also argue that google isn't exactly just testing algorithmic skills in an interview. The spiritual goal of the interview is that the question they give you is novel and one you haven't seen before. The overall purpose of novel questions is to measure your raw intelligence.

The question isn't whether or not you know how to reverse a binary tree but whether or not from a state of not knowing how to do it, can you creatively come up with a way to do it in an hour? Raw IQ.

Of course the practice doesn't always match up with the ideal and often times interviewees can get lucky.

I'm not saying that this is the best way to interview. I'm saying that judging an interview based off of architecture is even worse. It's even easier and there's a lot of room for bullshit in a conversational interview as opposed to a technical question.

[scarface74]

Pro tip: anytime you think something is easy, be concerned. You haven’t learned it at the depth that you think you have. Keep living....

[crimsonalucard]

Pro tip: this applies to you to buddy, you don't even know my background so you don't even know which field I have a PhD in or how much older I am than you.