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.

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). Some tools have lost a great deal of respect because most of their ecosystem is populated by tooling that’s orders of magnitude worse than their original design, compounding flaws (see: Java, Javascript, Ruby). Other tools are perfectly fine for what they were designed to do but are almost always used for things they’re terrible at (see: Perl, Javascript, Lua, TCL). The popularity of a tool with beginners can certainly negatively affect the suitability of that tool in genuine and valid ways if the beginners are given sufficient control over the tool’s later evolution, so it’s not as though a tool’s popularity with beginners is inherently irrelevant, but a good tool can be used well even as most people use it poorly.

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.

Finally, standardized programs for computer science education should include language survey courses earlier and feature them more prominently, while removing some of the pro-OO bias that currently characterizes them: nobody should be able to graduate with a CS degree without being truly competent in at least five or six very different languages, rather than the typical gamut of Java, Javascript, and SQL, and they shouldn’t graduate without non-trivial exposure to twenty or thirty more.

Written by

Resident hypertext crank. Author of Big and Small Computing: Trajectories for the Future of Software.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store