I'm married to an Architect, it bugs them too.
In most states - Legally they can't call themselves Architects until they've passed the AREs. You can't take the AREs until you have enough IDP hours (which takes about 3 years). You can't start IDP unless you have a Masters (or more recently a "professional bachelors"). Oh, and you have to take a new test for every state / country you want to practice Architecture in (Reciprocity is getting better but not quickly)
So it's that sense that they have to scratch and claw to get the title where we can just sort of make it up that bugs them.
I think we should switch to a different title scheme. I'm going to be a Doctor of Site Reliability (you know since I'm already doing operations....)
I do however wish that people were better able to make the distinction between titling oneself 'software architect' and claiming to be a sub-type of architect. Perhaps it's too subtle. What I mean is, 'software engineer' and 'software architect' are singular roles, peculiar to this industry, that happen to be made of two words.
See my other comment for details: https://news.ycombinator.com/item?id=16835964
Ironic, considering that college engineering courses are about 95% math.
I'm also fine with 'software developer' especially as we've largely moved away from programming computers, and at best most of us are programming abstract machines that bear decreasing resemblance to computers.
Consider a fuel injection system from the 1960's. It was a mechanical computer. Was that not engineering? It was certainly designed by a team of engineers.
These days, it's software that does the same thing. Why is that not engineering?
In order to discuss categories at all, you have to place some limit on how far to stretch the equivalence of different things. Sure, a physical thing is transformable to a logical thing, but doesn't that affect our categories? We're pretty bad at finding or agreeing on the lines between the categories we create, so I don't worry about that much.
I didn't say that programming is never anything like engineering. I apply engineering-inspired approaches to my work all the time. But here's another perhaps eccentric opinion: when I'm thinking like an engineer, it's usually to compensate for the code being too complicated to read. I consider that a pragmatic response to a worrying failure, not something to aspire to more of.
You betcha. Think of how Woz designed a floppy disk controller that used fewer parts than other designs. That's engineering the logic.
A big part of software engineering is to engineer the logic to get the correct result as fast as possible.
Engineering is all about working within a set of constraints. Things that are easier and/or cheaper to manufacture, have clearly been engineered that way.
It can't be a coincidence that we consider CPU time and memory footprint "costs".
I definitely see where you are coming from re: 'engineering' logic. As I said before, I don't have a huge argument against this. However, for me this is where the metaphor blurs into near-meaninglessness for me. Optimization happens to be a specialization of mine, and I can't find a reason to think of it as engineering, except for the fact that I take measurements. The optimization itself is more like applied information theory. I can agree that the measurement + iteration is perhaps engineering.
This title sometimes accompanies pretension toward traditional engineering, which is fine as far as it goes - usually not very far. I realize that there are some efforts in some jurisdictions to get something like engineering credentials for programmers. Ok, maybe that's not misguided, but I've yet to be convinced. It depends on how you conceptualize software. I don't think of it like engineering, I think of it like math. But more than that, I think of it as computer programming! If you think of it like engineering, I don't have a huge argument with that, but I have a hard time seeing is as more than an ill-fitting metaphor. I think that is one step better than the manufacturing metaphor.