I read several articles this morning that got me thinking about ancient history, as when I was young. The first article is a personal account from a young Asian male who eventually ended up in CS at MIT. He recounts how everyone assumed, due to being Asian male, that naturally he knew all about programming, from earlier exposure, and he didn’t and in fact had to struggle some matching the other students who had been programming from an early age. This article had a link to another article, another personal account from a young woman talking about “Technical Entitlement” and how this discourages the non-typical (i.e. not male) students from taking on STEM disciplines. These are interesting articles to give me a sense of what it is like today (vs 1962 when I started programming). Given the low cost of computers any kid who is so inclined (or encouraged by family) can start early in life with programming and thus enter the race with an existing headstart.
But it wasn’t always this way and so I can add a little tidbit from a generation earlier.
When I was 6 there were almost no commercial computers and so any kid, anywhere, any ethnicity or gender, was unlikely to have even seen a computer, much less had access to program one. The first time I even saw a computer was at the New York World’s Fair and it was even a fake, the image then that the public had of an “electronic brain”. But the first time I got near a computer was even later when I had the misfortune of spending about 10 days in a hospital bed (back in the old days when even a minor injury allowed you to be in a hospital awaiting surgery). My dad was required to take a programming course, ALGOL, as his company (the predecessor to Enron) had a large (for the time, about a watch today) computer used in various calculations about natural gas production. My dad hated the course and so brought his books and homework assignments to show me while visiting me in the hospital. Of course I was instantly taken and plowed through the textbook (McCracken, IIRC) and was fascinated with my dad’s homework assignments (really simple) and did them for him.
But nonetheless computers were so expensive then that even though I wanted to try a real program (not just drawing flow charts and “writing code” (with no way to test any of it, so it was probably junk) that I didn’t get a chance to actually try any program. The next summer I went away to one of the popular (back then) NSF summer science programs at Northwestern University and so got to do my first real program, a tiny thing on the university’s IBM 1620 (the closest thing to a mini-computer in those days). Now before graduating high school I’d “learned” both ALGOL and FORTRAN (even then I thought ALGOL was way more interesting and elegant).
So in my senior year in high school, frustrated by the stupid way classes were scheduled that then caused me to be in the dumb physics (instead of the AP version) I decided I could write code to do a better job of class scheduling. This was for the old Westinghouse Talent Search contest (still exists, but someone else sponsors it, the projects kids do today are amazing!) My summer at Northwestern had clearly demonstrated the need to actually test code as just writing it without testing means you probably had junk. So I enlisted my high school to get me access to a computer to do my code. The only thing they could find was a glorified check sorting machine used in simple banking (clearing checks) that could only be programmed in assembler and had a whopping 4K of core (yes, actually core). Of course, a) it was hopeless to do a large integer programming project (as I later learned the technology in an operations research class in grad school) on such a tiny machine, and, b) I was totally baffled by assembler (with no one to help me at all) after only seeing high level languages. Actually as I remember my project my approach was not that stupid even though I could never test it. Later in an in-person interview for Caltech this project had really attracted their attention and they wanted to know all about it (since this was an active interest at the time). Fortunately I was smart enough to not exaggerate what I’d done as they actually wanted to fly me out to meet with their people working on the same project, which would have been really embarrassing to expose my ignorance to people who would have quickly determined how feeble my effort was (later I met kids who at a young age had done astounding things worthy of discussion at grad school level so for Caltech to assume I might be in that category is not crazy, but in fact it was crazy).
I loved programming so much I decided that show-your-work numerical computation in a calculus class was too tedious and submitted a computer program (untested, of course) instead of doing the homework, getting my first 0 on an assignment because I broke the rules. Even though I was lucky to go to an elite high school being a smartass was still discouraged as I’d learn over and over again later.
So when I entered MIT there wasn’t even a CS major (many classes in programming, but no actual degree, yet). But only a handful of my fellow freshman had any exposure to programming at all so I did enter an “elite” group. But I actually considering programming just fun puzzles, not something I actually wanted to study. But nonetheless I did really learn programming, but not from classes.
A friend, who was a very clever mechanical engineer, wanted to try to build a control system for his hobby, electric trains, so, wisely he thought he’d model his design on a computer before trying to build it (rather prescient at the time as that kind of thing was rare and for a freshman to consider this was quite unusual). He was a good scrounger and so managed to find an “unguarded” computer, another IBM 1620, where we could “play” with it after hours on weekends. So early Friday night a few of us hackers (the real meaning of hackers) walked across the Mass Ave bridge and started to work. We did all the usual thing, fueled on cokes and pizza, and would drag ourselves back late Sunday night after non-stop programming.
The 1620 just barely had a disk (about 7Megs) and so to compile a Fortran program required loading a huge card deck into the 1620 which was the first pass of the compiler, and then insert our card deck. After considerable time the 1620 punched out (slowly) another card deck (the results of pass 1) and we’d load in another huge card deck (pass 2 of the compiler) and our output from pass 1 and after another long delay we’d get a binary of our code. Then we had to read in another card deck (a mini-OS, mostly just a loader and some library routines (a framework in modern jargon), and finally, literally after about 30 minutes our code would finally run. Now of course often the program didn’t even compile so it was back to our paper coding sheets to repair the compile errors, punch some new cards, and then get back in line for another go. Once we finally had a program that would execute it usually failed (the 1620 just halted, no debugged, not even a core dump) and then it was actually using all those lights and switches on the console to figure out what had happened. If we were lucky without about 8 hours we’d have a program that could actually run without crashing, but then it usually didn’t get the right results, so it was back to turning the crank.
The point of this long story is that all this tedious work emphasized real economy in getting the code right the first time (or at least the second or third); IOW, lots of hand testing on paper to make sure our code was right (today known as design). The huge amount of time to get any results completely eliminated the trial-and-error approach of debugging that wonderful tools like Visual Studio (despite emphasis on OOD and OOP) made easier. I suspect I could write a program like the ones that took me several weekends in probably less than an hour today, but some of the “tricks” (to minimize mistakes) stand me in good stead today.
So by the time I took an actual programming course (my college junior year) I’d had about five years of “experience”, thus resembling what the young people in their blog posts described as “technical entitlement”. And the only reason I took a programming course was that I’d been turned down for a summer job. I interviewed with a construction company who quickly figured out I had no useful skills so I replied “I can program” when the interviewer tried to find something I might do. So then, the same questions: “what classes have you taken? what experience do you have?”. Since I’d had no classes the interviewer simply wouldn’t believe I actually could program, especially as I explained I’d spent hundreds on hours on the 1620 “hacking” (actually used that term even though few had ever heard it) he simply didn’t believe me: a) no one could learn to program by themselves, without instruction, and, b) no kid would have had so much access to a computer that this company had struggled to buy and jealously guarded its usage.
So, for future interviews, I decided I needed a class on my CV. Of course by the time of the class I already knew all the material so quickly fell into the category of a wiseass who tried to prove I was smarter than the prof (my first homework assignment scored 0 since I used a different approach than I was supposed and got MORE accurate answers than the grading program, whose flaws (since I had its source code) I explained to the prof (as in, you never compare floating point results for precise inequality due to small errors in iterative calculations). I liked full professor don’t like to be told by smartass students their code is wrong. I almost flunked the course, in fact getting the only D I got. Once again I learned it’s not too good to be better than people expected.
I continued my major in materials science with no notion I’d ever do programming as a career, but once again, the need for a summer job led only to a programming job (now assembler on an early IBM 360, btw, almost all computers were IBM in those days). That was a lot of fun but actually I was more interested in the purpose of the programs I wrote, namely budgeting and projecting cash flows, so I ended up fascinated by that and went off to get an MBA in finance, leaving computing behind. Although once again I got “in trouble” submitting programs (now working) instead of tedious homework assignments (as in doing linear programming by hand), so again I got discouraged from my arrogance, even though I was right, and developing code was actually clear proof I “understood” the simplex method, better than doing the computations by hand.
So armed with my MBA I headed to Silicon Valley, not to do code, but to do finance. The trouble was they really saw my experience and decided I should be a COBOL programmer instead. Having far more experience and skills than the average programmer (at HP’s corporate IT, then known as EDP), yet again I broke the rules and did my first assignments in a completely unexpected way (it worked) and so, yet again, got my hands slapped for thinking outside the box. I was lucky though since HP released its first commercial computer the year I started so soon I found myself actually developing software for a living. My rebellious streak continued as I was convinced much of what HP was doing with the HP3000 software was stupid and so again I colored outside the lines with both some positive and some negative consequences.
So when these kids talk about what it means that some students enter programs either with (when unexpected) or without (when expected) extra background I understand the phenomenon.
But I also understand something else. As programming has become more commonplace it means a lot of people doing it are not very good. In my management classes the few companies needing good software had begun to study programmers. A fact emerged early on that many people were 10X, sometimes even 50X, better than average. In few fields do the “stars” do so much better than the average. And no one could really figure out what it was that the stars could do: they weren’t smarter, they weren’t better at math, they weren’t better students. In short, it was hard to correlate any human skill with great programming skill. Of course this is frustrating to business who wants simple ways to qualify and evaluate people, either for hiring or supervising. Since I’d hung out with some very sharp programmers at MIT I had my own ideas, not just of what they did “right”, but also what I did right. I’m sorry, but like most things some people have a knack for doing things that others do far less well. You see these young violinists or chess players or math geniuses and always wonder what it is that makes them so good and the answer is that it’s hard to correlate with many of the other skills.
So today with kids able to start programming at a young age and have access to computing capability I couldn’t even dream of when I started it’s inevitable that some of those kids will do very well. And since millions of “average” programmers at productively employed no one still can understand the unique talent that a handful of programmers have (and btw, I don’t believe hackathons prove diddly about this, glibness at puzzles is not the same thing as real talent).
But one thing I do believe is that a healthy bit of rebelliousness and out-of-the-box thinking is critical. In my last job I worked with a large number of young programmers in China. They were technically competent, but frankly very uninspired. They had been heavily “taught” and mostly my rote and mostly immediate practical skills (rather than general problem solving and a style of thinking critical to good software). They earned their pay but just barely. Few of them will ever do anything very creative or interesting (and I’m not just picking on Chinese outsource programmers, my experience with U.S. CS grads, including from MIT leads me to the same general appraisal of most programmers). So I think temperament is perhaps the most important key to success as an outstanding programmer. Sure some other skills matter, but the key thing is how a programmer’s mind works, not the mechanical skills of programming. But combining that with my experience of very sharp kids in other disciplines at MIT I believe the same idea holds.
So, sure, early exposure to any field gives that person a head start and perhaps a bit too much attitude, but the real effect is a filtering effect. Kids that REALLY take to software will be good at it; kids just showing off won’t or studious kids won’t.