[转]How I got started in programming - Bruce Eckel

This was a rather long and circuitous path. In freshman algebra in high school (1971), the extraordinarily weird teacher had a thing for computers and had managed to get an ASR-33 teletype with a 300-baud acoustic phone coupler (which I learned to whistle at and get a response) and accounts to the HP-1000 computer that the high school district used. We were able to create and run BASIC programs and save them on punch tape. I was fascinated and went home to write programs in the evenings that I would bring back and key in whenever I could. I invented HOSRAC.BAS which was a horse-racing simulation, using asterisks to represesent the horses as they moved (this was on paper printout, so it took a little imagination).

My friend Daniel (the same one who designs my book covers now) had a brother who was making money for a time by providing pinball machines to bars and restaurants. He had a slot machine where I got all of that out of my system, can't stand the things now, and also one of the very first Pong games (and I now almost never play computer games. Perhaps I'm a humorless sort, but it seems like programming is far more intriguing and challenging than playing a computer game).

I got involved in photography and journalism later in high school, and majored in journalism during my first year of college. I decided that I had learned enough about that from school, and changed to physics. Several colleges later I completed a physics degree at UC Irvine and added enough engineering classes to make it a double major if I had chosen a particular field of engineering, but I was trying to be broad, so my undergraduate degree is in "applied physics." As an undergraduate I took a smattering of computer programming classes here and there, enough for entertainment but nothing that provided any depth. I think these classes helped add to my foundation by regularly trickling in little bits of information, but I had none of the depth or perspective necessary to really understand anything. I didn't make any distinction between the computer and the compiler or interpreter (and only had a vague sense of compiler vs. interpreter); it was all the infallible computer to me and the idea that a bug could exist in the language or operating system was so purely theoretical that I never considered the possibility.

I went to Cal Poly, San Luis Obispo for graduate school because (A) I really liked the area (B) they accepted me and even gave me a teaching job and a fellowship, but most important (C) I couldn't imagine working at a job longer than one summer. I was definitely not ready to join the working world.

As a physics student I had studied solar power systems, which were big at the time (California gave a tax credit if you put a solar system on your house or business, and many business sprang up because of that), and Cal Poly seemed to promise these things in their engineering department. However, to get a degree in Solar Engineering would have taken many years because the necessary classes were not offered often enough. As a result, I took whatever graduate engineering classes were offered, and got a broad education (as was my wont) including mechanical, solar, electrical and electronic engineering. The class I taught was an introduction to electrical engineering for non-EEs. The graduate engineering classes that were offered most often were in computer engineering, so I ended up with a degree in that. I was also taking art courses, a couple of dance classes, and a few computer science courses (Pascal and data structures), but in computer engineering I finally struggled through the process of how a processor worked, and I carried that with me ever since. That was really the foundation of my knowledge of computers.

When I did start working, it was as a computer engineer, with a fair amount of hardware and relatively simple programming. I began to teach myself C because it seemed to be the ideal embedded systems language, and slowly started to understand more about programming languages. At one company we actually generated our own compiler from sources, which was a bit of an eye-opener for me (A compiler is just another piece of software! Imagine that).

When I went to work at the University of Washington School of Oceanography (for Tom Keffer, who later founded Rogue Wave), we decided to use C++. I had only one book to learn from (Stroustrup's; not a beginner text) and ended up having to struggle through and understand language features by examining the intermediate C code that was generated by the C++ preprocessor. Quite painful, but intensely educational. I have used that experience ever since, because it gave me the ability (that my physics professors tried and failed to impart) of dissecting a language and seeing it for what it is. I suppose that is where I began to learn critical thinking.

So the concepts didn't come all at once. Instead they were trickled in over time, and everything I know has taken time to assimilate. If I seem to get a new concept easily now, it's only because it's a variation on the accumulation of concepts I already know. In the Cal Poly computer science graduate program (which would take students who had non-CSci undergrad degrees), the students used to say that it took a year of being confused about computers before anything at all started to make sense (and they were in an immersion program). People often have unrealistic expectations of themselves when they try to learn about computers -- usually they want a high-paying job within a few weeks, and they've heard that computer programming pays the big bucks. But the best learning process starts with someone being interested in computers, and learning more and more as time passes, and generally teaching themselves. That's primarily what I have done; even though I had a strong foundation via computer engineering I didn't have many programming courses, but instead have been self taught. And I'm constantly learning new things. In this business, learning new things is a large portion of the profession.