Long ago, I posted a short note On Proficiency where I noted four things I believed were needed to become proficient at an activity: aptitude, interest, knowledge, and skills.
My experience learning software development took a different route than many developers today. I started development in very small teams (1-2 developers). I had actually been working with a larger group at the time, in an unusual language. As a result, we tended have to train people from scratch to work on our system. From this experience, I didn’t have many preconceived notions of who could or could not do development.
I was later surprised to have some communities decide ahead of time who could or could not have an aptitude for programming based on their gender or race. Of course, I was aware that many older programmers were white males. But, that was true in most fields because white males had dominated most fields for decades, so there were obviously more of them. I may have been naive, but I saw this as an opportunity problem rather than an aptitude issue. I hadn’t seen any race or gender correlation in the people I had learned from and trained. I saw talented programmers that were of many different races and genders. Empirical evidence trumped bias in my mind.
In my original article, I used a physical sports metaphor for explaining the aptitude portion of proficiency. That actually fails for programming. Worse, it gives the impression that aptitude is physically obvious. I’ve seen many different people learn to program, and the aptitude portion depends on how their brains work. No one can see that from the outside, despite the fact that many believe they can. Unfortunately, generalization and stereotyping also play into this issue.
The only way to see if people have an aptitude for programming is to allow them to try to program. Trying to guess someone’s aptitude by looking at them (or their resume) is doomed to fail. Trying to do otherwise has almost certainly held back talented programmers that could have done some great work.