1. 3
  1.  

  2. 9

    Someone who writes ostensibly production-ready code in PHP or Perl should be treated like someone who refuses to vaccinate their children: their behavior should be considered acceptable only if they are extremely careful and they have a very good excuse.

    I think the author is a bit melodramatic, and that is the toxic part – there’s criticism, and then there’s criticism without concern for the humans receiving the criticism. I agree with the author that there’s a vast majority of programmers who could benefit from better tooling (I put myself in this camp), but how that knowledge is conveyed makes all the difference (as they mention in the article itself).

    It sounds like the author has knowledge and wants to spread it – either by mentoring or teaching directly. To be successful at that, they need to understand where a mentee/student is and jump into their worldview before moving them forward. There is a huge difference between “here is where I think you are, which means you’ve probably seen these kind of frustrations pop up, why not try X instead” and “hey you’re doing this all wrong, here’s the best way.”

    Sidney Dekker talks about how people don’t show up at work to do a bad job – everyone is usually trying their best, but is working within constraints (“my boss won’t let me use X”, “I haven’t heard about this,” “I have outdated knowledge about this,” “I don’t want to support this organization for moral reasons,” “I’m under a tight deadline and can’t afford the rewrite,” etc). People will only be receptive if you acknowledge that they are doing their best within constraints, and you are removing a constraint. “You use PHP, therefore you are bad” statements make you feel good and self-righteous, but are less effective than “do you hit these kinds of errors?” “yes!” “then you might consider this other language, it’s easier than you think.”

    As I write this I feel a bit hypocritical as I’ve spent a long time criticising {large, well known software product with a defensive, tribal culture} for not doing {well established modern software engineering practice} and releasing a buggy and infuriating product. My ranting and raving did nothing. Absolutely nothing. What was effective? Another team got merged into that one and started flooding the mailing lists with “you thought {software engineering practice} was impossible at this scale but it’s actually doable.” It worked. That’s how you effect change in organizations that might even be hostile to you: meet them where they are, treat them as doing their best within constraints, and show how to remove the constraints.

    1. 4

      I think the author is a bit melodramatic, and that is the toxic part – there’s criticism, and then there’s criticism without concern for the humans receiving the criticism.

      Absolutely. I fell into that trap recently. The organisation I was in was using PHP, and I engaged what I thought at the time as collegial bitching at that poor language. Turns out they were mostly humoring me and taking a minor bit of offense at each nag, and the taken offense piled up in time.

      It was a lesson for me obviously, but there’s something to be learned on the other side of this fence: if you’re getting offended by something your colleagues do, bring it up very early and don’t just assume the offender is aware of how they’re affecting you.

      1. 3

        I actually make this point later in the essay:

        I consider this really to be an issue of beginners graduating to higher levels of understanding (and systematic pressure making it harder for certain groups to graduate out of the beginner classification), and one way to help this is to be extremely clear in your criticisms about the nature of the problems you criticize — in other words, rather than saying “PHP users are dumb”, say “PHP is a deeply flawed language, and PHP users should be extremely careful when using these particular patterns”.

        When we are talking to individuals, I think we have the responsibility, as @stip says, to “understand where a mentee/student is and jump into their worldview before moving them forward”. However, one-on-one mentoring is not where programmers of any level learn most of their habits these days (and I’m not sure it ever was!). Instead, the most powerful shapers of industry and community norms are publications (ranging from comments and blog posts to books and standardized lesson plans) and myth (ranging from hype and stereotypes to stuff like programming epigrams and The Story of Mel). Publications shape myth through hyperbole, so if you’re writing for a very general audience, it pays to be melodramatic enough to be memorable.

        (While overwrought, I don’t think the comparison to antivaxxers is unfair. Using insecure tools in serious projects because you think it doesn’t matter bites you in the ass when the project suddenly acquires scale and problems start affecting every install, in the same way that an individual decision to avoid vaccination becomes a failure of herd immunity at scale. The fundamental mistake is the same: evaluating decisions about interactions with a group from only an individual lens.)

        Something I originally meant to address more directly in this piece is a flaw I see in articles of the type it criticises – namely, I think social pressure is extremely valuable because it performs soft enforcement of rules, and articles critical of gatekeeping in tech often ignore the social dynamics of this. The particular article I’m responding to only bumps up against the problem.

        Ultimately: when your software doesn’t matter (when it has zero or one users, or all its users are also its core developers, and when nobody ever pays for it, uses it for important tasks, or gives it sensitive data), then tool choice also doesn’t matter. This is great! But, when your software matters (when people depend on it working), making sure it’s reliable and secure matters more than your ego and personal preferences. At this point, so long as they properly modify behavior in the appropriate direction, social pressure (to the point of hostility) is justified.

        When I see people complain that they get criticized for using in a serious project & their defense is that they’re a beginner and don’t know how to use something better-suited for the job, my basic response is that when somebody is depending on a project, it shouldn’t be implemented by someone who doesn’t know how to implement it reliably. (Making sure the thing works is more important than even profit: if you can only do a half-assed job without going broke, you shouldn’t do it at all.) In the extreme case, you work on it until it is reliable (by learning new techniques and tools) and discourage people from depending on it (by marking it alpha) until it’s actually release quality.

        (And, of course, on the other side: when nobody depends on it, we should encourage beginners to expand their horizons by using all sorts of tools – particularly tools that are a poor fit – since dealing with a poorly-fitting tool when both the tool and the problem are new to you is a very productive learning experience.)

    2. 4

      We should separate criticism of tools based on legitimate concerns from criticism of tools based on tribal or class issues. Plenty of tools can be used well but largely aren’t because most of their devotees are beginners (see: Java, C, C++, Python). Other tools are fundamentally flawed, and while using them well is not impossible, it is a trick that takes a great deal of experience and is beyond the scope of nearly all of its audience (see: PHP, Perl, Javascript).

      This is a really important point. The idea that expressing contempt for specific programming tools should be forbidden because the use of those tools is associated with an underrepresented group about whom criticism is forbidden doesn’t make the problems with those tools go away - but it does strengthen the association of those bad tools with the underrepresented group.

      I consider this really to be an issue of beginners graduating to higher levels of understanding (and systematic pressure making it harder for certain groups to graduate out of the beginner classification), and one way to help this is to be extremely clear in your criticisms about the nature of the problems you criticize — in other words, rather than saying “PHP users are dumb”, say “PHP is a deeply flawed language, and PHP users should be extremely careful when using these particular patterns”.

      This is always good advice. Criticize the actual problem as precisely as you can.

      Another way is to make it clear that using a single language is not acceptable in a professional context: any serious developer has a large toolbox already, and if beginners understood that language preference is not a reasonable basis for long-term tribal divisions because any professional belongs to multiple tribes, the toxic identity-based hostility between programming language communities would mostly go away, allowing concrete and issue-based critiques to become more visible.

      Absolutely, 100% agree. Languages should be tools, not foci for tribal identities. Every programmer should be expected to be familiar with multiple programming languages, even absolute beginners.

      1. 2

        “ultimately comes down to the decision to avoid taking full and proper advantage of hardware memory management, setting up a proper system of user privileges, and other common practices in the domain of network-connected multi-user OSes”

        Further, they knew about it since the founders of INFOSEC field and security certification were encouraging them to do that. Schell always gave GEMSOS, a B3- to A1-class system, as an example from the 80’s onward. In the evaluator reports, they always had a section asking whether the vendor made “effective use of hardware” like rings or segments. Even TIS’s rewrite of Microsoft Xenix to medium assurance (B2 class) got critiques for not using hardware enough. Microsoft Windows and Xenix didn’t even try. Instead, Microsoft went with minimum needed (C2 - “certified insecure”) to sell to government. Their lawyers, lobbyists, and marketing people worked from there. ;)