I've work with many of them, very good about Adobe products and Apple last thing, but clueless about, why their final code is of poor quality.

Fortunately, many of them did get their Ego down, when the web did start to move from markup (html+css) to code (js). Until then, they did take any feedback from a sysadmin, as an attack to their work.

About developers and architects... they should simply be the final support (24/7 calls included) for their work and changes.

As a side note... a sysadmin IS A developer (a systems developer). An application developer, usually should be a systems developer if he/she is working in a project that includes a platform to run (unless he/she is just uploading an app to any appstore). An operator with limited privileges, is just that. The concept of "pure developer" or "pure sysadmin" is so 199x...

This is why Ilya Grigorik's book, High Performance Browser Networking, exists. It's a great reference to that end as well.

But then you need to understand the differences between HTTP 1.1 and 2.0 and how it handles multiple requests from the same page. 1.1, you would probably be better off with a single concatenated file, 2.0, perhaps several. And then what about compression? Any good UI developer should be considering compression of that file, cache control, etc.

I see too many front end developers shy away from this stuff and create bloated monstrosities. They feel it's someone else's job... but if not the UI developer, then who??

This stuff does get pretty complicated. Mainly because the tech is evolving fast (browsers do a lot of tricks now). Even in HTTP 1.1, there are times where multiple files might be more interesting due to how large files are handled

Well, indeed, the higher level protocols, like HTTP, DNS, etc, are more useful on a daily basis.

How you get there is up to you. My own path was freakishly meandering. Don't be afraid to get out of your depth, but try to have a mentor around to stop you drowning.

And remember that DevOps is a mindset, not a job. If someone tries to setup a "devops team", run away.

Same here, though I was aided by being able to be really confident about stuff when people came calling with the checkbook and a quick study once I'd landed a gig. I learned to do what we would now call "sysadmin stuff" (manual administration of hardware) as a kid because I broke my Linux machines a lot. Then I went into the web development gristmill for a while. Ended up leading a multi-platform mobile team with zero mobile experience because "you're a good developer, you'll pick it up" (I did); I literally went into a devops role knowing no Ruby (to say nothing of Chef) under pretty much the same rationale.

"Fake it till you make it" is real, but then you gotta make it. ;)

Therein lies the best career advice I could possibly dispense: just DO things. Chase after the things that interest you and make you happy. Stop acting like you have a set path, because you don't. No one does. You shouldn't be trying to check off the boxes of life; they aren't real and they were created by other people, not you. There is no explicit path I'm following, and I'm not walking in anyone else's footsteps. I'm making it up as I go. - Charlie Hoehn

I've worked with developers who fully understand the systems they are deploying on, and developers who develop for an abstraction of services rather than a real world environment - I tend to prefer the former to the later because the deployment process is much less taxing, even though the later tend to have better luck moving their software to another platform in the future.

But I'll echo you, every time I've learned something hard, it's because I got way out of my depth and had to learn how to swim all over again.

I think this is kind of a given, today. I don't know many healthy, growing organizations for whom their "sysadmins" are not either originally developers or proficient in writing at least domain-specific code (I have always said that I am a software developer whose output is systems rather than web apps, because it's true; right now, with my current projects, I just wear both hats and get on with it!). Even the term "sysadmin" has largely disappeared in my neck of the woods; it has been largely replaced with "SRE" or similar, but that sort of position invariably seems to have development connotations.

I suspect I'd have a hard time finding employment doing the kind of work I'd want to do at the kind of salary I'd expect to earn. I'm a decent programmer with broad but rarely deep experience, a better than average sysadmin with ridiculously broad experience, a passable designer (better than half of the "real", but merely average, designers I've worked with over the years, but so far behind the good ones that I'm hesitant to use the same term to describe what I do when I build websites), a passable sales person, a pretty good writer and copy editor, and the list goes on and on, because I've run my own companies for the past 17 years. I've touched everything that a business has to do, and I've somehow muddled through and kept the bills paid and the customers coming back.

But, I'm not a "rock star" at any particular task. I couldn't wow anyone with my algorithms knowledge, though I've always figured out how to solve the problems I needed to solve. That's not a very compelling sales pitch when talking about a $100k+/year job for a company that has a specialist in all of the above-mentioned roles.

