I had exactly the same experience at a previous employer, almost word-for-word.

Having said that, the central assertion is still correct: the absolute best developers I've ever worked with were also top-tier sysadmins (or linux experts, depending on what you want to call it).

AMEN!!! In my current job, I am wearing both hats, and while I like that there is a certain variety in my work, users calling for help is highly disruptive when programming or doing some other stuff that requires deep focus.

The upside that in a three-person IT department there is very little bureaucracy to fight, just the odd "organically grown" legacy system.

As an aside, did you know that the word "Amen" actually is a acronym in the Jewish language that means "El melekh neʾeman" (or AMN) which translates to "God, trustworthy King". (source: https://en.wikipedia.org/wiki/Amen)

I figured the etymology of that word was rather interesting. But yeah, I get the whole SysAd/Dev dual job. They're tough to balance and do effectively. SysAds are firefighters. When the nag(ios) alarm rings, we come a-callin.

From that Wikipedia same article, it says

The Talmud teaches homiletically that the word amen is an acronym

The etymology section shows the word has much more prosaic roots. The Talmudic acronym seems to rather be an interesting backronym.

> As an aside, did you know that the word "Amen" actually is a acronym in the Jewish language that means "El melekh neʾeman" (or AMN) which translates to "God, trustworthy King". (source: https://en.wikipedia.org/wiki/Amen)

I did not know that. ;-) Thanks!

The fact is that nobody really knows. Talmud was written in ~200 BC and is an exegesis. Egypt is the elephant in the room of Hebraic history. It is possible it is an Egyptian loan word just like Moses -- "born" from water -- is an Egyptian name.

I've been in this situation for a long time; The worst part is every so often you get assigned a PM who wants you to accept responsibility for meeting artificial development deadlines.

Developers IMO benefit greatly from having the general engineering experience. This helps understand how the part they build fits in a full product, where the narrow spots are, what is likely to break first, where formal documentation is insufficient / contradictory / wrong, etc.

Sysadmins, who often manage crises, acquire this experience way or another (e.g, by researching options to fit a square peg in a round hole without leaks), so developers with sysadmin experience tend to all have it. I think though that the key part is the "engineer" part and it can be acquired and used without sysadmin-imposed hassles (interrupts, crises, being underappreciated).

The two hats don't fit well at the same time; 27 years of both has not been easy, but the experience of wearing each regularly is invaluable.

that's a great point about the types of schedules for each discipline.