Everyone seems to agree that our likely future includes more technology. Accordingly, everyone seems to agree that we need more programmers. You can teach yourself programming via online courses, and there are various earnest organizations keen to help members of underrepresented groups become programmers. Everyone, it seems, should be learning to program.

It’s hard to argue against education, and it’s hard to argue against economic opportunity – and I won’t do so. Nevertheless, I do wonder if we risk overdoing it with our current love of programming. As with most good things, there is a danger of getting carried away. Along those lines, it’s worth talking about a couple of different organizations I’ve encountered that explicitly filter their hiring based on programming skill.

The first organization prizes secrecy, and would not be a recognizable name to most people. Indeed, I had never heard of them before they contacted me and encouraged me to consider them. Let’s call them Secretive. The interview process at Secretive involves a first day of programming problems. Only the candidates who make it past that first day are invited to a second day of conversations about business.

Meanwhile, I also had a similar query from a big famous company, one of the internet giants. Because I don’t really know how representative my experience was, I won’t use their name either. But let’s call them Famous. In initial conversations with Famous, there was a clearly articulated hiring standard: individual contributors would be writing programs 80% of the time. Although managers would not have to spend as much time on programming, any manager would have to pass the same programming tests as an individual contributor.

Both Secretive and Famous exhibit a strong bias in favor of hiring only programmers. Both companies depend crucially on software and programming for their products and services, so at some level this focus on programming is rational. And yet I found myself wondering about the potential for blind spots and for narrowing the talent pool too much.

It seems sensible if you’re running the hiring processes of a tech company that you want to avoid certain deficiencies. Someone who just doesn’t understand programming as a task, who can’t think computationally, who can’t troubleshoot methodically – sure, those might well be reasons to eliminate a candidate. And one way to eliminate those problems is to focus on only hiring people who write code. But that choice yields false negatives. The process will eliminate people who are actually capable of the thinking skills required, even though they’re not good enough (or not inclined) to be full-time programmers.

Presumably, the companies that are focusing on programmers have considered that possibility and consider the false negatives to be less damaging than false positives: people who claim to be software-literate but are actually clueless.

Yet I am struck by a kind of arrogance exhibited by these organizations screening out the non-programmers. We could imagine, for example, that an organization might convince itself that everyone should understand accounting. After all, accounting is very important to business. So maybe people should only be considered for jobs within the organization after it’s been established that they understand the fundamentals of accounting.

As far as I know, even accounting firms don’t hold to this theory of hiring. Instead, accounting firms realize that people doing marketing need to understand marketing, people doing IT need to understand IT, people editing documents need to know how to edit. In all of these cases it can add value to be familiar with accounting, especially for an accounting firm; but it would seem bizarre to eliminate an otherwise-excellent proofreader because they couldn’t operate as a bona fide accountant.

I suspect that professional programmers overestimate the importance of programming skill. I don’t think it’s necessary or wise to create a technology-focused monoculture in tech companies. Even within an engineering organization focused on software development, there isn’t always a simple relationship between the ability to understand and innovate large-scale system structure – the architectural thinking, if you like – and skill in coding.

I love certain aspects of programming, and it has been a crucial skill for me at various points in my career. So whenever someone is genuinely interested in programming, or becomes enthusiastic about it, I’m happy. But I’ve also spent enough time explaining technology to non-technical people to see that thinking like a programmer is hard for many people. Indeed, I well remember how some people who entered college alongside me, intending to major in computer science, decided that they were not good programmers. They went into other intellectually-demanding fields and did well, so they weren’t bozos – but their skills didn’t align well with the demands of programming.

Of course, many worthwhile things are hard – that’s not in itself a reason to avoid something new. But I suspect that the advocates of “programming for all” are overselling its merits. The world is full of possible pursuits that are likewise challenging but rewarding – bricklaying, learning French, arranging flowers, and much more. I suspect that programming doesn’t merit the special attention it’s currently getting.