[vtange]

I'm a software engineer that went through architecture school and I think you're glorifying architects a bit here.

The only reason why architects have a more gradual path as you describe is because there is a LOT of gatekeeping and feedback on your work is a LOT slower.

To become an architect you have to ideally go through schooling at a specific set of schools and then after that you have years of internships where you are at the mercy of the architect who supervises you. If you end up with a not-so-friendly boss you could end up working years of your youth in an unpaid internship and end up NOT getting any credit. That's years of delay to licensure. After getting enough credit and hours you still to take multiple exams, paying out of your own pocket, to get licensed. And unlike software, aspiring architects cannot spend a weekend or two to build projects on their own to put on a portfolio of work, and problems from anything you design can take months or years to crop up.

And even after all that only a tiny minority of architects end up in firms like SOM (like Google but for architects) and get to work in glamourous projects. The vast majority of architects just work on run-of-the-mill housing (not unlike CRUD apps) where the combination of building codes, the client's budget, zoning and other requirements often prevents you from doing anything too flashy.

The great thing about software really is the fact you have the independence and ability to build and publicize your own stuff whereas in all the other formal professions you can't without oversight.

[starpilot]

> The vast majority of architects just work on run-of-the-mill housing (not unlike CRUD apps) where the combination of building codes, the client's budget, zoning and other requirements often prevents you from doing anything too flashy.

In talking with civil, naval, and mechanical engineers that I know, this type of "crank out another one similar to the last one" work seems to be the norm. I used to be aerospace and thought it was just my company. New part designed, do the same type of analysis and write it up and send it to the FAA, they rubber stamp it. But it's remarkably similar in many fields. The civil guy I know says for every new road/bridge they review it's just the same shit over and over. It's just a white collar assembly line everywhere. It reduces errors and is efficient as a division of labor, but it's not very fun.

[itronitron]

>> "crank out another one similar to the last one"

That's because they can't stand up a micro-service or API to crank those things out.

[Latteland]

that should be your startup idea! "automate that boring civil engineering design with the agi 5000".

[pjmlp]

Same applies to countries where Software/Informatics Engineering is a proper title certified by the Engineering National Council, not a paper title.

http://www.ordemengenheiros.pt/pt/a-ordem/colegios-e-especia...

https://www.anerkennung-in-deutschland.de/html/en/engineerin...

[icebraining]

Can't say I've ever found a job ad in PT that required that title, though. But hey, maybe it'll get some woman to marry us, as their marketing materials imply: https://preview.ibb.co/gRKupq/eng.png

[theoh]

> The great thing about software really is the fact you have the independence and ability to build and publicize your own stuff whereas in all the other formal professions you can't without oversight.

By the same token, software isn't really a professionalized activity: https://en.wikipedia.org/wiki/Software_engineering_professio...

[imgabe]

Agree. I also work in the building industry (Electrical Engineering - power distribution for buildings) and I love software because of the instant feedback loop.

In software, you make a typo and you get an error immediately. You fix it and go on.

In architecture, you make a typo and you hear about it 6 months later, and it's a $200,000 change order (exaggerating...somewhat).

[majormajor]

> In software, you make a typo and you get an error immediately. You fix it and go on.

This level of thing is usually silly, ultimately-meaningless errors. (The rare exception being the metric-vs-imperial type things that literally blow up eventually.)

There are many other errors we make every day building software that lead to years or decades of tech debt. The thing we need to figure out is how to get better at making better up-front decisions on that. Being better at monitoring the long-term feedback produced by our designs, so that instead of saying "we should rewrite this in a new framework" we can say "we should restructure this doing X and Y to prevent these types of problems from coming back."

[toast0]

The costs of making better decisions need to be measured against the costs of making poor decisions. Most (but certainly not all) software is ephemeral. If you knew what would be in use in ten years and what would be in the bit bucket, you might make different choices. If you were liable for your choices and mistakes for years and years after your product shipped, you would examine them closer as well.