dhconnelly

Interesting. It’s definitely more abstract and philosophical than books like “Effective C++/Java/etc,” but I personally got a lot out of it and find it to be a really useful resource in code reviews. Particularly when commenting on the big picture and structural aspects, rather than just language-specific idioms or correctness.

While it’s true that difficult decisions need to be made, it seems that the point of democracy is that such decisions should have popular mandates. This reform doesn’t seem to have anything close to a popular mandate

From the same link:

> Please don't complain that a submission is inappropriate. If a story is spam or off-topic, flag it. Don't feed egregious comments by replying; flag them instead. If you flag, please don't also comment that you did.

I dealt with a lot of the same issues around meaninglessness vs. golden handcuffs (at Google incidentally) and recently took a job at a smaller company, albeit without a pay cut. I specifically resisted switching jobs for several years for the same reason: having to grind Leetcode only to end up with the same alienation and cynicism. Turns out all that salary isn't just for hard work. Anyway, honestly, having now finally taken that step, I'll say that Leetcode isn't really a huge cost (you do it and then you're done for a while) and that simply working on new stuff does get you over one hump, namely the boredom. Not sure how long the new-stuff momentum will carry me past the possible onset of meaninglessness, but I'm trying to just adopt the "one must imagine sisyphus happy" mindset. Not a strategy but maybe at least a tactic? Happy to discuss further

Edit: I'm aware this is a very privileged situation to be in, honestly that doesn't help much with coping though and everyone wants to be happy. I seriously had just decided I never would be. Even that (temporary?) feeling is mind-blowing

Yeah, no argument there. And I definitely like the Go community’s tendency towards straightforward code. But even there (among less Go philosophy-minded engineers, possibly) I’ve seen crazy abstractions built using interface{} that didn’t need that kind of generic code for the use case. Another one in Go is the nil/interface type interaction, for example. And this kind of thing can be hard to reason about, and that’s what I’m trying to say. All the languages have these complex and tricky bits and it’s best to stay away from them unless truly necessary.

Oh man, I read this article a few months back and it immediately resonated with me. I've never used Scala, but this advice has been applicable in every language, project, and team I've ever worked with, and I very much regret that I didn't already have this resource to cite in past code reviews.

A lot of the worst tendencies that developers complain about in complex programming languages (i.e. all of them, they're all complex) could be addressed by this advice.

Okay, so there is consensus. I guess I was confused. Seems like quite a few people here are confused, though. Seems worth considering!