Reply to post:

"All you have to do is look at Glassdoor and see that developers make more money than system administrators on average."

Depends. Glassdoor breaks up "systems administrators" into the various subspecialities pretty granularly. Network admins, storage admins, etc make rather a lot, and it really depends on where you live. Devs in Canada, for example, don't make a lot...but they do in the valley. (Where glassdoor is most popular.)

"Most of the interesting work, and the glory, is in designing and engineering something new, i.e., being a developer."

And? You're talking about what motivates you, personally. Not what is delivering value to a company and to the end customer.

"but I guess you would be the elevator repairman because in your comically warped world view, that guy is somehow more important and better paid and everybody else is a bunch of idiots."

Actually, because it's a maintenance specialty, "elevator repairpeople" are usually quite well paid. But they are narrowly focused specialists, so I wouldn't think that they are knowledgeable about how to manage and maintain an entire building. managing and maintaining a building would be the job of utilities/facilities staffs.

And oh, yes, I don't for a fraction of a second think that most architects know how to maintain buildings. That's why architects are supported by teams of engineers who are in turn supported by teams of drafters and other ancillary staffs.

Architects and proper Iron Ring engineers are a great example of regulated professions in which there are massive legal incentives to think of every little thing. Fuck up and you lose your license to practice. You may even go to jail.

This doesn't exist for developers. If developers fuck up, the sysadmin gets yelled at when things fail. Developers aren't held to the sorts of standards that proper engineers, architects and so forth must meet. There is nothing mandating professional ethics or regulating responsibility within the industry.

The architect takes feedback from a massive team of people and runs simulation after simulation and discusses every aspect of everything with specialists. Including - low and behold - facilities specialists who can inform the architect about maintenance challenges they haven't thought of.

A modern architect working under legal regulation isn't a good analogue for a developer. They're an analogue for a certified project managed leading a unified SecDevOps team.

Developers tend to exist in a vaccum. In some cases - like developing your own piece of scientific software where only your own fingers will ever be in the soup - that is passably acceptable. In most cases, however, it's not.

"In the large companies I've worked at, everybody out of college with a computer science/engineering degree tries to interview for a developer position."

That's because computer science is about teaching you how to program. It isn't about teaching systems administration.

"The ones who fail both interviews but still seem fairly knowledgable about computers get put into system administration. It's always their last choice, it pays the least, and it means they already failed two interviews for things they'd rather be doing. You can decide what to take away from this information."

Well, yes, it would be their last choice because they're accepting a job they didn't train for. Probably at the lowest possible rank and the most substandard pay. I sure as hell wouldn't pay a computer science graduate even half of what I'd pay a properly trained systems administrator produced by my local polytechnic.

I can take a trained sysadmin cranked out of an actual systems administration program at a polytechnic and let them lose on the network after only a week or two of orientation. It would take me months just to deprogram a computer science graduate, let alone train them in what they need to know!

Now, that said, if I can deprogram a computer science graduate and train them up as a proper sysadmin - that takes about two to two and a half years - then what I've got is a DevOps specialist. They're trained as a developer and they've learned to think in risk assessment and operational terms. That is valuable.

Take that same person and teach them security and 5 years after they've landed in the department they'll be SecDevOps and probably the highest paid non-executive in the whole company. They'll also easily be the most valuable member of the IT team.

But you see, there's the key. The ability to think holistically. To run a team, and solicit input about all the moving parts before architecting one's datacenter. It's knowing enough to know what you don't know, then finding specialists to provide feedback to fill the gaps. It's thinking in terms of "what can go wrong" instead of simply "how can I solve this".

If any of this sounds familiar you might worked on mainframes. That specific subclass of developer who works on mainframes tends to have to work like this. They can't simply reboot every time something goes squirrely. They have to play nice with everything else. And any outage not only is going to cost millions, it may well cost lives.

There aren't a hell of a lot of those folks left. In today's world, it's the SecDevOps guys who are taking up the mantle. In a lot of ways, they have it harder, because they have networking and security issues to consider that a lot of the mainframe devs never had to worry about.

The best designed building in the world is worth nothing if it can't be inhabited. And no building can be inhabited unless it was designed from the start to be maintainable and is actually properly maintained. Over time, even the best designed building in the world will need to evolve. Telephone jacks will give way to RJ-45, which will give way to fibre. Power will be upgraded. Asbestos will be found to be a bad building material and need to be removed.

Architects don't solve those problems. Facilities staffs do.

What an architect - a good architect - does is make sure that the building can be evolved over time. That it's service life is longer than the technologies of which it is composed. A good architect listens to input from dozens of specialties and the result is a building that can have a useful service life that lasts centuries.

There is mainframe code out there has has persisted for decades. It will persist for decades to come.

Embedded devices exist all over this planet. Billions of them, growing at a rate of tens of billions of devices a year. Will they last decades? Will this "internet of things" be secure, hardened, capable of withstanding the evolution of IT over the life of the devices involved? Or will cars and microwaves and toasters move from decades of service life to years, not because of mechanical failure, but because of bad code?

Will the rock star snowflake developers of today, who believe in their own importance and that they know best architect applications that serve as monuments and withstand the test of time, or will they need to be managed, maintained, defended and ultimately discarded?

How long will your code last?