So, I think it really depends on what you want out of life. If you want to maximize security and income, focus on a high value skill. Become the best in your market, or as close to it as you can manage. Eschew all distractions from that skill; don't fuck around with weird Linux distros, figuring out how DNSSEC works, building your own mail server, setting up CI, self-hosting all of your own services and web apps, or otherwise becoming a "jack of all trades, master of none". If, on the other hand, all of those distractions sound like the best reason to be in tech (and, that's the way it's always added up for me, even when it's cost me time and money), and you're willing to take on a lot more risk building your own business (whether consulting or building products), I guess being a jack of all trades isn't so bad.

But, and this is a big but: There's only so many hours in the day, and so many productive days in your life (and you also have to take time away from productivity to have a life outside of work/tech). As I get older I realize more and more that I have probably valued my time less than I should and valued my ability to effectively DIY my way to success too highly. I've spent many hours fucking around with stuff that I could have paid someone a few (or a few hundred, or a few thousand) bucks to make the problem go away, and it would have been worth it in a lot of those cases.

If you aggregate all of the "Every developer should know X" posts and blogs, the list would probably be very long. It only promotes shallow signaling instead of actual competence (I only need to know enough about X to make people think I know about X).

Meanwhile, your salary will still only compensate you for one skill set: software development.

Devs will slowly learn the relevant knowledge anyway, just at a slower pace than the immediate needs. And yes, after a certain number of years, that dev could be good at both. But you can't only hire devs good in both places for every position at every company.

I see no harm in one having basic experience in multiple fields. Especially when those fields are related. Actually, this concept I kind of "market" it among my circles. A mobile developer should know the basics of web development and vice versa. That way they communicate better.

I claim that already happens naturally. It's our drive to quickly build a niche (e.g. "I'm a professional X developer"), in addition to insecurities that lead to saying "X is not my responsibility", is what gets in the way of expanding our fields of expertise.

That would be mostly Python these days. If someone here would touch Perl on my systems, they're gonna have a very bad day. Sure I wrote stuff in Perl back in the days, but those days are over.

I see this as Perl's problem: to be good enough at Perl, you'd have to frequently use it, but Perl is in my eyes only suitable for quick hacky run-once scripts - which should not be written frequently, so you shouldn't be good at Perl. My Perl is pretty damn rusty these days.

If someone is still writing large scripts/apps in Perl these days, I question their judgement in technologies and ability to keep up with the times. Sure you can write larger scripts in Perl - but what's the point? You have to take care not to make things unreadable, while when using something like Python, it's much harder to make a script that's unreadable.

Yes. Where I work, they're all expected to be able to cut code. They might pair with devs at various stages, but a sysadmin who can't write code isn't going to be able to work with some of the more modern frameworks for orchestrations because they are in essence DSLs: they _are_ code.

> Plan an invasion

This is actually a massive undertaking. An undergraduate at MIT taking a semester-long course on this will barely scratch the surface of it. Furthermore, you're never going to suddenly and unexpectedly need to know this. Any situation where you plan an invasion is going to be preceded by spending a long time getting into the position where people trust you with their lives and the fates of their nation.

> die gallantly

You're only ever going to be in this situation once, and probably not even that. Why does it matter how gallant your heart attack is?

These skills make a bit more sense in a world where most of us need to march off to war. Happily, we don't live in that world.

You should prepare for the situations you are only mildly unlikely to be in and where your skill matters.

Depends how old you are.. some historians are keen to point out that the global climate is very similar to the conditions just before WW1. Will you be of conscription age if WW3 does break out in the next decade?

> You're only ever going to be in this situation once, and probably not even that. Why does it matter how gallant your heart attack is?

I think doesn't exactly refer to the act of dying, but is more along the lines of "The object of war is not to die for your country but to make the other bastard die for his." So don't exactly want to die; rather, you want to avoid it, but should it happen, you just want to make it very expensive.

But of course, it could also have nothing to do with war; it could be about how you face death, and how much of a burden you leave to your loved ones. (E.g. don't commit suicide leaving a note that tries to shift the blame to your family, or whatever).

May be. Not only you understand better the needs of software developers. But also, you are able to automate a large chunk of your work. Paraphrasing Larry Wall: Sysadmins should be Lazy. "Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. ..."