site banner

Culture War Roundup for the week of October 3, 2022

This weekly roundup thread is intended for all culture war posts. 'Culture war' is vaguely defined, but it basically means controversial issues that fall along set tribal lines. Arguments over culture war issues generate a lot of heat and little light, and few deeply entrenched people ever change their minds. This thread is for voicing opinions and analyzing the state of the discussion while trying to optimize for light over heat.

Optimistically, we think that engaging with people you disagree with is worth your time, and so is being nice! Pessimistically, there are many dynamics that can lead discussions on Culture War topics to become unproductive. There's a human tendency to divide along tribal lines, praising your ingroup and vilifying your outgroup - and if you think you find it easy to criticize your ingroup, then it may be that your outgroup is not who you think it is. Extremists with opposing positions can feed off each other, highlighting each other's worst points to justify their own angry rhetoric, which becomes in turn a new example of bad behavior for the other side to highlight.

We would like to avoid these negative dynamics. Accordingly, we ask that you do not use this thread for waging the Culture War. Examples of waging the Culture War:

  • Shaming.

  • Attempting to 'build consensus' or enforce ideological conformity.

  • Making sweeping generalizations to vilify a group you dislike.

  • Recruiting for a cause.

  • Posting links that could be summarized as 'Boo outgroup!' Basically, if your content is 'Can you believe what Those People did this week?' then you should either refrain from posting, or do some very patient work to contextualize and/or steel-man the relevant viewpoint.

In general, you should argue to understand, not to win. This thread is not territory to be claimed by one group or another; indeed, the aim is to have many different viewpoints represented here. Thus, we also ask that you follow some guidelines:

  • Speak plainly. Avoid sarcasm and mockery. When disagreeing with someone, state your objections explicitly.

  • Be as precise and charitable as you can. Don't paraphrase unflatteringly.

  • Don't imply that someone said something they did not say, even if you think it follows from what they said.

  • Write like everyone is reading and you want them to be included in the discussion.

On an ad hoc basis, the mods will try to compile a list of the best posts/comments from the previous week, posted in Quality Contribution threads and archived at /r/TheThread. You may nominate a comment for this list by clicking on 'report' at the bottom of the post and typing 'Actually a quality contribution' as the report reason.

24
Jump in the discussion.

No email address required.

That said, I also see in newer hires a lack of that sort of persistence both among the men and the women. Probably somewhat "Old man griping about the young'uns" here, but I've seen an increasing tendency of kids with fresh CS degrees to not really know how to independently track down the solution to a problem, including scouring stackoverflow and APIs et al. They sort of throw their hands up and ask very broad questions in channels like "Hey, this thing isn't working, can anyone tell me why?" Or "How do I do ?" ("Thing" being a fairly complicated multi-step process that requires experience mostly consisting of trying to do it and figuring out how to get past each obstacle one by one.) And they do this at every step. I have to gently point them at where to go to look for the solution to the next step, when I want to say "This is called being a programmer - read the documentation, use Google, and figure it out!"

I am amazed at how many programmers never read the documentation. I've had many coworkers, not just younger, give up if they don't already know the solution to the problem. It should be bog standard to peruse the API calls, and fiddle in test programs with anything you don't understand. But most don't.

They don't want to discover a solution, they want someone to figure it out for them, and tell them exactly what to do.

A level up from that would be reading the source code of the libraries yourself (assuming it's available). A level up from that would be studying the byte code as an absolutely last resort.

Because sometimes you do find bugs in libraries. Or annoying deficiencies. Once I was using an open source websocket library, but had to use a bearer token for authentication. The websocket library came years before the requirement for bearer tokens, and it did not support it at all. The guy who maintained it had weird ideological reasons to never include it. But fuck it, it's open source. So away I went hacking it in. No big deal. But it's remarkable how few programmers are truly willing to go wading through someone else's code.

Honestly, given the quality of the documentation provided by most libraries etc these days, it's often easier to jump straight into the source. At best, the behaviour is undocumented. More likely the documentation is from six months ago when it worked entirely differently. The devs probably notified everyone about the change in behaviour via Discord or something.

EDIT: I think being given solutions to problems tends to be more valuable when you've tried your best to solve the problem yourself already. Then the answer is like a flash of light. If you just read about a problem and a solution, it's just a series of facts to store away for later.