In defense of contempt
A response to a popular article
The article in question suggests that the habitual tribalism & combative style in communication within the tech community is toxic, particularly to minorities; I do not dispute this point. The article in question also suggests that criticism of languages and technologies should be avoided because it often discourages community diversity, and this is where the author and I part ways.
The state of the programming community is poor, with regard to diversity, and this leads to all sorts of systematic problems that are self-perpetuating. However, the state of the programming ecosystem is also poor, and the perception of acceptability given to bad tooling and bad habits leads to systematic and self-perpetuating problems of its own. The way to increase acceptance of outsiders into the community is not by sacrificing the very worth of the enterprise the community exists to engage in; indeed, it’s entirely unnecessary to do so.
The author decries the tribalism of the community with regard to tooling, but differences of opinion when it comes to preferred tools is not a meaningless aesthetic distinction. The prevalence of overflow-related vulnerabilities in real software ultimately comes down to the popularity of C over Pascal historically; as many exfiltrations of password files and other sensitive data are owed to the use of outdated PHP best practices as can be attributed to SQL injection (and thus, lack of input validation); the poor state of Windows security prior to 2001 when compared to competitors at the time 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 — in other words, Windows was a leaky sieve and prime target for over a decade because lazy habits that were acceptable for single-user isolated machines with no real multitasking were being applied to a huge number of interconnected boxes.
The results of using a poor tool or using a good tool poorly are a lot like the results of ignoring modern medical science: in isolation, they might be acceptable for a handful of people who don’t have it rough, but in aggregate they result in epidemics. 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. Someone who promotes the use of tools that encourage the production of bug-prone insecure code outside the context of isolated personal experiments should be treated the same way we treat antivaxxers: as a perhaps well-meaning but deluded person whose misinformation is resulting in major destruction.
When someone has different aesthetic preferences, it’s natural to accept that. But, when a group that is already marginalized disproportionately adopts a set of tools that are well-known to be destructive and then dedicates enormous resources to the use of those tools, we don’t decide that those tools must be acceptable on aesthetic grounds despite their known destructive potential: we instead try to discourage that group from associating with those tools and figure out what forces are creating that association.
Poor tools are often the domain of beginners, and those who dedicate sufficient time and effort eventually graduate from those poor tools to better tools. (I first learned to program in QBasic.) That time and effort isn’t free, so people who are already under other extra constraints (including people who have extra social or financial pressure) often never move on.
There’s another factor here, however: good tools in some ways often become poor because they become popular with beginners. Most tools are optimized for a small set of problem domains, work acceptably in some others, and work horribly in every other domain. A beginner, having experience with only one tool, will apply this tool to every domain; if problems in some domain are harder to solve with this tool, the beginner, unless properly instructed, will believe the problems in this domain are simply inherently harder to solve. As a tool becomes popular with beginners, experts become difficult to identify in the crowd, and slightly elevated beginners begin to become treated like experts simply because there are many more slightly elevated beginners than experts; these pseudo-experts will popularize poor habits in the community, and these habits beocme associated with the tool itself. An expert who uses many tools will have less say in the community surrounding one tool than the many enthusiastic beginners who are unaware of or reject all other tools. To some degree, the most toxic tribalism is that of beginners who don’t think of programming languages or techniques as tools and identify themselves with their preferred tools.
There’s another interesting tendency with regard to the popularity of certain tools with beginners, and it’s one that’s wrapped up with institutions and politics. This is the matter of pedagogy. Java is currently extremely popular, but its popularity owes little to its attributes and much to the fact that it has become part of a standard; there is a curriculum surrounding Java focusing on a Java-centric view of object orientation, and this curriculum forms the basis of both the AP Computer Science curriculum in the United States and various certification and accreditation rules for university programs. In other words, if you live in the United States and you are not an autodidact your first programming experience (barring a bootcamp) will probably be in Java, combined with a curriculum that focuses on UML, inheritance, and the details of Java-style encapsulation, while completely ignoring performance concerns and systematically denying that some problems are not easily represented in an object oriented model. Prior to Java, these programs centered on C++, with a similar set of foci. In other words, for several decades, students with no prior programming experience have been taught that there is one language (Java or C++) and one technique (Java-style OO) that is the best at everything, and as they filter into industry they work with other people who went through the same indoctrination and continue to produce huge ugly monoliths of inefficient Java and C++ “enterprise” code. This is the end-game of letting an echo chamber of like-minded beginners dictate the state of an industry.
So, what do I recommend, with regard to the problem of balkanization in tech pushing out minorities?
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”.
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.
Also, seasoned developers who frequently work in many languages and have a deep understanding of the positive and negative aspects of many tool designs should become more vocal about tooling: even-handed discussions about this subject make it easier for beginners to graduate into well-rounded developers and avoid making common mistakes that lead to wide-scale disaster.