luord

In the future, I'll just link to this piece.

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.

- On type checking, I like type hints and gradual typing, but am not big on strict static typing.

- I'd like to do A/B testing, but only for fun and for learning/applying data analysis.

I post articles on what (I think) I know. Just a static blog generated by Pelican.

Feliz Navidad a todos!

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.

Better to follow standards anyway.

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.

So, assuming I understood correctly, treating them like tents is infinitely the better choice.

So I consider myself fortunate; by not taking LinkedIn that seriously, I've avoided a lot of... awkwardness, to put it nicely.

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.

If possible anyhow.

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.

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.

Still, I oughta try this to make a proper judgement.

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.

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.

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.

[1]: https://www.hillelwayne.com/post/crossover-project/we-are-no...

I don't remember the last time that a piece by Uncle Bob or Martin Fowler—and they're just two examples, I've seen quite a few more who are generally met with agreement every time they're posted—was heavily criticized or disagreed with here.

And when I do see disagreements, they tend to come from people who don't seem to have nearly as much experience as those guys do or who might have misinterpreted their point (much like how the idea of agile has turned into something that only reflects the manifesto tangentially, and accidentally at that) and who are, perhaps not coincidentally, likely to fall in the "programming is easy" camp.

And even then, "controversial in hacker news" is hardly representative of what's controversial in the field at large (which I also understand goes against my own first point).

Not sure how viable it is since it was actually more work than I thought it'd be, but at least I feel better now about my site not loading external stuff and setting unnecessary cookies. Now I guess I should actually write more stuff to see if I get mentions (and to test how vulnerable to spam it is, I suppose). I haven't ruled out looking into other ways to implement federated comment systems—or similar, like web mentions—though[2].

[1]: That said, I'm using cloudflare so I guess I do get its analytics.

[2]: And there's always the self-hosted option.

I must try this.

[1]: Pretty much the usual gitflow with sequential commits of partial work on a branch—often with commits fixing previous errors in the branch—until I deem it finished.

Quickly found out that enjoying the high school chemistry classes the most didn't translate to chemistry processes being what I wanted to do for the rest of my life. On the other hand, I fell in love with tinkering with the computer's software (first in windows, and then even more after I installed Linux) right away.

I stuck it out with chemical engineering for a year and half, before finally dropping out and starting fresh with systems engineering (more or less my country's equivalent to computer science) during what would have been my fifth semester. Haven't looked back since and, much like the author says, I love solving those puzzles.

In general, I've always liked the idea of pypy, so I'll try to use it more, and not just for performance. Will also donate when I can.

Absolutely none? I somehow doubt that, otherwise only the most incompetently run companies would still ask for that kind of commitment during the process and... Actually, you might have a point. I certainly have rarely liked work in companies that demanded free work from me during the hiring process. That might be one of the reasons why I haven't done an unpaid take home test in a long time.

> But the idea that the company is getting you to do work for its value outside of the interview process just seems

So the company isn't getting the candidate to work for free because it isn't getting value... If we ignore the value it gets from the interview process itself.

Providing some company a service so that it can make a decision on how it operates sounds like work to me.

On another note, this doesn't take into account that pointless busywork is still work.

This type of expectation of free work during the process needs to change. Maybe if enough people reject stuff like this, it will, but again, many can't afford not to jump through all the hoops the company decides to put in place. It's a tricky problem, to say the least.

Could you share the link to where someone else presented that same point? In fact, I only commented because I found it odd that nobody had said it yet in this subthread.