Tag Archives: aptitude

Extras

The one person who can’t be replaced by a computer …

3 Comments

… is the person who runs one.

I came across this advertisement for the Electronic Computer Programming Institute (ECPI) in the September 16, 1966 issue of Life Magazine.   It is particularly notable for the way in which it plays on fears of technologically-driven unemployment:   “For all the people the computer puts out of a job, it can put more people into new ones.”

During the mid-to-late 1960s, vocational schools offering training in computing sprung up all over the country, appealing to the massive growth of the computer industry and the desperate need for programmers to develop software for them.  Some of these schools were legitimate attempts to provide much needed training in computing; others were fly-by-night operations that played on vulnerable populations (the un- or under-employed, women seeking to reenter the labor market after taking time off to have children).  All promised a high-paying job after graduation.  Most relied on some form of aptitude testing as an admissions criteria (although many admitted students regardless of their scores, with the sole condition that they were able to pay).  Many did not even provide hands-on time with an actual computer, or at best provided an hour or two of time on a leased machine.1  Edward Markham, “EDP Schools: An Inside View”, Datamation 14:4 (1968)

 By the late 1960s, the flood of vocational schools had become something of a scandal.  Numerous exposes of their less admirable practices were published in the industry literature, and many companies adopted “no vocational school graduates” policies.  The result was frustrating to both aspiring programmers and their potential employers, and highlighted the problematic nature of programmer education and training.  The need for quality programmers was apparent to everyone. But what exactly made for a quality programmer?

 

Email, RSS Follow
  • 1
      Edward Markham, “EDP Schools: An Inside View”, Datamation 14:4 (1968)
Book

Programmer aptitude?

7 Comments


The 1960s were characterized by a perpetual “crisis” in the supply of computer programmers.  The computer industry was expanding rapidly; the significance of software was becoming ever more apparent; and good programmers were hard to find. The central assumption  at the time was that programming ability was an innate rather than a learned ability, something to be identified rather than instilled. Good programming was believed to be dependent on uniquely qualified individuals, and that what defined these uniquely individuals was some indescribable, impalpable quality — a “twinkle in the eye,” an “indefinable enthusiasm,” or what one interviewer described as “the programming bug that meant … we’re going to take a chance on him despite his background.”

In order to identify the members of the special breed of people who might make for a good programmer, many firms turned to aptitude testing.  Many of these tests emphasized logical or mathematical puzzles: “Creativity is a major attribute of technically oriented people,” suggested one advocated of such testing. “Look for those who like intellectual challenge rather than interpersonal relations or managerial decision-making. Look for the chess player, the solver of mathematical puzzles.”

The most popular of these aptitude tests was the IBM Programmer Aptitude Test (PAT).  By 1962 an estimated eighty percent of all businesses used some form of aptitude test when hiring programmers, and half of these used the IBM PAT.

Although the use of such tests was popular (see Chapter 3, Chess-players, Music-lovers, and Mathematicians), the were also widely criticized.  The focus on mathematical trivia, logic puzzles, and word games, for example, did not allow for any more nuanced or meaningful or context-specific problem solving. By the late 1960s, the widespread use of such tests had become something of a joke, as this Datamation editorial cartoon illustrates.

 

So why did these puzzle tests continue to be used (including to this day)?  In part, despite their flaws, they were the best (only?) tool available for processing large pools of programmer candidates.  In the absence of some shared understanding of what made a good programmer good, they were at least some quantifiable measure of … something.

Email, RSS Follow