I've thought for a while that sysadmin, operator, "devops engineer" and sre were all more or less the same job, but always felt like saying it would be silly of me.
Well, how sad. I have liked what Jakob wrote quite a bit but not only does this article betray a lack of self awareness as it describes quite a few of his own posts—not that there's anything wrong with that as he has published truly insightful things too and the fluff I still liked for the positivity—but then he used an essay by PG as an example of this.
And now I'm not one of those people who think that everything PG writes is gold, but it's hardly "insight porn". In fact, if that particular essay is "advice", it's the advice to not even try as it's likely just not for you, so it almost seems like Greenfeld misrepresented it just because of a single sentence.
I have been a developer for eight years and yet I still get shocked about the places where Python will be used. I mean, it is my favorite language, but in the communities I gravitate towards (basically communities like HN) it has so many detractors for being dynamically typed, not being functional enough, being slow, etc, that sometimes I'm tempted to think maybe it's actually a guilty pleasure of mine, and that I should look for better pastures.
Then I read articles like this and I remember why I like it: it gets the job done, and quickly (for the developers at least). It's why it's so widely used and keeps climbing. Of course, nothing wrong with learning other languages and I do try to keep up, but Python will remain my go-to for the time being.
People who make complaints like that are privileging their own personal aesthetics over pragmatism.
Same mistake as the people who keep talking about perl being "dead" while they're deploying their production platforms on debian or red hat based systems and ignoring the fact that the packaging and release QA work for those distros is substantially dependent on - actively maintained by the distros in question - perl projects.
Sounds like someone else is putting their personal aesthetics over pragmatism. Perl is a dead language walking, the fact that there are some tools it hasn't been worth rewriting doesn't contradict that.
I'm talking about actively chosen new development because it's still the dynamic language most oriented towards being comfortable as part of a unix environment rather than simply running on top of one.
Modern async/await + heavily OO based perl is not, I suspect, the language that you're thinking of when you made your comment.
While I believe there's value in the mentality that "you don't know what you're building until you're building it", I also agree with a lot of this, as long as it means more asynchronous communication anyhow. The write-up itself was a bit focused on if it all happened in meetings, but a lot of this could also be accomplished over email or collaborative editing, RFCs, etc.
But back to the idea of many applications being emergent and/or not at all (or not entirely) what their creators intended. Maybe there's room for both approaches depending on the situation.
I wish I were this creative; I've mostly bought domains that are variations of my name/last name, and the only one I haven't let die is my usual username luord.com
I've seen the problems of treating containers as houses, primarily during development: Multiple different processes inside a single container, with a wrapper around them (inside the container) that makes it even more difficult to debug.
So, assuming I understood correctly, treating them like tents is infinitely the better choice.
In the future, I'll just link to this piece.