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.
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.
I removed all recruiters and similar, leaving only people I know and (mostly) other engineers... And even then I basically only check the notifications anyhow.
So I consider myself fortunate; by not taking LinkedIn that seriously, I've avoided a lot of... awkwardness, to put it nicely.
In that case then the service will just hang as it won't handle the requests caused by even a simple malfunction (not even an actual attack) like the one mentioned by GP.
Mind you, I see your point and I generally don't like the captchas either, but it is definitely a trade-off and I won't blame webmasters that use the DDoS protection.
I agree but with one caveat: If the difficult to integrate tool/library is open source, then one probably shouldn't ask likely already overworked maintainers for even more work. In those cases, one should probably be the change one wants to see by contributing the features, refactoring or documentation needed to ease integration.
The way I see it is that Linus already left his mark in history twice over (so far). I don't know how he feels about it[1], but if I were given the choice between being a billionaire and being remembered for a great thing I did, I'd certainly pick the second.
And sure, many people have achieved both, but they didn't take their money with them once they were gone. As long as you have enough to live comfortably, everything else is at most an incidental bonus IMO.
[1]: Though I haven't heard anything suggesting he's anything but pretty okay with his lot in life.
This presents a strong case, IMO. And taking in account that studies have been made suggesting that language choice has little to no correlation with number of bugs[1], it would make sense that recency bias plays a part in, well, preference in technologies.
I'm interested in the outliers though: Both the ones among the loved brownfield languages, and the ones present in both loved and dreaded lists. I feel like programming language designers, people in charge of choosing the stack for new projects, and people considering renovating legacy codebases can learn a lot about what to do and what not to do from those.
[1]: Though that one ended up in a flame-war, like discussion on programming languages tend to do. Apparently not even academia is safe.
htmx by itself is so good—when paired with discipline in the backend in creating proper fragments anyway—that so far I haven't needed hyperscript. But then again, htmx is so good that any project by the author has my vote of confidence by default.
Still, I oughta try this to make a proper judgement.
Not that the article itself didn't already have some odd takes, to say the least, but I find it a bit ironic that they talk about design with seeming authority when that site has a very strange anti-feature where every few minutes eyeballs pop up on screen—sometimes over the text, making it more difficult to read—and you have to hover the pointer over them to make them go away. It was absolutely terrifying the first time, and quickly got annoying after that.
In hindsight, the eyeballs act like an unintentional warning not to bother reading. And that's despite my agreeing with the initial premise that these flat rebrandings are getting way too common.
Well, as an avid movie watcher who absolutely loves the theater experience, I truly do hope they never go away, and that my hypothetical children get to experience them too.
> It turns out Kubernetes is actually perfect for small teams
As long as at least one of them is an expert on kubernetes. In this case, the one person in the team is that person, and as he points out in the article, he's using it because it's what he knows.
That should be the takeaway, I think. The "trope" remains pretty sensible IMO; I've seen it first-hand, jumping on kubernetes without the know-how is a foot-gun factory, and that team ultimately gave up on trying to implement it.
Probably, the best answer to the "programming is easy" mindset I've read is this article[1] about whether software engineering is actually engineering. Turns out we are engineers, and we're not even that special as far as engineering goes.
And it's funny, because the article has nothing to do with whether programming is hard or not. Not idea what Wayne thinks of the matter.
In the future, I'll just link to this piece.